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

[Michael Niedermayer]

On Mon, Feb 09, 2009 at 01:01:53AM +0100, Ivan Schreter wrote:
> 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.

we should support 2 fields in one buffer either way
what i want is correct and full support of h264 in h222 timestamp
interpolation


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090209/90912d50/attachment.pgp>