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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
