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

Aaron Colwell acolwell at chromium.org
Mon Jun 30 23:01:26 CEST 2014

On Fri, Jun 27, 2014 at 11:47 AM, 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.

Ogg is "interleaved" at the page level and by "end timestamp" so weird
situations can occur where the page that contains the seek point actually
has pages before it that cover the same part of the timeline. I think this
situation can happen even under the best muxing practices for Ogg. I think
it is just a property of the decision to interleave at the page level
instead of at the frame level.

I think the logic that finds the page for a specific stream is fine, but I
think once it has found that page, it needs to walk back a page or more to
make sure that none of the previous pages also contain data for the desired
seek point. If a previous page does, then it should be considered the
starting page instead of the one that actually contains the requested
stream. I think this would provide consistant behavior with more
traditional interleaved formats. The specified stream is used to determine
the actual seek timestamp, but the demuxer makes sure it always starts at a
point where frames from all streams that are after that timestamp are

> I'd see rather a hack in lavf to deal with this, than in Chromium + N
> other projects.
I would also like to see this fixed upstream so we don't have to have our
own workaround in Chromium. I'm pretty sure the problems we are seeing
affect all ffmpeg based players that seek back to 0 where the video page is
first and the audio has some samples trimmed from the front. From Ogg's
point of view the audio page doesn't need to be first, but because FFmpeg
generates negative timestamps for trimmed frames it creates a situation
where the actual page layout can differ from what FFmpeg considers the
first sample in the timeline. ISTM the FFmpeg code is in the best position
to deal with this instead of having the caller have to worry about it.


More information about the ffmpeg-devel mailing list