After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 640023 - Jitterbuffer: does not put the same gst timestamp on packets with the same RTP timestamp
Jitterbuffer: does not put the same gst timestamp on packets with the same RT...
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2011-01-20 03:33 UTC by Olivier Crête
Modified: 2013-02-06 16:20 UTC
See Also:
GNOME target: ---
GNOME version: ---

rtpjitterbuffer: Only compute skew once if multiple consecutive packets have the same ts (2.05 KB, patch)
2011-01-20 03:34 UTC, Olivier Crête
none Details | Review

Description Olivier Crête 2011-01-20 03:33:12 UTC
Currently, the jitterbuffer does the skew computation idependantly for every incoming packet. If a large video frame is split into separate packets, they all have the same RTP timestamp, so they should all have the same GStreamer timestamp. If the decoder uses the GStreamer timestamp to get the PTS after decoding, it could get confused (and ffdec_h264 does with the patch attached to bug #640012).
Comment 1 Olivier Crête 2011-01-20 03:34:09 UTC
Created attachment 178806 [details] [review]
rtpjitterbuffer: Only compute skew once if multiple consecutive packets have the same ts
Comment 2 Olivier Crête 2011-01-20 03:42:37 UTC
Actually, this bug actually causes serious confusing to the interpolation code in gstffmpegdec even without the patch from bug #640012
Comment 3 Wim Taymans 2011-01-20 12:19:01 UTC
Unfortunately, this makes it calculate the clock skew only on the first packet of a fragmented frame.

Maybe it's better to feed all timestamps in the skew correction but only use a more recent skew for the timestamps when the rtp time changes. you have to be careful about reordered packets too, so it should probably be done on the output side of things.

Maybe the easiest is to store the current skew in the buffer offset or something and then on the output size apply it to the buffer timestamp.

The real problem is again in ffmpeg, it uses the timestamp difference between consecutive packets to estimate the duration. It's difficult to do this right.. 

Also setting access-unit to TRUE on the depayloader (or using caps) should fix this because then each buffer is a complete frame and ffmpeg will do the right thing.
Comment 4 Olivier Crête 2011-01-20 17:50:19 UTC
I actually think that feeding subsequent packets to the skew algorithm will give the wrong result. Since the skew algorithm assumes that the RTP timestamp on the packet is related to the time when it was sent. If you have multiple consecutive packets with the same timestamp X, I think its safe to assume that the first one was sent around time X and the subsequent one were sent afterwards. So doing the skew computation from subsequent packets just adds noise..
Comment 5 Wim Taymans 2011-01-24 17:20:41 UTC
yes, you are right. I'll have a look at this.
Comment 6 Wim Taymans 2011-01-24 17:58:15 UTC
Did you ever see the current algorithm fail? if so, how did it happen?
Comment 7 Olivier Crête 2011-01-24 18:59:09 UTC
It's 100% reproducible with the example in farsight2. But only if I have two sessions (audio and video), not with a single one. And for some reason it works fine if I do it with gst-launch.
Comment 8 Wim Taymans 2013-02-06 16:20:12 UTC
commit c3077012c0914a8d3a103a858d820f4a3ec3c900
Author: Wim Taymans <>
Date:   Wed Feb 6 17:15:11 2013 +0100

    jitterbuffer: do skew estimation only for new timestamps
    Only run the skew estimation code when we have a new RTP timestamp. If we have
    the same RTP timestamp, we simply use the previous estimation. This works
    because the new observation with the same RTP timestamp has to have a bigger
    receiver time and is thus not going to influence the estimation except for
    causing more jitter.