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

[Reimar Döffinger]

On Mon, Jun 30, 2014 at 02:01:26PM -0700, Aaron Colwell wrote:
> > 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.

Uh, maybe I misunderstood it, but this has nothing at all to do with
the issue I was discussing.
The problem under discussion from me was that you seek to point A but you
end up getting data from before point A from a different stream,
which generally should not happen with proper interleaving.
What you are describing is that you seek to point A but you get
data only from _after_ point A for some streams, which is completely
fine and expected even in properly interleaved streams and worse,
can't be fixed by the suggested solution of _dropping_ packets.
Also it seems you only care about seeking to the start, there is
a certain chance this is just a bug, because I remember those symptoms
happening with ogg before and they have been a bug then.
Btw. seeking to 0 will in fact not generally seek to the start,
files can start with negative timestamps.
If you want a solution (and I agree that sharing it between projects
is a good idea), the first step would be to describe the problem
so that we actually try to fix the right thing.
An example that works with ffplay or ffmpeg might be best.