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

[Michael Niedermayer]

On Tue, Feb 10, 2009 at 03:29:51PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
> > On Mon, Feb 09, 2009 at 09:39:27PM +0100, Ivan Schreter wrote:
> >   
> >> Michael Niedermayer wrote:
> >>     
> >>> On Mon, Feb 09, 2009 at 01:01:53AM +0100, Ivan Schreter wrote:
> >>>   
> >>>       
> >>>> [...]
> >>>> 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).
> >>>>
> >>>> [...]
> >>>>     
> >>>>         
> >>> we should support 2 fields in one buffer either way
> >>> what i want is correct and full support of h264 in h222 timestamp
> >>> interpolation
> >>>
> >>>
> >>>   
> >>>       
> >> In that case, is the above the solution (at least for common case)? If 
> >> yes, I'll send you a patch. I suppose it should be enough - DTS/PTS 
> >> computation for full frames does work and even in field-picture stream, 
> >> current formulas for first field of a frame still hold - problematic is 
> >> just second frame. Right?
> >>     
> >
> > as ive said already, you have a guranteed timestamps once every 0.7 seconds
> > this can be always on the first field or always on the second or randomly
> >
> > the current code cannot interpolate timestamps for h264, building code on
> > the assumtation that the current would work for the first field seems
> > strange. But you can point me to the section of H222/264 that supports
> > your theory about conseutive field timestamp relation.
> >
> >   
> I didn't find any section about PTS/DTS or for the sake of it about 
> timestamps in general (except clock timestamp in SEI picture timing) in 
> H.264 standard. Regarding field pictures in H.222.0 standard, a PTS is 
> assigned to "presentation unit", which may be a frame or field picture. 

> A note to field pictures says, though: "... for field pictures the 
> presentation time refers to the first field picture of the coded frame". 
> I infer, the timestamp for the second field picture is thus equal to the 
> first field picture in same frame.

This note is about mpeg2.


> 
> Did you find anything in standard which describes how PTS/DTS for field 
> pictures is to be computed? I didn't and I searched quite hard.

2.7.5 explains the restrictions upon which you can calculate timestamps.

you will have to implement this or you waste your time, iam not interrested
in your hypothetical talk about what fields and timestamp relation there
should be.


[...]
> But again, I'm thinking practical: A patch which addresses the problem 
> 95% (and surely doesn't break anything) is better than no solution at 
> all.
> It can be later extended/corrected to handle it 100%, but I didn't 

no your random guessing is not a 95% solution that can be extended its a
guess that works for the files from a single encoder (the one you have).
and likels its more a -5% solution that is it moves us away from anything
correct and that full support would first involve removing that again.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/20090211/9d412f00/attachment.pgp>