[FFmpeg-devel] [PATCH] Fix MPEG-TS seek and frame positions in general
Sat Feb 28 18:06:38 CET 2009
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
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
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.
More information about the ffmpeg-devel