[FFmpeg-devel] Order of demuxed packets after a seek in an ogg container.

[wm4]

On Fri, 27 Jun 2014 20:24:05 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> 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:
> > 
> >> Hi,
> >> 
> >> 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.

I'd see rather a hack in lavf to deal with this, than in Chromium + N
other projects.

> 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!

AFAIK matroskadec.c does it this way. It seeks "somewhere" into the
file according to the index, and then skips packets until the right
target position is found.

> Lastly, considering that all interleaved formats have this "issue", handling/"fixing" this in the demuxer seems like a bad idea either way.

You mean this could be in utils.c too?