[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set

[Michael Niedermayer]

On Fri, Feb 20, 2009 at 03:30:16PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
> > On Fri, Feb 20, 2009 at 12:00:35PM +0100, Ivan Schreter wrote:
> >   
> >> Michael Niedermayer wrote:
> >>     
> >>> the parser also can set timetamps, they as well are in a container based
> >>> timebase
> >>>   
> >>>       
> >> Ok, then here the next patch to handle frame duration properly. Namely, for 
> >> interlaced videos, it uses frame duration of 3600 (for 50i) instead of 
> >> 1800, since it computes it from framerate. Since the parser can compute 
> >> timestamps, it can also compute duration...
> >>
> >> Actual duration computation will follow in H.264 parser patch to compute 
> >> timestamps (it's actually already there in old version of the patch, but 
> >> not propagated to lavf).
> >>
> >> I'll clean up the patches for the parser and post them later today 
> >> (dependent on this patch, though).
> >>     
> >
> > this patch looks wrong, we already have a repeat_pict specifying duration
> >
> >   
> Yes, we do. Unfortunately, you can't specify half-frame duration (of 
> display frame) for field pictures, except you'd set repeat_pict to -1 to 
> subtract half a frame, which is possibly not what is desired. The 

i see no problem
repeat_pict=0 for a field could be duration = 1 field
repeat_pict=0 for a frame could be duration = 2 fields
of course repeat_pict=-1 also could be considered


> solution giving parser the control of frame duration seems cleaner to me.

considering that your code depends on a 90khz clock which is not guranteed
and that repeat_pict must be fixed and unambigously specified for fields
anyway i dont see any advantage of ignoring a existing field ans introducing a
new one


[...]
> BTW, current solution has anyway a problem: First of all, repeat_pict 
> during parse time is one (transport stream) frame too late (as it comes 
> from last decode, not from parse). Second, first parsed frame will have 
> duration of 0, which is also incorrect (since frame rate and related 
> stuff are not set yet, I suppose).

i dont know what you talk about


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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20090220/cacd1819/attachment.pgp>