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. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: PGP signature
_______________________________________________ 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".
