[FFmpeg-devel] [PATCH 1/3] lavc/avcodec: Add caps for the support of variable dimension encoding

Linjie Fu fulinjie at zju.edu.cn
Mon Jun 8 18:10:55 EEST 2020


> From: "Anton Khirnov" <anton at khirnov.net>
> Sent Time: 2020-06-08 18:50:43 (Monday)
> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
> Cc: 
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavc/avcodec: Add caps for the support	of variable dimension encoding
> 
> Quoting Linjie Fu (2020-06-08 10:58:03)
> > And declare AV_CODEC_CAP_VARIABLE_DIMENSIONS for rawvideo and
> > wrapped_avframe.
> > 
> > Signed-off-by: Linjie Fu <linjie.fu at intel.com>
> > ---
> >  doc/APIchanges               | 3 +++
> >  fftools/cmdutils.c           | 2 ++
> >  libavcodec/avcodec.h         | 4 +++-
> >  libavcodec/codec.h           | 5 +++++
> >  libavcodec/rawenc.c          | 1 +
> >  libavcodec/version.h         | 2 +-
> >  libavcodec/wrapped_avframe.c | 1 +
> >  7 files changed, 16 insertions(+), 2 deletions(-)
> 
> During the last iteration, I asked how is this preferable to just making
> a new encoder instance. Don't think I got a sufficient reply.

Thanks Anton for the remind, indeed making a new encoder instance would be
more general and suitable for all encoders, with resolution changing in key
frames.

In this patch set, I prefer to restrict the implementation/support to
rawvideo and wrapped_avframe encoders, since they don't need to be recreated
when resolution/dimension changes and are required. at this moment.

Also as we've discussed about whether it's worthwhile:

>> Do we get sufficient benefits from having parameter change capability inside
>> encoders over just creating a new encoder instance when needed? Do people
>> really need to change resolution mid-GOP?

This implementation didn't touch the logic of encoders which supports variable
resolution encoding on inter frames(vp9, av1), since such enhancement/requirement
seems to be rare for now.

Please help to comment whether it's acceptable.

(missed this mail due to mail server problem, hence using an alternative account
to reply)

- Linjie


More information about the ffmpeg-devel mailing list