retransmission with rtpbin and rtprtxqueue

[Nicolas Dufresne]

Le mardi 23 juin 2020 à 01:01 -0500, andis a écrit :
> Hi Nicolas, 
> 
> Many thanks for your reply! Actually I already wrote a C++ Application and
> started the pipelines from there, so no gst-launch. In brief, what would be
> required to make it working? What is done differently compared to what
> happens at gst-launch? 

There is request-aux-sender/receiver callback, to which you will return a bin.
It's inside this bin that you will have to add the rtprtxreceiver/rtprtxsender
elements. You should go through the properties, and make sure they are configure
for your needs. On top of this, you need to set "do-retransmission" property of
rtpbin to TRUE.

> 
> Sure, I will check out the rtpsink / rtpsrc elements. Would the following
> pipelines be sufficient? 
> SENDER: gst-launch-1.0 -v souphttpsrc
> location=
> https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm
> ! matroskademux ! vp8dec ! x264enc bitrate=5000 ! rtph264pay ! identity
> drop-probability=0.01 ! rtpsink address=127.0.0.1 port=5000
> RECEIVER: gst-launch-1.0 -v rtpsrc address=127.0.0.1 port=5000 !
> rtph264depay ! decodebin ! xvimagesink

To use rtpsrc, you need to specify the encoding-name property, in your case
"H264" is the standard RTP encoding name.

> 
> How would it be made work there? I found a latency property in the rtpsrc,
> but nothing being mentioned on retransmission. 
> https://gstreamer.freedesktop.org/documentation/rtpmanagerbad/rtpsrc.html?gi-language=c#properties 

Indeed, I was under the impression the rtpsrc/sink enabled RTX, but now I'm in
doubt, I will ping Marc and check, if this indeed not enabled, I'll make a
patch, and make this controllable through a property with the same name as on
rtpbin.

You can use ristsrc/ristsink to get good RTX without too much effort, but the
implementation is of RTX follows RIST spec, which is an RTP extension. RTX is
already implemented in the RTSP server and client (with a boolean property to
enable).

> I also find the rtprtxreceive/send elements, which are already available in
> my version 1.14.5. What are the differences here? 
> https://gstreamer.freedesktop.org/documentation/rtpmanager/rtprtxreceive.html?gi-language=javascript 

rtprtxqueue is not following any standards, it will send the RTX packet as part
of the same session, it does not really allow for full tracking of what was RTX
and what wasn't (causing some stats needed to implement the RFC to not work).
With rtprtxreceiver/rtprtxsender, the RTX is an auxiliary stream as specified by
RFC4588. This method will allow to exchange with non-gstreamer receiver/sender.

> 
> Andi
> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel