[FFmpeg-devel] [PATCH] ffmpeg_opts: remove lowres check

Anton Khirnov anton at khirnov.net
Sun Jan 24 15:44:31 EET 2021


Quoting James Almer (2021-01-23 19:38:57)
> 
> If i apply the following, the output of three remuxing (codec copy) 
> tests change
> 
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 8ac6bc04b8..0cdf3156a6 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4110,13 +4110,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >              ret = add_coded_side_data(st, st->internal->avctx);
> >              if (ret < 0)
> >                  goto find_stream_info_err;
> > -#if FF_API_LOWRES
> > -            // The decoder might reduce the video size by the lowres factor.
> > -            if (st->internal->avctx->lowres && orig_w) {
> > +
> > +            // The decoder might change the video size.
> > +            if (orig_w && orig_h) {
> >                  st->codecpar->width = orig_w;
> >                  st->codecpar->height = orig_h;
> >              }
> > -#endif
> >          }
> 
> What i assume happens is that without this change st->codecpar is being 
> populated with dimensions set by whatever decoder was used during 
> probing, and then propagated to the muxer codecpar, whereas with this 
> change the dimensions from the source container are kept unchanged.
> 
> Case in point
> 
> > diff --git a/tests/ref/fate/cbs-vp9-vp90-2-05-resize b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > index 8f036bba81..37a37ff1ea 100644
> > --- a/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > +++ b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
> > @@ -1 +1 @@
> > -6838422ebb45df353a2bad62b9aff8e9
> > +1c39300b93fe110e1db30974e5d3479d
> > diff --git a/tests/ref/fate/redcode-demux b/tests/ref/fate/redcode-demux
> > index 45119ec71e..c6e0b6de5c 100644
> > --- a/tests/ref/fate/redcode-demux
> > +++ b/tests/ref/fate/redcode-demux
> > @@ -1,7 +1,7 @@
> >  #tb 0: 1/240000
> >  #media_type 0: video
> >  #codec_id 0: jpeg2000
> > -#dimensions 0: 2048x1152
> > +#dimensions 0: 4096x2304
> >  #sar 0: 0/1
> >  #tb 1: 1/240000
> >  #media_type 1: audio
> > diff --git a/tests/ref/fate/wtv-demux b/tests/ref/fate/wtv-demux
> > index abe85a4ab6..39d395699c 100644
> > --- a/tests/ref/fate/wtv-demux
> > +++ b/tests/ref/fate/wtv-demux
> > @@ -3,7 +3,7 @@
> >  #tb 0: 1/10000000
> >  #media_type 0: video
> >  #codec_id 0: mpeg2video
> > -#dimensions 0: 720x576
> > +#dimensions 0: 704x480
> >  #sar 0: 64/45
> >  #tb 1: 1/10000000
> >  #media_type 1: audio
> > -- 
> 
> I personally think that for a codec copy scenario (Where you could have 
> no decoders at all), this behavior is more consistent. Some samples have 
> different resolution per frame, like that vp9 one, and a decoder could 
> return the one from the last frame probed.

I tend to agree, though in the specific case of wtv-demux the container
dimensions seem broken. But then again I don't think it's the job of
find_stream_info() to engage in such heuristics.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list