[FFmpeg-devel] [PATCH] H.264/AVCHD interlaced fixes

[Ivan Schreter]

Hi Michael,

Michael Niedermayer wrote:
> On Sun, Feb 08, 2009 at 04:06:34PM +0100, Ivan Schreter wrote:
>   
>>
>> Oh, c'mon! I have split the big patch as good as possible. But I don't 
>> have infinitely much time, my small daughter was born a few days ago => 
>> end of hacking. I'd like to have my patches in for the release, though.
>>     
>
> you know that this h264 timestamp issue is one of the more obnoxious and
> complex issues ...
>
> More parsing code is likely not too hard to get into svn, the field combine
> code may be very hard to get in. Basically i must awnser the question if
>   
OK, I'll try to separate the parsing part.

> the alternative of treating fields seperately (which is what h264 wants)
> is really hard enough to justify that we do that hack. And if that hack
> wont bite us, i mean there are unpaired fields and such in the spec ...
>
>   
Alternative would be to modify the application I want to use (kdenlive 
w/ MLT framework) to handle several av_read_frame() calls until a 
picture arrives. Shouldn't be that hard to do.

In that case, however, each second field frame must get the same 
timestamp as first field frame it is paired with. I.e., lavf's utils.c 
must somehow know it is handling the second field of the same frame and 
assign same DTS/PTS as first field (or offset by 1/2 frame duration in 
case of interlaced video).

Would it be OK with you to do it this way? Then, we don't need frame 
combining nor handling of several pictures in same buffer in decode_frame.

If yes, where would you suggest I can safely put additional flags and 
frame number to pass from parser to lavf and where to keep last PTS/DTS, 
so I can assign PTS/DTS to the next field packet in compute_pkt_fields() 
properly?

> also besides the point the parser may not drop fields that arent pairable
>   
OK, I'll consider it. But if you agree with the above, it's going to be 
irrelevant anyway...

Regards,

Ivan