[gstreamer-bugs] [Bug 587304] New: [jitterbuffer] don't handle correctly data burst from udpsrc

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=587304

  GStreamer | gst-plugins-bad | Ver: 0.10.12
           Summary: [jitterbuffer] don't handle correctly data burst from
                    udpsrc
           Product: GStreamer
           Version: 0.10.12
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: benjamin at gaignard.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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 at 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.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=587304.