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

[wm4]

On Sat, 28 Jun 2014 08:57:57 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On 27.06.2014, at 20:47, wm4 <nfxjfg at googlemail.com> wrote:
> > 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.
> 
> To be honest I wonder why it matters.
> Also it won't solve all cases. I believe flac packets can contain many seconds of audio, and video packets for slideshows will have similar durations.
> You just won't be able to have matching audio and video time stamps in general.
> I kind of wonder if this is trying to solve a problem with little real relevance while not actually solving it in general.

Apparently it matters to Chromium.

Yes, you can't get perfect results due to the nature of things. But the
current seeking API fails even at things it could do. (And doesn't
consider corner cases. What happens if a seek fails?)

> >>> 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.
> 
> Matroska groups packets together, thus you need to skip packets just to get to the right position even if it has a single stream only.
> Are you sure matroskadec does the skipping per-stream? I would expect it skips until the first sib-packet with the right timestamp, but then returns all.
> Anything else can cause a few issues I think.

Yes, it skips to the packet with the first relevant timestamp, but it
does so for all streams equally (except subtitle streams, for some
reason).

> >> 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?
> 
> Possibly, though a real solution (possibly) also needs part of the code after decoding.