[FFmpeg-devel] [RFC][PATCH] ticks_per_frame / timebase
Sat Feb 28 11:17:08 CET 2009
Michael Niedermayer wrote:
> On Fri, Feb 27, 2009 at 07:53:58PM +0100, Ivan Schreter wrote:
>> Michael Niedermayer wrote:
>>> On Fri, Feb 27, 2009 at 06:47:42PM +0100, Ivan Schreter wrote:
>> Independent of that, frame rate is computed wrong for field picture stream,
> what is the problem with parser.repeat_pict == 0 to detect that
> (possibly with ticks_per_frame == 2) ?
Nothing in general, works as well. It just looks like a hack to me...
But anyway, patch attached.
>> As for the MOV, my MOV is missing timing info! I just noticed now
> alot of h264 are sadly missing it ...
I think I'll add some logic to generate timestamps in case timing info
is missing on the lines of adding 1+repeat_pict to dts for each frame
and letting output delay undefined. This will work for mov and at least
for progressive H.264 in mpegts, since mpegts has to code both pts and
dts for frames where dts != pts.
Anything speaking against it?
However, interlaced field-picture stream without timing info in mpegts
will be still broken, as the second field of a delayed frame DOESN'T
code pts/dts, even though they are different. I didn't find an
explanation in standard yet and currently don't have any patch to
>> (timing_info_present_flag == 0). So at least in this case, it doesn't work.
>> Attached patch sets ticks_per_frame to 2 only if time_base is specified. If
>> it is unknown, lavf will set it equal to frame rate, so then
>> ticks_per_frame is 1 (default)...
> that would cause problems with interpretation of repeat_pict
True. In that case, we need to do it the other way around: if time base
is undefined, then when defining it, multiply it by ticks_per_frame. I
tried it, but it still doesn't work. The frame rate is still estimated
at fps/2. I'll look at it somewhat more.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 646 bytes
Desc: not available
More information about the ffmpeg-devel