[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set
Fri Feb 20 15:44:25 CET 2009
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
> 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel