[Ffmpeg-devel] [PATCH] fix frame duration computation in find_stream_infos

[Michael Niedermayer]

Hi

On Fri, Mar 09, 2007 at 09:51:44PM +0100, Baptiste Coudurier wrote:
> Hi
> 
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Fri, Mar 09, 2007 at 05:42:48PM +0100, Baptiste Coudurier wrote:
> >> Hi
> >>
> >> $subj.
> >>
> >> I guess there is a typo here. Is it correct ?
> >> last_dts should be updated when duration is present.
> > 
> > no its no typo, this improves accuracy IIRC
> > 
> 
> ok, I misunderstood the code then.
> 
> wrong_frame_rate.mp4 in incoming:
> Stream #0.0(eng): Video: mpeg4, yuv420p, 352x288, 49.67 fps(r)
> 
> should be 16.38 (quicktime),

just because QT says it, doesnt make it correct ...
16.38 does not look like a likely framerate at all
also the 20 first durations have a average framerate
of 16.57 their strict minimum exact frame rate is 1000

the reason why the code fails to choose 16.57 as a guess
is that it doesnt test every possible fractional framerate
but just simple fractins, and here 149/9 = 16.555... is "better"
approximation then 199/12=16.583333 but the code doesnt try
149/9 but rather just 149/3 so it ends with 49.67

why does it not test every possible fraction? well because
if it did some files wouldnt get 30fps but rather 30.00234
even though the file really contains 30fps video its timbase
just cannot represent the timestamps exactly and this cannot
be distingushed from the first 20 frames

so to fix this the first question is what is the true base
framerate of the file? 16.38? 16.57? 1000? to awnser this
all the durations would need to be considered and even then
there could be some debate left for example if the file is almost
representable with a 1/16.57 timebase but not exactly ...

from the first 20 durations which is all the detection code
sees the correct awnser would be 16.57 to make it choose this
rate the get_std_framerate() will have to "return" 16.57 for one
of its calls

to make the code not fail by choosing a multiple rate like 49.67
get_std_framerate() would always have to return X/Y if it returned X
for one of its calls that shouldnt be too hard to fix (patch welcome)

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070309/da89a7ad/attachment.pgp>