GNOME Bugzilla – Bug 747919
rtpbin: RTX packets only forwarded after two are received (probation period)
Last modified: 2018-11-03 14:59:54 UTC
Currently an RTX packet is queued up in rtpsource on the receiver until a second one is received... because of the probation period. That's obviously not a good idea for RTX packets, as that one will then be far too late and we don't really have that many packets anyway. Problem now is that nothing in rtpbin knows about RTX, and somehow we need to get this information to rtpsource so that it does not queue up things.
Also see https://bugzilla.gnome.org/show_bug.cgi?id=747922 for some bad effects from this.
Afaik, the application creating the RTX session should just set the "probation" property on the RTPSession object to 0.
But that would also affect the sources for any non-RTX streams. As discussed with Wim on IRC, I'm going to try to make rtpsource aware of what are RTX streams and what not, and ignore the probation period for RTX streams.
This is actually not (usually) a problem anymore after bug #747394 is fixed. That bug allowed us to receive an RTCP packet for the RTX stream before anything else, which then set the probation to 0. If all RTCP packets are lost before we receive a RTX packet, it will still be a problem though. However the only way to get this information to rtpsource seems to be via the caps, which requires adding more callbacks to rtpsource and rtpsession to request-pt-map can be emitted. And then *the application* could provide something inside the caps, e.g. not just the payload but also a rtx-original-payload field (so that rtpsource can know that this is actually an RTX stream if it receives some new payload type).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/181.