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