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

[Aaron Colwell]

On Tue, Jul 1, 2014 at 9:28 AM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
wrote:

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

I'm sorry. I must have misinterpreted what you were saying.


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

I think I agree with you here. I guess my expectation is that when seeking
to a location in the timeline, I'd get all packets from all streams that
have a timestamp >= the seek point modulo snapping to keyframe/audio frame
start. The idea being that the caller receives all the data necessary to
decode what should be rendered at that instant in time. It seems like this
behavior should be independent of how the data is actually laid out in the
file.


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

Yes. I believe this may be a general seeking issue, but we first noticed it
when we tried to tighten up our test coverage with respect to seeking back
to the beginning of the clip. We noticed that we couldn't consistantly get
the FFmpeg code to return us the same set of frames it returned when it
first started playing from the beginning of the file. Depending on the
order of the first audio & first video page, we'd get different results.


> Btw. seeking to 0 will in fact not generally seek to the start,
> files can start with negative timestamps.
>

Understood, but when audio happens to be the second page, then seeking to
the negative timestamp results in the code starting at the second page
instead of the first page eventhough the timestamp for the first video
keyframe is 0.


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

Dale tried to do this with the .zip file he attached. It shows the
situation we have encountered plus includes the ogg file that triggers the
behavior. I may have missed it, but I haven't seen any comments on that
code yet.

Aaron


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>