[FFmpeg-devel] [RFC] Many formats return wrong position => seeking problems

[Michael Niedermayer]

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()
useage.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090307/1da73699/attachment.pgp>