GNOME Bugzilla – Bug 587304
[jitterbuffer] don't handle correctly data burst from udpsrc
Last modified: 2010-03-01 11:50:27 UTC
The streaming server is a "Youtube Mobile" server through 3G network. The following script has been used for testing : (After creating PPP connection) export url="rtsp://rtsp- youtube.l.google.com/CkcLENy73wIaPgmxkKqBx7NymxMYDSANFEIJbXYtZ29vZ2xlSARSBWluZGV4Wg5DbGlja1RodW1ibmFp bGCtl9uD4q3MrIoBDA==/0/0/0/30/video.3gp" gst-launch playbin uri=$url --gst-debug=rtpjitterbuffer:5 At the begining of the video a large part of the video is played too quickly and frames skipping can be observed.(Note that video frame rate is 15fps) Video rendering frame rate analysis shows that during the begining of the video playback the rate is not consistant : -most of time, rate is higher than 66ms (after 1&2s the rate is close to 30ms) - it takes around 10s to stabilize "smoothly" to 66ms -after 3s we have several consecutive frame drops Analysis of Timestamping (as produced by Jitterbuffer) shows a close relation between the timestamping and rendering rate. The timestamping rate (that should be constant and equal to 66ms) : -is sometime too high (close to 30ms) and takes a also about 10s to stabilize to 66ms -after 3s, instead of increasing, it returns back to low value Gstreamer Jitterbuffer uses a "clock skew" algorithm (refer to "calculate_skew()" C function) in order to calculate and compensate drift between sender and receiver servers clocks. This algorithm allows then to calculate new timestamps for rendering after skew correction. This algorithm used as entry "sender server timestamps" (that have a fixed constant period - 66ms in our example) and "receiver Gstreamer timestamps" (time when buffers are read by gstreamer onto UDP (refer to "gst_base_src_do_sync() C function").In our case, speed arrival of UDP packets (during start-up phase : ~8s) is higher than theorical speed (the one specified by sender Timestamps) (This can be assimilated as a data burst). As a consequence, receiving Timestamps period is too small compared to theorical one. The Jitterbuffer detects a too high negative skew (cf calculate_skew() algorithm) and a too high negative correction is applied on timestamps. =>this explain the 30ms rate instead of 66ms and so high speed video In the worst case (as in our example), the skew correction algorithm detects a too big skew and reset the skew algorithm with consequence on Timestamping and rendering.(cf warning below in the trace) 0:00:05.412706778 1508 0xeb7e8 WARN rtpjitterbuffer rtpjitterbuffer.c:290:calculate_skew:<RTPJitterBuffer@0x45a01800> delta + 0:00:01.203199519 too big, reset skew =>this explain the backward timestamps and frame drop The skew calculation algorithm is not able to regulate UDP data burst that take too long time.
Created attachment 137555 [details] jitter buffer trace
I've had issues with the jitterbuffer as well (see Bug 565319). The patch there solved things for me, but I agree things aren't perfect yet. I think the problem occurs when you have bursty behaviour while the window is filling. Once the window is full, there are enough samples to reduce the impact of the burst, but when it's filling it causes large inaccuracies. And of course, when the skew is too big and it is reset, the problem reappears... So maybe the skew compensation should be disabled completely while the window is filling. But then there can be a big jump in skew, so we have to find a solution for that as well... By the way, you do have plugins-bad >= 0.10.10 where the patches of Bug 565319 have been applied, correct? It should no longer be possible for timestamps to go back in time, so if they do, something is definitely wrong.
I have plugins-bad 0.10.12 and the timestamps are going back in time.
The is a slope calculation code in the jitterbuffer now. It's not hooked up yet but you should be able to see bursty behaviour in the debug log now.
I have a branch with a new buffering mode that is more suited for streaming RTP applications like rtsp.
Commited the new buffering algorithm.