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

[Måns Rullgård]

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?

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

-- 
M?ns Rullg?rd
mans at mansr.com