| Message ID | 20160905144152.27460-1-u@pkh.me |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: > From: Clément Bœsch <clement@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 ./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 [...]
On Mon, Sep 05, 2016 at 05:41:25PM +0200, Michael Niedermayer wrote: > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch <clement@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 > > ./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 Thanks. Such fate tests are likely not very hard to add and would be very welcome.
On Mon, Sep 05, 2016 at 05:49:10PM +0200, Clément Bœsch wrote: > On Mon, Sep 05, 2016 at 05:41:25PM +0200, Michael Niedermayer wrote: > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote: > > > From: Clément Bœsch <clement@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 > > > > ./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 > > Thanks. Such fate tests are likely not very hard to add and would be very > welcome. ok, ill see if i can add tests for these thx [...]
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@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. > > ./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 >
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@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 >> >
On Mon, Sep 05, 2016 at 10:04:35PM -0300, 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@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. that seems to be a regression since 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 IIRC the intended timebase is 1/50 for this kind of content (allowing the support of interlaced and field duplicated content to appear later) > And with or without the code, the resulting files play the > same with the players i tried. Higher framerates / finer timebases need noticably more space to be stored in avi, thats not the case for other formats and thats one reason why avi is treated as a special case. ill try to look tomorrow why its 100fps since the previous codecpar patches. Though 100fps is not nearly as bad as 600fps 600 has ~6 times the overhead Thanks [...]
On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote: > On Mon, Sep 05, 2016 at 10:04:35PM -0300, 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@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. > > that seems to be a regression since > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 > > IIRC the intended timebase is 1/50 for this kind of content > (allowing the support of interlaced and field duplicated content to > appear later) > > > > And with or without the code, the resulting files play the > > same with the players i tried. > > Higher framerates / finer timebases need noticably more space to > be stored in avi, thats not the case for other formats and thats > one reason why avi is treated as a special case. > > ill try to look tomorrow why its 100fps since the previous > codecpar patches. Though 100fps is not nearly as bad as 600fps > 600 has ~6 times the overhead This regression is caused by ticks_per_frame beiing incorrect Ill send a patch to fix this [...]
diff --git a/ffmpeg.c b/ffmpeg.c index d858407..9516b2d 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -2910,48 +2910,6 @@ static int transcode_init(void) enc_ctx->bits_per_raw_sample = dec_ctx->bits_per_raw_sample; enc_ctx->time_base = ist->st->time_base; - /* - * Avi is a special case here because it supports variable fps but - * having the fps and timebase differe significantly adds quite some - * overhead - */ - if(!strcmp(oc->oformat->name, "avi")) { - if ( copy_tb<0 && ist->st->r_frame_rate.num - && av_q2d(ist->st->r_frame_rate) >= av_q2d(ist->st->avg_frame_rate) - && 0.5/av_q2d(ist->st->r_frame_rate) > av_q2d(ist->st->time_base) - && 0.5/av_q2d(ist->st->r_frame_rate) > av_q2d(dec_ctx->time_base) - && av_q2d(ist->st->time_base) < 1.0/500 && av_q2d(dec_ctx->time_base) < 1.0/500 - || copy_tb==2){ - enc_ctx->time_base.num = ist->st->r_frame_rate.den; - enc_ctx->time_base.den = 2*ist->st->r_frame_rate.num; - enc_ctx->ticks_per_frame = 2; - } else if ( copy_tb<0 && av_q2d(dec_ctx->time_base)*dec_ctx->ticks_per_frame > 2*av_q2d(ist->st->time_base) - && av_q2d(ist->st->time_base) < 1.0/500 - || copy_tb==0){ - enc_ctx->time_base = dec_ctx->time_base; - enc_ctx->time_base.num *= dec_ctx->ticks_per_frame; - enc_ctx->time_base.den *= 2; - enc_ctx->ticks_per_frame = 2; - } - } else if(!(oc->oformat->flags & AVFMT_VARIABLE_FPS) - && strcmp(oc->oformat->name, "mov") && strcmp(oc->oformat->name, "mp4") && strcmp(oc->oformat->name, "3gp") - && strcmp(oc->oformat->name, "3g2") && strcmp(oc->oformat->name, "psp") && strcmp(oc->oformat->name, "ipod") - && strcmp(oc->oformat->name, "f4v") - ) { - if( copy_tb<0 && dec_ctx->time_base.den - && av_q2d(dec_ctx->time_base)*dec_ctx->ticks_per_frame > av_q2d(ist->st->time_base) - && av_q2d(ist->st->time_base) < 1.0/500 - || copy_tb==0){ - enc_ctx->time_base = dec_ctx->time_base; - enc_ctx->time_base.num *= dec_ctx->ticks_per_frame; - } - } - if ( enc_ctx->codec_tag == AV_RL32("tmcd") - && dec_ctx->time_base.num < dec_ctx->time_base.den - && dec_ctx->time_base.num > 0 - && 121LL*dec_ctx->time_base.num > dec_ctx->time_base.den) { - enc_ctx->time_base = dec_ctx->time_base; - } if (!ost->frame_rate.num) ost->frame_rate = ist->framerate;
From: Clément Bœsch <clement@stupeflix.com> These adjusted codec fields do not seem to be in use anymore and prevent the convert of ffmpeg*.c to codecpar. --- ffmpeg.c | 42 ------------------------------------------ 1 file changed, 42 deletions(-)