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

[Michael Niedermayer]

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

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- 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/03a06c5d/attachment.pgp>