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 <clem...@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. 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@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
