[Ffmpeg-devel] [BUG] wrong fps in r_frame_rate ?
Sat Dec 9 03:24:47 CET 2006
Michael Niedermayer a ?crit :
> On Sat, Dec 09, 2006 at 12:51:27AM +0100, Baptiste Coudurier wrote:
>> Michael Niedermayer a ?crit :
>>> On Fri, Dec 08, 2006 at 04:08:14PM +0100, Baptiste Coudurier wrote:
>>>> latest svn. ffmpeg -i wrong_fps.mpg
>>>> Seems that stream 0 comes from film source: 25.00 (25/1) -> 24.75 (99/4)
>>>> Input #0, mpeg, from 'wrong_fps.mpg':
>>>> Duration: 00:00:04.3, start: 0.552822, bitrate: 15583 kb/s
>>>> Stream #0.0[0x1e0]: Video: mpeg2video, yuv422p, 720x608, 15000 kb/s,
>>>> 24.75 fps(r)
>>>> Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, 192 kb/s
>>>> Stream #0.2[0x1c1]: Audio: mp2, 48000 Hz, stereo, 192 kb/s
>>>> Must supply at least one output file
>>>> wrong_fps.mpg on mplayerhq as usual. File should be 25fps.
>>>> in libavformat/utils.c if I remove || CODEC_ID_MPEG2VIDEO, or revert
>>>> commit r6345, it is correctly detected.
>>> neither is acceptable, the code should be executed
>>> find another solution :)
>>> also it might be interresting if you would dump the timestamps for the
>>> frames which are used in the r_frame_rate calculation ...
>> Ok that commit broke many more files than it solved. Can we revert it ?
> no because this isnt true, the code before should have failed for pretty much
> all telecined mpeg files
I would prefer not to troll here, but I remember last time we were
talking about policy, it was said that a commit should not break working
scenario whatever it was, and that instead a clean a working for both
solution should be commited.
If the sample I supplied is broken, then Im ok to leave this but if not,
that file should be prefered over groundhog.vob, else this is a
regression, and IMHO not acceptable.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
More information about the ffmpeg-devel