[FFmpeg-devel] [PATCH 3/3] [RFC] mpegts: Support seeking based on stream timestamps.

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Sep 28 19:58:42 CEST 2014


On Sun, Sep 28, 2014 at 03:50:20PM +0200, wm4 wrote:
> > > The only "hack" about this is that libavformat doesn't provide a proper
> > > flush function. It could be easily added.
> > 
> > Do you volunteer? :-)
> 
> Sure. I was already wondering how to implement it. One issue is with
> which formats such an API makes sense at all, and whether there is a
> need for a AVInputFormat.flush callback.

Yes, you could imagine a crazy implementation like for MOV that actually
looks up the current byte position in the index and calculates a
new pts to start playing from, but that sounds a bit insane.
One definition I could think of is that it basically only needs
to work for demuxers that implement the read_timestamp function.
If a demuxer implements it that means it can make sense of the data
it gets after seeking it a random byte offset.

> Currently, I'm thinking it would be fine if the implementation only
> drops buffers, with no further sanity checks. (It would just break the
> data stream when used with formats which don't/can't support it.) I'm
> wondering whether the function should make efforts to flush the
> AVIOContext too.

Maybe getting some inspiration and possibly reusing the code that uses
read_timestamp would work?
I guess you could just call that function to drop some internal state,
but that would end up losing at least one packet I think...
I wonder how the generic read_timestamp code actually works at all
without such a flush function? Might there be some subtle bugs in that
code?


More information about the ffmpeg-devel mailing list