[Bug 746543] rtpsession: Properly implement T_rr_interval and allow sending multiple early feedback packets in a row

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=746543

--- Comment #28 from Magnus Westerlund <magnus.westerlund at ericsson.com> ---
(In reply to Sebastian Dröge (slomo) from comment #27)
> To improve upon the last patch, I'm going to rewrite the timeout scheduling
> a bit now. We would only schedule a timeout by default for every
> MAX(rtcp-min-interval, calculated-rtcp-min-interval)... unless feedback is
> requested to be sent.
> 
> Then we would schedule earlier, based on the calculated-rtcp-min-interval
> and the last time we sent something. Based on that we would also decide if
> we can do early feedback or not.
> 
> That way we would only wake up the RTCP threads when something is actually
> to be sent (or when a forward reconsideration is happening).
> 
> 
> The bad thing about this is that it's not exactly the same as in the spec
> anymore then. The behaviour will be the same, but the algorithm is different.

I have to ask about what you refer to as a "forward reconsideration" is that
for the cases when the reverse reconsideration algorithm tests if it is going
to transmit and come up with a transmission interval larger than what resulted
in this wakeup? If that is the case, I am fine. 

Secondly, I hope the "rtcp-min-interval" above will be the currently randomized
value, i.e. T_rr_current_interval from RFC 4585. If not you disable the timer
self synchronization protection. 

Another effect this could have, is that as it is not suppressing a number of
steps with the normally calculated and randomized value is that it will change
the transmission distribution for when being suppressed. The resulting behavior
according to the spec, can result in that the actual RTCP interval becomes up
to 2.73*T_rr_int. I do consider it a bug, but we haven't gotten around to do
anything towards updating the AVPF specification in this regard. So, from that
perspective, using the randomized T_rr_interval is fine. 

What I am uncertain is what behavior you will see when rtcp-min-interval and
calculated-rtcp-min-interval are almost equal in size, at least their
determenistic part. As you will choose the longer, at least you will not use
more bandwidth than is assigned. Thus, I expect this to be fine from that
aspect. 

Further, I hope you ensure that if FB packets are needed to be sent that you
perform the evaluation if allowed_early should be reset at that time.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.