[FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
Michael Niedermayer
michaelni at gmx.at
Wed Feb 19 20:07:28 EET 2020
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200219/81ae47d5/attachment.sig>
More information about the ffmpeg-devel
mailing list