RTP FEC + RTX: Using both rtpulpfecenc and rtprtxqueue

Olivier Crête olivier.crete at collabora.com
Tue Jun 8 17:04:26 UTC 2021


You must place the rtprtxsend inside rtpbin too, you can do this by
inserting using the "request-aux-sender" signal that was designed for

As for the FEC's success, if you do random drops and you drop multiple
packets in a sequence, it's expected that it won't be that great. For
those cases, we would need to implement 2D FEC and that's not
implemented yet for ULP. Ideally, we'd actually implement flexfec is
which the future of FEC, but that's also in the future.


On Tue, 2021-06-08 at 17:42 +0200, Pablo Odorico via gstreamer-devel
> Hello,
> Thank you for the awesome project.
> I'm trying to enable both RTP ULP-based FEC and RTX on a pipeline
> which is using rtpbin.
> They are both somewhat working independently*, but RTX breaks down
> when FEC is enabled. This is most likely due to this comment in the
> rtpulpfecenc doc:
> > This element rewrites packets' seqnums, which means that when combined with retransmission elements such as GstRtpRtxSend, it *must* be placed upstream of those, otherwise retransmission requests will request incorrect seqnums.
> Currently rtpulpfecenc is inside the rtpbin ("request-fec-encoder"
> signal) and rtprtxqueue is placed right before rtpbin.send_rtp_sink_0
> which upstream of rtpulpfecenc.
> Any idea how I can switch this order considering rtpbin is doing the
> linking of the rtpulpfecenc?
> * rtpulpfecenc is not working that great so far. Dropping 1% of
> packets it can only recover <50% of the packets no matter what the FEC
> percentage I use (even 100%), is this expected?
> Thank you,
> Pablo
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Olivier Crête
olivier.crete at collabora.com

More information about the gstreamer-devel mailing list