Interaction between rtpbin and rtpst2022-1-fec does not work when using the rtpbin `request-fec-decoder` signal.
CC @meh
GStreamers ulpfec
element is designed to be compatible with the "broken" FEC in Googles-WebRTC implementation, read here for reference: gst-plugins-good#581
Because of this, it is expecting to receive a single combined stream of RTP packets with both FEC and media packets combined.
The code for request-fec-decoder
signal on rtpbin
was originally designed for the ulpfec
.
Because of that, the fec-element returned by the request-fec-decoder
signal-handler is plugged in in a spot that works for ulpfec
.
Contrary to ulpfec
, rtpst2022-1-fec
is implemented so that it works in the general case. It expects to receive 3 independent RTP-streams, 1 media and 2 FEC.
If you want to use rtpst2022-1-fec
with rtpbin
, and use the request-fec-decoder
signal to instantiate it for rtpbin
, it will be plugged in the wrong place inside rtpbin
, and because of this, it will not work. Instead, using rtpst2022-1-fec
requires that one uses the fec-decoders
property of the rtpbin
, as then it will be plugged in by some different code-path inside rtpbin which places it is the correct spot.
See the attached scripts that demonstrate the problem.
- send.sh sends a test rtp stream with rtpst2022-1 fec encoding and H264
- receive.sh receives the stream and displays it using gst-launch-1.0 syntax. Works well.
-
receive.py receives the stream and displays it. Allows for setting a bool wether to use the
request-fec-decoder
signal or thefec-decoders
factory string. When using the signal, the receiver breaks and does not show any video.
Matrix chat for reference of when this issue was discovered: https://matrix.to/#/!rFXJkaEjvUdqUHMPew:gstreamer.org/$f6MnvwIYygfCdCNIge66EZwy5_GkwcfH8NGkDynUlmY?via=gstreamer.org&via=matrix.org&via=gnome.or