[FFmpeg-devel] Order of demuxed packets after a seek in an ogg container.
Reimar.Doeffinger at gmx.de
Fri Jun 27 20:24:05 CEST 2014
On 27.06.2014, at 19:07, wm4 <nfxjfg at googlemail.com> wrote:
> On Wed, 25 Jun 2014 15:37:11 -0700
> Dale Curtis <dalecurtis at chromium.org> wrote:
>> If av_seek_frame() is used to seek within a specific stream, are future
>> av_read_frame() calls guaranteed to return all packets from all other
>> streams in the container with timestamps after the seek timestamp?
> I don't understand why this wouldn't be guaranteed. It sounds like a
> quality of implementation issue with the ogg demuxer to me. Just
> because it chose a simple way to implement this (apparently returning
> all packets after the destination file position, according to the other
> comments), it doesn't mean it's correct.
Ogg is supposed to be interleaved. If audio with earlier time stamps comes after video with later ones there is either a good reason or the files are broken IMHO.
Neither case seems like a good reason to meddle with what is in the file to me.
> Just intuitively I'd say it should determine the target file position
> for all active streams, then start demuxing from the lowest file
> position of these streams, and skip any packets that are before the
> seek target PTS.
Seek target PTS sounds like a horrible idea, at least for the case when seeking to "nearest keyframe" - either the application skips forward until the exact seeking position and then it can do that just as well as audio, or it doesn't and then you don't want it playing video for possibly minutes before getting an audio packet!
Lastly, considering that all interleaved formats have this "issue", handling/"fixing" this in the demuxer seems like a bad idea either way.
More information about the ffmpeg-devel