-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix RR handling for SenderBWE #1507
Conversation
chead->getSSRC(), | ||
chead->getSourceSSRC(), | ||
chead->getPacketType()); | ||
// ELOG_DEBUG("%s ssrc %u, sourceSSRC %u, PacketType %u", connection_->toLog(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, that's an annoying log when we set the log level to DEBUG so I'll remove it
avg_delay += rr_info->delay / rr_delay_data_size; | ||
}); | ||
if (period_packets_sent_ > 0) { | ||
uint32_t fraction_lost = total_packets_lost * 255 / period_packets_sent_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can't calculate the fraction lost in a period from the packets lost you get in a Receiver Report. You would have to keep track of the differences in packet loss between two consecutive Receiver Reports since it indicates the cumulative lost packets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good solution 👍 looks good to me
Description
There were still cases where the SenderBandwidthEstimationHandler was not calculating the bandwidth estimation properly. This PR fixes them. The problem was that we were updating the same estimator with RRs received from multiple streams.
[] It needs and includes Unit Tests
Changes in Client or Server public APIs
Not needed.
[] It includes documentation for these changes in
/doc
.