[FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

James Almer jamrial at gmail.com
Tue Sep 6 05:00:09 EEST 2016

On 9/5/2016 10:04 PM, James Almer wrote:
> On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
>> On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
>>> From: Clément Bœsch <clement at stupeflix.com>
>>> These adjusted codec fields do not seem to be in use anymore and prevent
>>> the convert of ffmpeg*.c to codecpar.
>>  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
>> fails, no output anymore
>> ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
>> the output now has 600fps
> Even with this code in place the resulting stream in the avi is reported
> as 100 fps. And with or without the code, the resulting files play the
> same with the players i tried.
> mpc-hc suffers from choppy playback with both files due to tons of dropped
> frames per second, and WMP directly refuses to play it. Only ffplay and
> mpv play both fine.

So apparently libavformat's av_dump_format() reports the stream time base
as fps as well, at least with these files, which explains the odd 100 and
600 fps.
libav's av_dump_format() in contrast correctly reports the fps as 25 in

Both check st->avg_frame_rate to print the fps values.

>> ./ffmpeg -i ~/tickets/236/fcp_export8.mov -codec copy -map 0 out.mov
>> something goes terribly wrong with the timecode tracks
>> "fps 2997 is too large"
>> If you want more cases that this breaks, it should be easy to find
>> i think fate does not test stream copy very well
>> [...]
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

More information about the ffmpeg-devel mailing list