[FFmpeg-devel] [RFC] Many formats return wrong position => seeking problems
Sat Mar 7 21:59:31 CET 2009
On Sat, Mar 07, 2009 at 09:38:38PM +0100, Ivan Schreter wrote:
> Hi Michael,
> Michael Niedermayer wrote:
> > On Sat, Mar 07, 2009 at 05:28:41PM +0100, Ivan Schreter wrote:
> >> Reimar D?ffinger wrote:
> >>> On Sat, Mar 07, 2009 at 03:43:12PM +0100, Ivan Schreter wrote:
> >>>> I'm writing some low-level support for new seeking API. In principle, it
> >>>> works OK now, but many format demuxers in lavf are broken in the sense
> >>>> that they don't return correct packet positions. This is mandatory for
> >>>> new seeking API and for corrections to current seeking API as well.
> >>> Can you please define what "correct position" means? That would make it
> >>> easier to know which are broken and how to fix them (or alternatively
> >>> flame you if the requirements are too restrictive ;-) ).
> >> Well, quite easy:
> >> av_read_frame() returns an AVPacket, containing file position in member
> >> pos. If I reposition the file pointer to this position in the file, I
> >> expect next av_read_frame() to return exactly the same packet (also with
> >> same DTS/PTS, single exception being undefined DTS/PTS after repositioning).
> > in that sense most formats do not have a position, as they will never work
> > once you touch the file pointer, their demuxers rather need various parts
> > of their internal state updated
> > and code that does this exists and works.
> But how do you want to implement the new seeking API then? The algorithm
> you described _requires_ to be able to restart reading from a given
> position. Namely, after we find keyframes in all streams of interest, we
> have to reposition the file pointer to the frame with lowest file
> position and start reading from there. But this requires that positions
> returned from av_read_frame() are valid (transitively requiring demuxers
> to return correct position of packets returned from them).
> I think this should not be that big problem, since those formats in
> question also have the notion of keyframes, when they do synchronize the
> internal state. But at least these keyframes must return correct file
> position and timestamps from av_read_frame(). And this is missing.
All formats that have a index can and should seek puerly by that and not
go over av_read_frame() + repositioning. Its simply a waste of time ...
> As for the code in demuxer to update internal state after file position
> change: currently the seeking routine does this (it seems to usually
> first call the generic seek and then update the state). But I didn't
> find any other means of updating the state. Possibly, a new demuxer
> function is needed to update state after position change during backward
> search for keyframes (we need to reposition the file offset and start
> from that position) and after all keyframes found.
> BTW, I still didn't get any comments from you to the seeking patch I
> posted for pre-review already twice... It effectively implements your
> algorithm for searching for keyframes in several streams.
The code seems to be missing usage of the AVStream.index_entries
the idea is that it should never waste time gathering some information
over av_read_frame() twice.
This way demuxers that fill index_entries should work without av_read_frame()
about the demuxer state, read_seek2() that calls the generic seeking code
can also update the state somehow
also if its more convenient a state reset flush whatever can be added
to AVInputFormat (iam not sure about this though)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel