GNOME Bugzilla – Bug 746035
rtpjitterbuffer: Does not handle bursts properly
Last modified: 2018-11-03 14:58:35 UTC
Created attachment 299099 [details] Sample rtsp audio stream which yields duplicate timestamps with rtpjitterbuffer When the attached gdp-payloaded file is run through rtpjitterbuffer, with mode=slave (the default), the output audio has buffers with duplicate pts, but not with mode=buffer/synced/none. Those buffers all seem to contain silence (see bug 746032). Bad: gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer ! rtpmp4adepay ! decodebin ! ... Good: gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=buffer ! rtpmp4adepay ! decodebin ! ... gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=synced ! rtpmp4adepay ! decodebin ! ... gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay ! rtpjitterbuffer mode=none ! rtpmp4adepay ! decodebin ! ... All the incoming packets are sequential and evenly-spaced (captured from gst-rtsp-server over a link-local network), so in theory there shouldn't be a "discontinuity" like that.
Created attachment 299200 [details] Sample rtsp audio stream which yields duplicate timestamps with rtpjitterbuffer I attached the wrong file, sorry. :)
The problem here is: 0:00:00.073105731 19667 0x1721450 DEBUG rtpjitterbuffer rtpjitterbuffer.c:601:calculate_skew: backwards timestamps, using previous time but I fail to understand the calculations that lead to this currently. All timestamps I see are monotonically increasing :)
The bug here is that we have two jitterbuffers, the second one becoming completely confused because of the first. rtspsrc ! gdppay ! filesink (one jitterbuffer in rtspsrc) filesrc ! gdpdepay ! rtpjitterbuffer ! ... (second jitterbuffer).
As discussed on IRC, the bug does happen even without gdp(de)pay. I'm attaching a full pcap capture (RTP, TCP, RTSP/SDP) as requested by Sebastian.
The file is too big for bugzilla even with `xz`, so I've put it on my server: http://nirbheek.in/files/rtpjitterbuffer-bug.pcap
The problem here is that we get a burst of data in the beginning. The way to handle this is a bit complicated :) - The jitterbuffer has to check when it first filled up to $latency amount of RTP timestamps - If the slope is >> 1.0 then (i.e. we received all these buffers much faster than real time), the real latency of the jitterbuffer is the time it took to fill up the buffer and this should be used in the replies to the LATENCY query - Once the slope goes back to normal, i.e. close to 1.0, we skew once - Whenever the slope is much bigger than 1.0 (also later), we won't skew until the slope goes back to normal. Skewing would just completely break everything :) As an end result, we would start playback faster (i.e. GStreamer latency is small) but the sender-to-receiver latency would have the latency value configured on the jitterbuffer.
> gst-launch-1.0 filesrc location=rtpjitterbuffer-bug.pcap ! pcapparse src-port=46028 dst-port=44382 caps="application/x-rtp,media=audio,clock-rate=44100,encoding-name=MP4A-LATM,clock-base=703710269,seqnum-base=12883" ! rtpjitterbuffer ! fakesink silent=false sync=true
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/167.