RTP FEC + RTX: Using both rtpulpfecenc and rtprtxqueue

[Pablo Odorico]

Thank you Olivier and Mathieu,

I just tried moving the rtprtxqueues to rtpbin using
request-aux-sender but I'm encountering an issue that rtpbin expects
the pads to be named "src_%u" and "sink_%u" but they are instead named
"src" and "sink".
This may be a beginner question, but is there a way I can rename or
mirror those pads to match the expected name? Maybe there's a way to
put the rtprtxqueue in a bin and pass that to request-aux-sender?

Mathieu, I did read that article when researching this and I'm looking
forward to try rtpst2022-1-fecenc or flex once it makes it to a
release.

Regards,
Pablo

On Tue, Jun 8, 2021 at 8:15 PM Mathieu Duponchelle via gstreamer-devel
<gstreamer-devel at lists.freedesktop.org> wrote:
>
> Worth mentioning http://mathieuduponchelle.github.io/2020-10-09-SMPTE-2022-1-2D-Forward-Error-Correction-in-GStreamer.html,
> we can probably use this as the basis for flex fec, I second Olivier's
> comment that we want that :)
>
> On 6/8/21 7:04 PM, Olivier Crête via gstreamer-devel wrote:
> > Hi,
> >
> > You must place the rtprtxsend inside rtpbin too, you can do this by
> > inserting using the "request-aux-sender" signal that was designed for
> > this.
> >
> > 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.
> >
> > Olivier
> >
> > On Tue, 2021-06-08 at 17:42 +0200, Pablo Odorico via gstreamer-devel
> > wrote:
> >> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel