GNOME Bugzilla – Bug 705058
mpegvideoparse: Should only output from keyframe/sequence after flush
Last modified: 2016-05-30 00:08:36 UTC
When a flush happens (like after a flushing seek), mpegvideoparse will no longer wait for next I-frame (or sequence header) before pushing. Right now it only checks if it got the config (which does not get resetted when flushing if obtained from the stream) and if so pushes out everything it receives (which might not start from an I-frame).
Marking as blocker since: 1) It causes artefacts with some decoders 2) Pushes out data that will be processed... and discarded. This increases the delay until first frame decoded (when scrubbing/seeking).
Can you provide a file on which this happens?
Demoting
Created attachment 328683 [details] [review] mpegvideoparse: wait for keyframe after flushing seek
We don't do this in other parsers either, or demuxers. And decoders also happily output things from before a keyframe (just not with perfect frames being decoded).
Just fixed the title. It sounded like if the parser was doing so, and that it was a bug.
Note that it would be nice to check if we do re-send the sequence though (that we do at least in H264 now, because most decoder completely destroy their state and forget about the headers on flush).
The original title was fine btw, there's a difference between 'xyz: outputs' and 'xyz: output', but thanks for clarifying :) I think sequence headers will always be in the caps once available, so there shouldn't be a need to re-send it in-stream, but didn't confirm (with h264 it's only a problem because of the different stream-formats and because we don't put this info into the caps in byte-stream format).