> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Anton Khirnov > Sent: Wednesday, February 19, 2020 00:42 > To: FFmpeg development discussions and patches <ffmpeg- > de...@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...@intel.com/ [2] https://patchwork.ffmpeg.org/project/ffmpeg/patch/1565688544-9043-1-git-send-email-linjie...@intel.com/ _______________________________________________ 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".
