[FFmpeg-devel] Order of demuxed packets after a seek in an ogg container.
h.leppkes at gmail.com
Thu Jun 26 04:08:46 CEST 2014
On Wed, Jun 25, 2014 at 5:37 PM, Dale Curtis <dalecurtis at chromium.org> wrote:
> 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?
> We're noticing that this is not the case with some ogg files, for which
> I've had to write up a workaround which involves considering the file
> position of the packet (as indicated by AVPacket.pos). Chromium change for
> reference: https://codereview.chromium.org/353563002/
> We discovered this after adding code which uses the lowest packet timestamp
> as seeking point when attempting to restarting playback from the beginning.
> We were expecting a seek in the audio stream to avoid missing keyframe
> corruption of the video stream if the first video timestamp was later in
> the stream. Is this an invalid assumption? Again, here's the Chromium
> change for reference: https://codereview.chromium.org/335273002/
There is no such guarantee.
It'll return all data after the physical position in the file - if the
file is badly interleaved (or for reasons specific to that container
format), anything can happen.
The results look like expected to me, it seeks to the earliest audio
packet and returns any packets after those in the file.
Some formats will behave differently, like mp4, which has all
timestamps decoupled from the actual file data, which allows seeking
streams individually, but many other formats do not easily allow
individually seeking streams, so if whatever stream you seek on
appears later in the file, data before it is not returned.
More information about the ffmpeg-devel