retransmission with rtpbin and rtprtxqueue
Locked
 
|
Hi,
I want to live stream a video over mobile networks. To achieve minimal latency I need to use udp. To get started using the rtpbin with its retransmission mechanism, I am testing on the localhost with simulated paket loss. Here are my two pipelines: SENDER: gst-launch-1.0 -v rtpbin name=rtpbin \ souphttpsrc location=https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm ! matroskademux ! vp8dec ! x264enc bitrate=5000 ! rtph264pay ! rtprtxqueue ! rtpbin.send_rtp_sink_0 \ rtpbin.send_rtp_src_0 ! identity drop-probability=0.01 ! udpsink host=127.0.0.1 port=5000 \ rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false async=false \ udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0; RECEIVER: gst-launch-1.0 -v rtpbin name=rtpbin do-retransmission=true latency=500 \ udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" \ port=5000 ! rtpbin.recv_rtp_sink_0 \ rtpbin. ! rtph264depay ! decodebin output-corrupt=true ! xvimagesink \ udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \ rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5005 sync=false async=false; For this, the retransmission mechanism does not work as expected. I am experiencing, probably all, packet loss, i.e., corrupt frames. On the receiver side, the rtx-count skyrockets (6376 after 19s). On the sender side, there is a negative number of lost packets (-1786 after 19s). See below the complete stats. Am I missing an important parameter or element in my pipelines? Another question: Is there any more robust choice than above pipeline for minimal, latency video streaming of multiple cameras? H264 (with tunes zerolatency and preset ultrafast) seems like a good choice due low CPU load. Andi -v output from the SENDING PIPELINE: /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0: stats = application/x-rtp-session-stats, rtx-drop-count=(uint)0, sent-nack-count=(uint)0, recv-nack-count=(uint)117, source-stats=(GValueArray)< "application/x-rtp-source-stats\,\ ssrc\=\(uint\)3302729844\,\ internal\=\(boolean\)false\,\ validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)false\,\ seqnum-base\=\(int\)-1\,\ clock-rate\=\(int\)-1\,\ rtcp-from\=\(string\)127.0.0.1:51795\,\ octets-sent\=\(guint64\)0\,\ packets-sent\=\(guint64\)0\,\ octets-received\=\(guint64\)0\,\ packets-received\=\(guint64\)0\,\ bitrate\=\(guint64\)0\,\ packets-lost\=\(int\)0\,\ jitter\=\(uint\)0\,\ sent-pli-count\=\(uint\)0\,\ recv-pli-count\=\(uint\)0\,\ sent-fir-count\=\(uint\)0\,\ recv-fir-count\=\(uint\)0\,\ sent-nack-count\=\(uint\)0\,\ recv-nack-count\=\(uint\)0\,\ have-sr\=\(boolean\)false\,\ sr-ntptime\=\(guint64\)0\,\ sr-rtptime\=\(uint\)0\,\ sr-octet-count\=\(uint\)0\,\ sr-packet-count\=\(uint\)0\,\ sent-rb\=\(boolean\)false\,\ sent-rb-fractionlost\=\(uint\)0\,\ sent-rb-packetslost\=\(int\)0\,\ sent-rb-exthighestseq\=\(uint\)0\,\ sent-rb-jitter\=\(uint\)0\,\ sent-rb-lsr\=\(uint\)0\,\ sent-rb-dlsr\=\(uint\)0\,\ have-rb\=\(boolean\)true\,\ rb-fractionlost\=\(uint\)0\,\ rb-packetslost\=\(int\)0\,\ rb-exthighestseq\=\(uint\)10216\,\ rb-jitter\=\(uint\)0\,\ rb-lsr\=\(uint\)1152762771\,\ rb-dlsr\=\(uint\)11998\,\ rb-round-trip\=\(uint\)54\;", "application/x-rtp-source-stats\,\ ssrc\=\(uint\)3116036975\,\ internal\=\(boolean\)true\,\ validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)true\,\ seqnum-base\=\(int\)10071\,\ clock-rate\=\(int\)90000\,\ octets-sent\=\(guint64\)4996323\,\ packets-sent\=\(guint64\)3959\,\ octets-received\=\(guint64\)4996323\,\ packets-received\=\(guint64\)1786\,\ bitrate\=\(guint64\)2983649\,\ packets-lost\=\(int\)-1786\,\ jitter\=\(uint\)0\,\ sent-pli-count\=\(uint\)0\,\ recv-pli-count\=\(uint\)0\,\ sent-fir-count\=\(uint\)0\,\ recv-fir-count\=\(uint\)0\,\ sent-nack-count\=\(uint\)0\,\ recv-nack-count\=\(uint\)117\,\ have-sr\=\(boolean\)true\,\ sr-ntptime\=\(guint64\)16328720465379218184\,\ sr-rtptime\=\(uint\)2041153692\,\ sr-octet-count\=\(uint\)4996323\,\ sr-packet-count\=\(uint\)3959\;" >, rtx-count=(uint)0; ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:19.652469133 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... -v output from the RECEIVING PIPELINE: /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0: stats = application/x-rtp-session-stats, rtx-drop-count=(uint)0, sent-nack-count=(uint)366, recv-nack-count=(uint)0, source-stats=(GValueArray)< "application/x-rtp-source-stats\,\ ssrc\=\(uint\)3302729844\,\ internal\=\(boolean\)true\,\ validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)false\,\ seqnum-base\=\(int\)-1\,\ clock-rate\=\(int\)-1\,\ octets-sent\=\(guint64\)0\,\ packets-sent\=\(guint64\)0\,\ octets-received\=\(guint64\)0\,\ packets-received\=\(guint64\)0\,\ bitrate\=\(guint64\)0\,\ packets-lost\=\(int\)0\,\ jitter\=\(uint\)0\,\ sent-pli-count\=\(uint\)0\,\ recv-pli-count\=\(uint\)0\,\ sent-fir-count\=\(uint\)0\,\ recv-fir-count\=\(uint\)0\,\ sent-nack-count\=\(uint\)0\,\ recv-nack-count\=\(uint\)0\,\ have-sr\=\(boolean\)false\,\ sr-ntptime\=\(guint64\)0\,\ sr-rtptime\=\(uint\)0\,\ sr-octet-count\=\(uint\)0\,\ sr-packet-count\=\(uint\)0\;", "application/x-rtp-source-stats\,\ ssrc\=\(uint\)3116036975\,\ internal\=\(boolean\)false\,\ validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)true\,\ seqnum-base\=\(int\)-1\,\ clock-rate\=\(int\)-1\,\ rtp-from\=\(string\)127.0.0.1:39862\,\ rtcp-from\=\(string\)127.0.0.1:53468\,\ octets-sent\=\(guint64\)0\,\ packets-sent\=\(guint64\)0\,\ octets-received\=\(guint64\)6672117\,\ packets-received\=\(guint64\)5244\,\ bitrate\=\(guint64\)3099889\,\ packets-lost\=\(int\)-2082\,\ jitter\=\(uint\)0\,\ sent-pli-count\=\(uint\)0\,\ recv-pli-count\=\(uint\)0\,\ sent-fir-count\=\(uint\)0\,\ recv-fir-count\=\(uint\)0\,\ sent-nack-count\=\(uint\)367\,\ recv-nack-count\=\(uint\)0\,\ have-sr\=\(boolean\)true\,\ sr-ntptime\=\(guint64\)16328720465379218184\,\ sr-rtptime\=\(uint\)2041153692\,\ sr-octet-count\=\(uint\)4996323\,\ sr-packet-count\=\(uint\)3959\,\ sent-rb\=\(boolean\)true\,\ sent-rb-fractionlost\=\(uint\)0\,\ sent-rb-packetslost\=\(int\)0\,\ sent-rb-exthighestseq\=\(uint\)10216\,\ sent-rb-jitter\=\(uint\)0\,\ sent-rb-lsr\=\(uint\)1152762771\,\ sent-rb-dlsr\=\(uint\)11998\,\ have-rb\=\(boolean\)false\,\ rb-fractionlost\=\(uint\)0\,\ rb-packetslost\=\(int\)0\,\ rb-exthighestseq\=\(uint\)0\,\ rb-jitter\=\(uint\)0\,\ rb-lsr\=\(uint\)0\,\ rb-dlsr\=\(uint\)0\,\ rb-round-trip\=\(uint\)0\;" >, rtx-count=(uint)6376; ^Chandling interrupt. Interrupt: Stopping pipeline ... Execution ended after 0:00:19.916776877 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: retransmission with rtpbin and rtprtxqueue
|
|
Le lundi 22 juin 2020 à 10:09 -0500, andis a écrit :
> Hi, > > I want to live stream a video over mobile networks. To achieve minimal > latency I need to use udp. To get started using the rtpbin with its > retransmission mechanism, I am testing on the localhost with simulated paket > loss. Here are my two pipelines: > > SENDER: > gst-launch-1.0 -v rtpbin name=rtpbin \ > souphttpsrc > location= > https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm > ! matroskademux ! vp8dec ! x264enc bitrate=5000 ! rtph264pay ! rtprtxqueue ! > rtpbin.send_rtp_sink_0 \ > rtpbin.send_rtp_src_0 ! identity drop-probability=0.01 ! udpsink > host=127.0.0.1 port=5000 \ > rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5001 sync=false > async=false \ > udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0; Doing retransmission with rtprtxqueue is not standard and usually not ideal. That being said, this is likely the only way to enable RTX from launch syntax. As enabling this is tedious, 1.17.1 (development release) includes new element rtpsrc/rtsink which will take care of that for you, I greatly recommend to give that a shot. If you are aiming to use that in your project, we aren't too far from the release, so it's good idea to target this. > > > RECEIVER: > gst-launch-1.0 -v rtpbin name=rtpbin do-retransmission=true latency=500 \ > udpsrc > caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding- > name=(string)H264" > \ > port=5000 ! rtpbin.recv_rtp_sink_0 \ > rtpbin. ! rtph264depay ! decodebin output-corrupt=true ! xvimagesink \ > udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \ > rtpbin.send_rtcp_src_0 ! udpsink host=127.0.0.1 port=5005 sync=false > async=false; > > > For this, the retransmission mechanism does not work as expected. I am > experiencing, probably all, packet loss, i.e., corrupt frames. On the > receiver side, the rtx-count skyrockets (6376 after 19s). On the sender > side, there is a negative number of lost packets (-1786 after 19s). See > below the complete stats. > > Am I missing an important parameter or element in my pipelines? > > > Another question: Is there any more robust choice than above pipeline for > minimal, latency video streaming of multiple cameras? H264 (with tunes > zerolatency and preset ultrafast) seems like a good choice due low CPU load. > > Andi > > > -v output from the SENDING PIPELINE: > /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0: stats = > application/x-rtp-session-stats, rtx-drop-count=(uint)0, > sent-nack-count=(uint)0, recv-nack-count=(uint)117, > source-stats=(GValueArray)< "application/x-rtp-source-stats\,\ > ssrc\=\(uint\)3302729844\,\ internal\=\(boolean\)false\,\ > validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ > is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)false\,\ > seqnum-base\=\(int\)-1\,\ clock-rate\=\(int\)-1\,\ > rtcp-from\=\(string\)127.0.0.1:51795\,\ octets-sent\=\(guint64\)0\,\ > packets-sent\=\(guint64\)0\,\ octets-received\=\(guint64\)0\,\ > packets-received\=\(guint64\)0\,\ bitrate\=\(guint64\)0\,\ > packets-lost\=\(int\)0\,\ jitter\=\(uint\)0\,\ sent-pli-count\=\(uint\)0\,\ > recv-pli-count\=\(uint\)0\,\ sent-fir-count\=\(uint\)0\,\ > recv-fir-count\=\(uint\)0\,\ sent-nack-count\=\(uint\)0\,\ > recv-nack-count\=\(uint\)0\,\ have-sr\=\(boolean\)false\,\ > sr-ntptime\=\(guint64\)0\,\ sr-rtptime\=\(uint\)0\,\ > sr-octet-count\=\(uint\)0\,\ sr-packet-count\=\(uint\)0\,\ > sent-rb\=\(boolean\)false\,\ sent-rb-fractionlost\=\(uint\)0\,\ > sent-rb-packetslost\=\(int\)0\,\ sent-rb-exthighestseq\=\(uint\)0\,\ > sent-rb-jitter\=\(uint\)0\,\ sent-rb-lsr\=\(uint\)0\,\ > sent-rb-dlsr\=\(uint\)0\,\ have-rb\=\(boolean\)true\,\ > rb-fractionlost\=\(uint\)0\,\ rb-packetslost\=\(int\)0\,\ > rb-exthighestseq\=\(uint\)10216\,\ rb-jitter\=\(uint\)0\,\ > rb-lsr\=\(uint\)1152762771\,\ rb-dlsr\=\(uint\)11998\,\ > rb-round-trip\=\(uint\)54\;", "application/x-rtp-source-stats\,\ > ssrc\=\(uint\)3116036975\,\ internal\=\(boolean\)true\,\ > validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ > is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)true\,\ > seqnum-base\=\(int\)10071\,\ clock-rate\=\(int\)90000\,\ > octets-sent\=\(guint64\)4996323\,\ packets-sent\=\(guint64\)3959\,\ > octets-received\=\(guint64\)4996323\,\ packets-received\=\(guint64\)1786\,\ > bitrate\=\(guint64\)2983649\,\ packets-lost\=\(int\)-1786\,\ > jitter\=\(uint\)0\,\ sent-pli-count\=\(uint\)0\,\ > recv-pli-count\=\(uint\)0\,\ sent-fir-count\=\(uint\)0\,\ > recv-fir-count\=\(uint\)0\,\ sent-nack-count\=\(uint\)0\,\ > recv-nack-count\=\(uint\)117\,\ have-sr\=\(boolean\)true\,\ > sr-ntptime\=\(guint64\)16328720465379218184\,\ > sr-rtptime\=\(uint\)2041153692\,\ sr-octet-count\=\(uint\)4996323\,\ > sr-packet-count\=\(uint\)3959\;" >, rtx-count=(uint)0; > ^Chandling interrupt. > Interrupt: Stopping pipeline ... > Execution ended after 0:00:19.652469133 > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > Freeing pipeline ... > > > -v output from the RECEIVING PIPELINE: > /GstPipeline:pipeline0/GstRtpBin:rtpbin/GstRtpSession:rtpsession0: stats = > application/x-rtp-session-stats, rtx-drop-count=(uint)0, > sent-nack-count=(uint)366, recv-nack-count=(uint)0, > source-stats=(GValueArray)< "application/x-rtp-source-stats\,\ > ssrc\=\(uint\)3302729844\,\ internal\=\(boolean\)true\,\ > validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ > is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)false\,\ > seqnum-base\=\(int\)-1\,\ clock-rate\=\(int\)-1\,\ > octets-sent\=\(guint64\)0\,\ packets-sent\=\(guint64\)0\,\ > octets-received\=\(guint64\)0\,\ packets-received\=\(guint64\)0\,\ > bitrate\=\(guint64\)0\,\ packets-lost\=\(int\)0\,\ jitter\=\(uint\)0\,\ > sent-pli-count\=\(uint\)0\,\ recv-pli-count\=\(uint\)0\,\ > sent-fir-count\=\(uint\)0\,\ recv-fir-count\=\(uint\)0\,\ > sent-nack-count\=\(uint\)0\,\ recv-nack-count\=\(uint\)0\,\ > have-sr\=\(boolean\)false\,\ sr-ntptime\=\(guint64\)0\,\ > sr-rtptime\=\(uint\)0\,\ sr-octet-count\=\(uint\)0\,\ > sr-packet-count\=\(uint\)0\;", "application/x-rtp-source-stats\,\ > ssrc\=\(uint\)3116036975\,\ internal\=\(boolean\)false\,\ > validated\=\(boolean\)true\,\ received-bye\=\(boolean\)false\,\ > is-csrc\=\(boolean\)false\,\ is-sender\=\(boolean\)true\,\ > seqnum-base\=\(int\)-1\,\ clock-rate\=\(int\)-1\,\ > rtp-from\=\(string\)127.0.0.1:39862\,\ > rtcp-from\=\(string\)127.0.0.1:53468\,\ octets-sent\=\(guint64\)0\,\ > packets-sent\=\(guint64\)0\,\ octets-received\=\(guint64\)6672117\,\ > packets-received\=\(guint64\)5244\,\ bitrate\=\(guint64\)3099889\,\ > packets-lost\=\(int\)-2082\,\ jitter\=\(uint\)0\,\ > sent-pli-count\=\(uint\)0\,\ recv-pli-count\=\(uint\)0\,\ > sent-fir-count\=\(uint\)0\,\ recv-fir-count\=\(uint\)0\,\ > sent-nack-count\=\(uint\)367\,\ recv-nack-count\=\(uint\)0\,\ > have-sr\=\(boolean\)true\,\ sr-ntptime\=\(guint64\)16328720465379218184\,\ > sr-rtptime\=\(uint\)2041153692\,\ sr-octet-count\=\(uint\)4996323\,\ > sr-packet-count\=\(uint\)3959\,\ sent-rb\=\(boolean\)true\,\ > sent-rb-fractionlost\=\(uint\)0\,\ sent-rb-packetslost\=\(int\)0\,\ > sent-rb-exthighestseq\=\(uint\)10216\,\ sent-rb-jitter\=\(uint\)0\,\ > sent-rb-lsr\=\(uint\)1152762771\,\ sent-rb-dlsr\=\(uint\)11998\,\ > have-rb\=\(boolean\)false\,\ rb-fractionlost\=\(uint\)0\,\ > rb-packetslost\=\(int\)0\,\ rb-exthighestseq\=\(uint\)0\,\ > rb-jitter\=\(uint\)0\,\ rb-lsr\=\(uint\)0\,\ rb-dlsr\=\(uint\)0\,\ > rb-round-trip\=\(uint\)0\;" >, rtx-count=(uint)6376; > ^Chandling interrupt. > Interrupt: Stopping pipeline ... > Execution ended after 0:00:19.916776877 > Setting pipeline to PAUSED ... > Setting pipeline to READY ... > Setting pipeline to NULL ... > Freeing pipeline ... > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
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? 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 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 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 Andi -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: retransmission with rtpbin and rtprtxqueue
|
|
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 > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |