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

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Tuesday, February 18, 2020 21:32
> 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 Michael Niedermayer (2020-02-17 23:38:31)
> > On Mon, Feb 17, 2020 at 06:28:23PM +0000, Fu, Linjie wrote:
> >
> > > > > > https://patchwork.ffmpeg.org/patch/14122/
> >
> > iam hesitating because it feeds encoders with changing resolution resulting
> > in potentially undefined behavior ...
> >

Any suggestions?

> > > > > > https://patchwork.ffmpeg.org/patch/14139/
> >
> > long discussion here its not immedeatly clear if anyone was against it

Please help to give some inputs if this would leads to some unexpected
results from your point of view.

> > Also there is the question about the API, is there anything in the API
> > documentation that restricts the user app from changing the encoder
> > input frame dimensions?
> > This should be documented somewhere if its not ...
> >
> > If a flag is added that affects this, it would have to
> > be documented so someone writing a user app using the encoders
> > would know if they are allowed to change the resolution.
> > With just the flag and its documentation a developer could miss
> > the flag entirely

Since I didn't find the descriptions in doxygen:
https://ffmpeg.org/doxygen/trunk/group__lavc__encoding.html#ga4fde50e2cad4cf3d66d882a7078aeab4

The things should be done seem to be:

[1]. Documentation in API, to declare that encoders require input frame to 
be in constant dimensions, unless the encoders have the capability of
dynamic resolution encoding [2].

[2]. Documentation in API, to declare this codec flag would affect the restrict in [1].

If it's ok, I'll update the patch with the documentations added.


> 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.