Quoting Michael Niedermayer (2020-02-19 19:07:28) > On Tue, Feb 18, 2020 at 05:42:19PM +0100, Anton Khirnov wrote: > > 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? > > some sort of capability check would be needed for flush destroy open too > because there are a range of cases where this would not produce a decodeable > file. > for example some codecs like msmpeg4 do not store the resolution in their > header and instead its stored in the container only once per stream.
Right, but that is a property of a given codec ID and should be a flag in AVCodecDescriptor, not in a specific encoder implementation. Actually I had some plans to add such a flag and then write a bitstream filter for concatenating streams where some extra processing is required. -- 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".