[FFmpeg-devel] [PATCH] Fix MPEG-TS seek and frame positions in general

[Ivan Schreter]

Michael Niedermayer wrote:
> On Tue, Feb 24, 2009 at 09:13:24PM +0100, Ivan Schreter wrote:
>   
>> [...]
>> I made a simple routine av_find_keyframe() which consumes read_timestamp 
>> function to position the stream to a defined position and then finds the 
>> position and DTS of the key frame using av_read_frame() calls. Then, 
>> I've replaced all read_timestamp calls with this. It does work, but I 
>> didn't get it clean yet, so seek regression doesn't work yet (it hangs 
>> for one format). I suppose, the reason is some bug in handling border case.
>>
>> Shall I clean it up and prepare a patch for that?
>>     
>
> above does not sound entirely correct.
>
> what we need is first to let the existing read_timestamp / binary search thing
> do its job to find the position in the stream with the wanted timestamp
> this is O(packet_distance * log filesize)
>
> 2A.
> then once this byte position in the file is found do the keyframe search using
> av_read_frame() this would produce one byte position for each stream where
> there is the next keyframe.
> O(keyframe distance)
>
> 2B.
> like 2A just backward, and because there is no backward demuxing function
> search for all keyframes with av_read_frame() begining at -1024 bytes
> then is none found -2048 (stoping at -1024) then -4096 (stoping at -2048)
> and so on until each stream has a found keyframe.
> O(keyframe distance)
>
> 3.
> The new (unfinished) API provides us with a  target timestamp the user wants
> to seek to and optional max/min timestamps that bound the range acceptable to
> her
> the timestamp from the user as well as the limits represent pressentation
> times at which all streams can be decoded
> the possible byte positions to seek to match the (2*number streams) keyrames
> found, each of them will allow full presentation once each stream contained
> a keyframe, it is its time that has to be used to select where to start.
> O(number streams)
>
> example:
> target time=5 no min/max
> time:        0123456789
> stream1:      K    K
> stream2:        K    K
>
> if we would seek to the byte position for the first keyframe in stream 1
> we could start presenting all streams at pts=3
> if we would seek to the byte position for the second keyframe in stream 1
> we could start presenting all streams at pts=8
> if we would seek to the byte position for the first keyframe in stream 2
> we could start presenting all streams at pts=6
>
> pts=6 is closest to the requested point from the user, so seeking to the
> first keyframe we found in stream 2 is the best choice
> if OTOH the user provided us with a target time=5 max=5 then 
> the first keyframe in the first stream would have been the correct choice
>
>
>
> [...]
>   
>>> also for the new seek API we need to not only find one keyframe of one
>>> stream but one keyframe for each active stream and in both directions
>>> then from this decide where to seek to. Sounds nasty but shouldnt be
>>> because it doesnt cost to consider more streams ...
>>>
>>>       
Attached is the first version of the seeking patch to search for 
keyframes in the way you suggested (for functional pre-review). It 
cannot be committed yet, since it relies strongly on having proper frame 
positions (other subthread), but in principle it works (there is some 
regression due to corrected keyframe search and corrected keyframe 
positions, but I didn't post it, since it's not yet definite).

Future seeking API can then directly use the new function to find 
keyframes in several streams at once.

BTW, current API seems to work with DTS. A flag could be added to 
consider PTS instead of DTS (or simply change the whole thing to seek to 
PTS always).

Please give me your opinions about it.

Regards,

Ivan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: seek.patch
Type: text/x-patch
Size: 8985 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090301/54579191/attachment.bin>