rtpsession: Deprecate rtcp-immediate-feedback-threshold property
authorSebastian Dröge <sebastian@centricular.com>
Sun, 25 Jan 2015 16:30:33 +0000 (17:30 +0100)
committerSebastian Dröge <sebastian@centricular.com>
Mon, 26 Jan 2015 17:49:31 +0000 (18:49 +0100)
commite4ed852041fc890706d2b002bb24d33078ba47ae
tree88d9ce25a29ea453fd4f282ce6b6d7d01d1307b4
parentb07b7736b37757e3e271eda27aacb4b0669826fa
rtpsession: Deprecate rtcp-immediate-feedback-threshold property

It had no effect since quite some time and also is not needed in general,
especially not to switch between immediate feedback mode and early feedback
mode. The latest understanding of the RFC is that from the endpoint point of
view, both modes are exactly the same. RTCP is only allowed to use the
bandwidth as given by the RFC constraints, as such it is only ever possible
to schedule a RTCP packet early but it's against the RFC to schedule more RTCP
packets.

The difference between immediate feedback mode and early feedback mode is that
the former guarantees that an RTCP packet can be sent for every event
"immediately", which means that the bandwidth calculations from the RFC have
resulted in an RTCP scheduling interval that is small enough. Early feedback
mode on the other hand means that we can schedule some packets early to make
that happen, but it's not guaranteed at all that it's possible to schedule
an RTCP packet per event (i.e. they need to be accumulated or dropped).
gst/rtpmanager/rtpsession.c