Dropped buffers with rtprtxreceive

Samuel Hurst samuelh at rd.bbc.co.uk
Fri Jan 28 15:41:19 UTC 2022


Hello all,

I'm doing some investigation with the rtprtx* elements for GStreamer and 
running into a few issues. Primarily, when I induce packet loss using 
netem [1] on the link in order to test the retransmission functionality, 
I get a lot of WARN-level debug output that says there's no clock-rate 
in caps and that it's dropping buffers:


> 0:00:10.753827153 197836 0x55f378160060 ERROR        rtpjitterbuffer gstrtpjitterbuffer.c:1401:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer2> Got caps with wrong payload type (got 97, expected 96)
> 0:00:10.753875088 197836 0x55f378160060 WARN         rtpjitterbuffer gstrtpjitterbuffer.c:3316:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer2> No clock-rate in caps!, dropping buffer
> 0:00:10.754099058 197836 0x55f378160060 WARN               rtpsource rtpsource.c:1015:calculate_jitter: cannot get clock-rate for pt 97
> 0:00:10.754129159 197836 0x55f378160060 WARN         rtpjitterbuffer gstrtpjitterbuffer.c:3316:gst_rtp_jitter_buffer_chain:<rtpjitterbuffer2> No clock-rate in caps!, dropping buffer
> 0:00:10.754173119 197836 0x55f378160060 WARN               rtpsource rtpsource.c:1015:calculate_jitter: cannot get clock-rate for pt 97


My understanding of the rtprtx* elements is that by passing the 
payload-type-map parameter I tell it what payload type the retransmitted 
packets are using, and the documentation for rtprtxreceive [2] seems to 
imply that it forwards the retransmission packets to other RTP elements 
with the original SSRC and payload type, so I'm not sure why 
rtpjitterbuffer is still seeing PT97 as it's a later element in the 
pipeline (see below).

I also occasionally get messages from the decoder and the playback 
window is also not smooth, so I don't think it's actually successfully 
doing retransmission.

For reference, I'm running on GStreamer 1.19.3 from git, and here's my 
sending pipeline:


> gst-launch-1.0 -e rtpbin name=r sdes="application/x-rtp-source-sdes,cname=(string)\"samuelh\@rd.bbc.co.uk\"" videotestsrc ! "video/x-raw,width=1280,height=720,framerate=25/1" ! queue ! videoconvert ! x264enc bitrate=8000 ! rtph264pay ! "application/x-rtp,payload=(int)96,clock-rate=(int)90000,ssrc=(uint)123456" ! rtprtxsend payload-type-map="application/x-rtp-pt-map,96=(uint)97" ! r.send_rtp_sink_0 r.send_rtp_src_0 ! udpsink host=192.168.57.1 port=5000 r.send_rtcp_src_0 ! udpsink host=192.168.57.1 port=5001 sync=false async=false udpsrc port=6001 ! r.recv_rtcp_sink_0


And my receiving pipeline:


> gst-launch-1.0 -e rtpbin name=r sdes="application/x-rtp-source-sdes,cname=(string)\"samuelh\@rd.bbc.co.uk\"" udpsrc port=5000 ! "application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96" ! r.recv_rtp_sink_0 r.recv_rtp_src_0_123456_96 ! rtprtxreceive payload-type-map="application/x-rtp-pt-map,96=(uint)97" ! rtpssrcdemux ! rtpjitterbuffer do-retransmission=true ! rtph264depay ! queue ! avdec_h264 ! videoconvert ! queue ! xvimagesink udpsrc port=5001 ! r.recv_rtcp_sink_0 r.send_rtcp_src_0 ! udpsink host=192.168.57.101 port=6001 sync=false async=false


Any help on this matter is very appreciated.

Best regards,
-Sam


[1]: https://wiki.linuxfoundation.org/networking/netem
[2]: 
https://gstreamer.freedesktop.org/documentation/rtpmanager/rtprtxreceive.html?gi-language=c


More information about the gstreamer-devel mailing list