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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
