[FFmpeg-devel] [RFC][PATCH] ticks_per_frame / timebase

[Michael Niedermayer]

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:
>>   
>>> Ivan Schreter wrote:
>>>     
>>>> Michael Niedermayer wrote:
>>>>         
>>>>> On Fri, Feb 27, 2009 at 09:54:36AM +0100, Ivan Schreter wrote:
>>>>>               
>>>>>> Michael Niedermayer wrote:                       
>>>>>>> good, ive applied it, if you find more regressions please tell me
>>>>>>>
>>>>>>>                             
>>>>>> TS works without problem.
>>>>>>
>>>>>> However, there is a regression with MOV. I tried to decode trailer for 
>>>>>> movie "9", which is H.264 progressive 23.98 fps, but it detects it as 
>>>>>> 11.99 fps:
>>>>>>                     
>>>>> that happens because of local changes in your tree, i suspect the hunk
>>>>> to the r_frame_rate code i rejected
>>>>>
>>>>>               
>>>> I looked at the changes before reporting it. But you are right, there 
>>>> was one hunk where I removed H264 from tb_unreliable. This was the 
>>>> reason.
>>>>
>>>> OTOH, when reverting this hunk, interlaced field-picture H.264 stream is 
>>>> detected at 2*fps... I'll check it later, but I don't think it's because 
>>>> of my local changes (only seeking changes are there).
>>>>
>>>>         
>>> So, now I looked at it. The problem is, the information repeat_pict and 
>>> ticks_per_frame is not enough to determine frame duration for 
>>> tb_unreliable H.264 stream.
>>>
>>> So we have following values for these MPEG-TS H.264 streams:
>>>
>>> Progressive: ticks_per_frame == 2, repeat_pict == 1, dts deltas == frame 
>>> duration.
>>> Interlaced, field-pictures: ticks_per_frame == 2, repeat_pict == 0, dts 
>>> deltas == 1/2 frame duration.
>>> Interlaced, top-bottom pictures: ticks_per_frame == 2, repeat_pict == 1, 
>>> dts deltas == frame duration.
>>>
>>> All of these use timebase 2*fps.
>>>
>>> However, for H.264 MOV stream (progressive) we have timebase == fps!
>>>     
>>
>> nope, thats whats printed, but a av_log() in h264.c shows the timebase
>> is 2*fps for my sample
>>   
> Independent of that, frame rate is computed wrong for field picture stream, 

yes
what is the problem with parser.repeat_pict == 0 to detect that
(possibly with ticks_per_frame == 2) ?


> since only field durations are taken into account. So I think the patches 
> for field flag should be applied (or it must be fixed in a different way, 
> but how?).

parser.repeat_pict should be sufficient to identify fields.
or in what case is it not?


>
> As for the MOV, my MOV is missing timing info! I just noticed now 

alot of h264 are sadly missing it ...


> (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

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

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/20090227/e1580f09/attachment.pgp>