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 631075 - RTP based decoding degrades over time
RTP based decoding degrades over time
Product: GStreamer
Classification: Platform
Component: gst-libav
Other Linux
: Normal normal
: 0.10.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2010-10-01 08:00 UTC by Marc Leeman
Modified: 2010-10-14 20:04 UTC
See Also:
GNOME target: ---
GNOME version: ---

verbose log (451.15 KB, application/x-bzip)
2010-10-05 13:55 UTC, Thijs Vermeir

Description Marc Leeman 2010-10-01 08:00:41 UTC
RTP based decodding (tested mostly with h.264) from a range of encoders (gstreamer and hardware) go to slideshow mode after playing for about 12-18hs.

This seems to be something new; I haven't had this in previous releases yet.
Comment 1 Wim Taymans 2010-10-05 11:21:39 UTC
What's the previous release that doesn't exhibit the problem?
Comment 2 Wim Taymans 2010-10-05 11:50:08 UTC
If the maximum amount of reordered frames is larger than the jittebuffer size, it resets currently and causes weird timestamps. Increasing the latency solves this.

the relevant commit was one for Bug #593354
Comment 3 Marc Leeman 2010-10-05 13:07:14 UTC
We have settings with 300 ms latency on a local network with Cisco Catalyst 3750 switches with a couple tens of streams running from bitrates ranging from a couple kB to several MB.

I don't think that reordering for over 300 ms on RTP is likely (I think they even guarantee that the packets arrive in time).
Comment 4 Marc Leeman 2010-10-05 13:07:53 UTC
"arrive in time" -> "arrive in order" that is
Comment 5 Thijs Vermeir 2010-10-05 13:55:59 UTC
Created attachment 171767 [details]
verbose log

This is a verbose log, when this is happening. I don't see in the logs that the jitterbuffer resets when the weird timestamps start.
Comment 6 Wim Taymans 2010-10-05 15:47:37 UTC
(In reply to comment #5)
> Created an attachment (id=171767) [details]
> verbose log
> This is a verbose log, when this is happening. I don't see in the logs that the
> jitterbuffer resets when the weird timestamps start.

That all looks fine. The max reorder is around 106ms
Comment 7 Wim Taymans 2010-10-06 14:06:01 UTC
The problem turns out to be ffmpeg related. The timestamp tracking system is broken when QoS is performed.

Also as a sidenote, when ffmpeg starts doing QoS and frame dropping, due to the nature of this stream, it never goes back to normal operation and you essentially end up with reduced framerate video.
Comment 8 Wim Taymans 2010-10-06 16:50:54 UTC
This should avoid being stuck in hurry up mode.

commit 4aa9b97d3fabdbb5a7c63f9543b673dbf29a1965
Author: Wim Taymans <>
Date:   Wed Oct 6 16:43:27 2010 +0200

    ffcodecmap: avoid setting large framerates
    When the framerate is bigger than 1000/1, set it to 0/1 instead. This avoids
    letting the videosink do QoS on these very small frame durations.
Comment 9 Wim Taymans 2010-10-06 17:00:02 UTC
this fixes it for me.

commit 76d9685202e4443573d71c16b0445cbd3fb59aca
Author: Wim Taymans <>
Date:   Wed Oct 6 16:00:05 2010 +0200

    ffdec: Add timestamp tracking
    Use ffmpeg reordered_opaque to track an id that combines all timing info we have
    for a frame. The ids are kept in a 255 item cache.
    Fixes #631075

commit edb79396f2ecea58259b05a79608df1b24da283c
Author: Wim Taymans <>
Date:   Wed Oct 6 12:30:57 2010 +0200

    ffdec: remove broken TSHandler
    Remove the TShandler code, it is broken when QoS is enabled and ffmpeg provides
    much easier methods for tracking timestamps.
    Simplify pcache joining.
Comment 10 Marc Leeman 2010-10-07 13:53:38 UTC
It doesn't really solve the switching to I-frames after applying the patches on gst-ffmpeg 0.10.11.

Looks like we're looking at a different issue. Odd thing is that, on two virtually identical machines. One machine does seem to exhibit the behaviour more than the other one.

We're trying reproduce more consistently and isolate.
Comment 11 Marc Leeman 2010-10-08 09:27:17 UTC
added log ffmpeg

the video seems to be decoded at 30fps

trying to reproduce with only one stream being decoded; (sink is currently glimagesink)
Comment 12 Marc Leeman 2010-10-14 20:04:18 UTC
seems to be fixed in a full git build; while I only applied the patches you provided.

I'll retry after the pending release.