[FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

Fu, Linjie linjie.fu at intel.com
Wed Feb 19 18:25:30 EET 2020


> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Wednesday, February 19, 2020 00:42
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> 
> Quoting Fu, Linjie (2020-02-18 16:06:10)
> > > Is there even a sufficiently strong use case for this? Why not just
> >
> > Like transcoding reinit-large_420_8-to-small_420_8.h264 (from 352x288 to
> 240x196)
> > and prefer to keep the resolution changing in the output stream.
> >
> > IMHO not modifying the resolution unless it's required by user is kind of
> natural.
> >
> > > create a new encoder instance?
> >
> > Would you please help to elaborate more about "create a new encoder
> instance?"
> >
> > What I intended to do is to flush and close the encoder when resolution
> changing,
> > and reinit/recreate a new one.
> 
> Yes, that's what I mean. Flush and destroy an AVCodecContext and open a
> new one. But then why is there a need for this flag?
> 
Previously I intended to add close and re-init inside specific encoder like [1],
without destroy AVCodecContext, and some codec [2] may support
dynamic resolution encoding without reinitialization. (which allows resolution
changing on P/inter frame, not only I/key frame).

So it's more secure to add a flag to declare the capability, and add the support
for encoders step by step.

[1] https://patchwork.ffmpeg.org/project/ffmpeg/patch/1564307683-22194-1-git-send-email-linjie.fu@intel.com/
[2] https://patchwork.ffmpeg.org/project/ffmpeg/patch/1565688544-9043-1-git-send-email-linjie.fu@intel.com/


More information about the ffmpeg-devel mailing list