GNOME Bugzilla – Bug 649372
ffdec: make the time threshold to skip to next keyframe configurable
Last modified: 2011-05-06 11:24:26 UTC
Created attachment 187187 [details] [review] ffdec: make the time threshold to skip to next keyframe configurable This patch makes the time threshold to skip to next keyframe configurable. This may be required in the case where a pipeline setup takes more than two seconds between the moment where a live source starts and a decoder processes the first frame.
I think that code should be removed completely. As the FIXME above says, this is something the demuxer has to do based on the knowledge of the container and the QoS events.
If preferred, here's an alternative patch that does that. Not quite sure it wouldn't possibly cause regressions though, in cases where performance is *just* enough and it would never catch up where it could with the skip code. A corner case though maybe.
Created attachment 187199 [details] [review] Alterntive patch, which removes the resync code path
Please add some more to the commit message... like why this code should be removed (demuxers should handle this and doing it in the decoder who has absolutely no knowledge about future keyframes is wrong)
Created attachment 187309 [details] [review] Add a bit more explanation to the commit message Not sure what else to add. Is this what you had in mind ?
commit 920bfb0da20f939f13b1742946af8fa3253723a9 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed May 4 17:33:03 2011 +0300 ffdec: do not try to resync to the next keyframe when late A keyframe may be quite a while in the future, and the decoder has no way of knowing this. A poor decision could mean quite some time with no video output. This decision should be left to the upstream element: a demuxer might know about incoming keyframes, or some other element might be able to request a keyframe. Fixes bug #649372.