GNOME Bugzilla – Bug 631075
RTP based decoding degrades over time
Last modified: 2010-10-14 20:04:18 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.
What's the previous release that doesn't exhibit the problem?
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
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).
"arrive in time" -> "arrive in order" that is
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.
(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
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.
This should avoid being stuck in hurry up mode. commit 4aa9b97d3fabdbb5a7c63f9543b673dbf29a1965 Author: Wim Taymans <wim.taymans@collabora.co.uk> 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.
this fixes it for me. commit 76d9685202e4443573d71c16b0445cbd3fb59aca Author: Wim Taymans <wim.taymans@collabora.co.uk> 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 <wim.taymans@collabora.co.uk> 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.
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.
added log ffmpeg http://crichton.homelinux.org/~marc/downloads/log.0.error.log.bz2 the video seems to be decoded at 30fps trying to reproduce with only one stream being decoded; (sink is currently glimagesink)
seems to be fixed in a full git build; while I only applied the patches you provided. I'll retry after the pending release.