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

[Baptiste Coudurier]

Hi Michael,

On 2/28/2009 7:44 AM, Michael Niedermayer wrote:
> On Sat, Feb 28, 2009 at 03:18:21PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>>
>>> 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"
>>>
>>> IMHO this commit c/sh ould be reverted until this is investigated and fixed
>> I have reverted it for now.
>>
>>> 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 ...
>> Don't those streams have any VUI in the SPS?
> 
> i dont remember but i do know that the ones i looked at had 
> timing_info_present_flag=0 at least
> 
> 
>>> 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 ...
>> That theory sounds plausible.  Do you have any ideas how to fix it?
> 
> change libavformat/raw.c so it uses some safer timebase like 1/90000 or
> 1/1000000, instead of the "default framerate". i did try this already
> yesterday (due to other issues), its just a 2 line change 
> (2nd line needed to keep the codec timebase at 1/25 or the user provided one)
> but it uncovered yet another bug, namely something about a duplicated frame
> at  the begin, that one i assume was hidden because previously the timebase
> was not accurate enough to trigger it ...
>
> i did not investigate further and would surely be happy if others would
> help me with fixing the timestamping code in ffmpeg.c and libavformat

I'm helping, I submitted a patch concerning ffmpeg.c and vsync some time
ago, and I know regression tests didn't pass, I will investigate
further, I explained the situation.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org