[FFmpeg-cvslog] r17656 - trunk/libavformat/utils.c

[Michael Niedermayer]

On Sat, Feb 28, 2009 at 06:57:54PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
>> On Sat, Feb 28, 2009 at 02:01:11PM +0000, M?ns Rullg?rd wrote:
>>   
>>> cehoyos <subversion at mplayerhq.hu> writes:
>>>
>>>     
>>>> Author: cehoyos
>>>> Date: Sat Feb 28 14:14:46 2009
>>>> New Revision: 17656
>>>>
>>>> Log:
>>>> Improve frame rate guessing for streams with two fields per frame.
>>>>
>>>> Patch by Ivan Schreter, schreter gmx net
>>>>
>>>> Modified:
>>>>    trunk/libavformat/utils.c
>>>>
>>>> Modified: trunk/libavformat/utils.c
>>>> ==============================================================================
>>>> --- trunk/libavformat/utils.c	Sat Feb 28 09:38:33 2009	(r17655)
>>>> +++ trunk/libavformat/utils.c	Sat Feb 28 14:14:46 2009	(r17656)
>>>> @@ -2115,6 +2115,11 @@ int av_find_stream_info(AVFormatContext           
>>>>    int64_t last= last_dts[index];
>>>>              int64_t duration= pkt->dts - last;
>>>>
>>>> +            if (st->codec->ticks_per_frame == 2 &&
>>>> +                st->parser &&
>>>> +                st->parser->repeat_pict == 0)
>>>> +                    duration *= 2;  // two fields are needed per frame
>>>> +
>>>>              if(pkt->dts != AV_NOPTS_VALUE && last != AV_NOPTS_VALUE && 
>>>> duration>0){
>>>>                  double dur= duration * av_q2d(st->time_base);
>>>>       
>>> This broke all H264 tests on FATE by halving the reported frame rate
>>> (and thus PTS values).  Was that intentional?
>>>     
>>
>> no
>> "12.50 tbr, 25 tbn, 50 tbc" is wrong it should be
>> "25 tbr, 25 tbn, 50 tbc"
>> or maybe in some cases
>> "50 tbr, 25 tbn, 50 tbc"
>>
>>   
> I think only the former. For real 50 fps movies, it will be most probably 
> 50/50/100...

yes


>
>> IMHO this commit c/sh ould be reverted until this is investigated and 
>> fixed
>> i still think the original change was correct but the raw h264 is a
>> nasty beast
>> my (completely unverified) hypothesis of the problem is that ffmpeg
>> sets framerates and timebases to 1/25 default, there is no framerate
>> timebase or any timing information in these raw streams ...
>> h264.c then fixes the default timebase to 1/50 to be able to represent
>> field timestamps but the demuxer level timebase is 1/25 and cannot 
>> represent
>> the field timestamps thus ends up returning them in 1/25 units which
>> get corrected by the framerate guessing code that correctly identifies
>> them as fields to 2/25 ...
>>
>>   
> This is what I was afraid of with using ticks_per_frame and repeat_pict for 
> guessing. Having field flag is IMHO safer (but possibly also doesn't 
> address all issues).
>

> BTW, are you sure it was _this_ change, which broke it?

its working since it was reverted


>
>> iam CCing this to ivan so he is aware of it though all people with svn
>> write access should be subscribed to cvslog
>>
>>   
> Well, I'm not. I don't have svn access yet (no response yet from Diego).
>
> Regards,
>
> Ivan
>

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- 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-cvslog/attachments/20090228/dd03212b/attachment.pgp>