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

[Ivan Schreter]

Robert Swain wrote:
> 2009/2/28 Ivan Schreter <schreter at gmx.net>:
>   
>> Carl Eugen Hoyos wrote:
>>     
>>> Ivan Schreter <schreter <at> gmx.net> writes:
>>>       
>
>   
>>>>> Maybe ts_packet_pos ?
>>>>>           
>>>> Changed. New patch attached.
>>>>         
>>> The patch breaks regression tests (make test), so not applied.
>>>       
>> Attached also seek regression test patch. Difference is only that now we
>> also get reasonable positions from mpegts.
>>     
>
> After these patches, are there any more outstanding seek-related
> issues (or other issues) that need to be addressed before we make a
> release?
>   
Yes. There are still two outstanding issues:

1) Currently, the position of the packet is just estimated. Thus, we 
cannot really get correct position. MPEG-TS fix fixes getting position 
for TS packets as such, but not frame position in general. If the frame 
consists of several packets, then the last packet position is taken as 
frame position, which is wrong. I posted a patch, which was rejected, 
since it didn't handle the opposite case correctly (several frames in 
one packet). This has been discussed with Michael and he suggested to 
add a new version of av_parser_parse function which gets also packet 
position for "reordering". I already have a patch for this, which I 
wanted to post today, but didn't get to it yet (I have to clean it up a 
little).

2) In general, seeking ignores key frames, at least for MPEG-TS, 
possibly for other formats as well, since read_timestamp function 
returns just some timestamp, not necessarily that of a key frame. We 
need to search for actual key frame to return from seeking function. I 
have a first version of the search function already written for current 
seeking API, but Michael wanted to have one which will work for future 
seeking API as well. Maybe I can simply post this one and later it can 
be extended for new seeking API (to handle several streams at once).

Since currently seeking simply returns some frame, which the format 
deems appropriate for given timestamp (it might be a key frame, but it 
might be not) and position of this frame is returned, 1) was not really 
an issue up to now. When we search for key frame in 2), then 1) is 
important, since we need to return correct position of found key frame.

Note: both patches will cause changes in seek regression test (similar 
to already existing MPEG-TS packet position patch), since 1) corrects 
the positions and 2) corrects returned timestamp to that of a key frame.

> I know this area has been under active development over the past week
> or so and really it should have waited, but as long as you are all
> happy that the issues have been resolved, I think we should be OK. You
> seem to have been very thorough.
>
>   
Unfortunately, it's not yet OK :-(

I'll try to get it fixed this weekend, but I cannot promise for sure.

Regards,

Ivan