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

[Ivan Schreter]

Michael Niedermayer wrote:
> On Wed, Feb 11, 2009 at 11:10:52AM +0100, Ivan Schreter wrote:
>   
>> [...]
>>     
>> If I understand you correctly (including previous mails), you'd like to 
>> see the following: The packet position is passed to parser function by 
>> extending the parser context by two fields: one passing the position of 
>> current packet to the parser (currently only buffer and size is passed) 
>> and one returning the position of packet which contained the startcode. 
>> The parser should take care of filling it (or not). If filled, it will 
>> be used, if not, current (broken) last packet position can be used as 
>> fallback, until all parsers do. Alternatively, one could extend parser 
>> function by extra parameter with in/out position (in = current packet 
>> pos, out = first frame packet pos). This would require change in all 
>> parsers, though, making the patch large, OTOH making the aforementioned 
>> fallback unnecessary (it will work so implicitly). Which one do you want?
>>     
>
> av_parser_parse() takes dts & pts currently, it should also take pos and then
> do pretty much the same with pos that it does with dts/pts
>
>   
I've put together a series of patches adding exact frame position in the 
stream.

avcodec_framepos adds av_parser_parse2(), which gets also the position, 
which is then passed to the actual parser. If the parser wants to, it 
can store it, do whatever with it and return correct position later. 
Alternatively, we could store it on the context directly in lavf and 
save extra function version.

avformat_framepos passes current packet position to the parser and 
consumes the position from the parser, if any. As fallback, current 
packet position is used (it is OK for formats having one packet per frame).

h264_framepos is the implementation for H.264 parser. It will store 
position of the first packet in the context and then return this 
position after the whole frame is parsed. Should more than one frame lie 
in the same packet, all of them will get the same packet position. I 
suppose something analoguous will be needed for MPEG video.

regress_framepos updates seek regression test. Now even more seek 
results do have a frame position (which was missing before).

What do you think?

BTW, I was trying to get some sense out of the current parser code 
regarding ff_fetch_timestamp and use frame_offset instead of passing the 
position, but I must admit, I don't quite understand it. Frame offsets 
stored on AVCodecParserContext diverge from real frame positions 
considerably for MPEG-TS, since they seem not to take any startcodes or 
other overhead into account. Correcting them breaks other things.

Regards,

Ivan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: avcodec_framepos.patch
Type: text/x-patch
Size: 3141 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090228/d4414911/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: avformat_framepos.patch
Type: text/x-patch
Size: 2504 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090228/d4414911/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264_framepos.patch
Type: text/x-patch
Size: 1787 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090228/d4414911/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regress_framepos.patch
Type: text/x-patch
Size: 4126 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090228/d4414911/attachment-0003.bin>