[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 #2 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
I think this can be implemented quite easily actually, without introducing new
properties or anything.

- rtcp-min-interval is ignored if feedback is pending for the actual timeouts
and we only take the bandwidth calculations into account (also see bug
#747863), unless the last non-early RTCP packet is more than rtcp-min-interval
in the past (in which case we would schedule earlier). Exception to this is for
the very first RTCP packet, which would be at 1s if feedback is pending and
otherwise at the time the current code calculates (rtcp-min-interval/2).
- on every timeout, we send RTCP if the last non-early RTCP packet is more than
rtcp-min-interval in the past, or feedback is pending (in which case we
consider this RTCP packet as early feedback). Otherwise we suppress (and allow
early feedback again).

This would cause us to only send RTCP every rtcp-min-interval if there is no
feedback pending, and otherwise send RTCP as often as bandwidth calculations
allow (if there is actual feedback pending). As we always reconsider the next
timeout when feedback is to be sent, this would also not cause scheduled
timeouts to be too far in the future if no feedback was pending last time we
scheduled the timeout.




Also this would be a first step to reduced-size RTCP, as we would now already
have to store the time since the last non-early RTCP packet. Which with
reduced-size RTCP would be exactly the time since the last compound
(non-reduced size) RTCP packet. And whenever we send a non-early RTCP packet,
we would have to make sure that we really send a compound RTCP packet.
Additionally we would have to take IP/UDP headers into account and not consider
all RTCP packets of approximately equal size as Olivier said in comment 1.



Any comments here, potential problems?

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