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

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Wednesday, July 31, 2019 14:04
> 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
> 
> On Tue, Jul 30, 2019 at 10:27:10AM -0300, James Almer wrote:
> > On 7/30/2019 6:33 AM, Carl Eugen Hoyos wrote:
> > > Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie <linjie.fu at intel.com>:
> > >>
> > >>> -----Original Message-----
> > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> > >>> Of Carl Eugen Hoyos
> > >>> Sent: Tuesday, July 30, 2019 16:06
> > >>> 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
> > >>>
> > >>> Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu
> <linjie.fu at intel.com>:
> > >>>>
> > >>>> Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate
> > >>>> whether encoder supports variable dimension encoding.
> > >>>
> > >>> Isn't this about variable (or "changing") "resolutions" instead of
> dimensions?
> > >>>
> > >>
> > >> Comment is welcome and "variable resolutions" is good.
> > >
> > >> But is "dimension" not quite suitable for the meaning of "variable size"?
> > >
> > > It took me some time to understand that "dimension" implies resolution,
> > > especially since the FFmpeg documentation mentions resolution iirc.
> > >
> > > Carl Eugen
> >
> > We have a AV_SIDE_DATA_PARAM_CHANGE_DIMENSIONS flag to signal
> resolution
> > changes, so both words seem to be used interchangeably.
> >
> 
> > This also makes me think that the existing
> AV_CODEC_CAP_PARAM_CHANGE
> > codec cap can be used for this already, without the need for a new one.
> > It should a matter of using AV_PKT_DATA_PARAM_CHANGE packet side
> data
> > afterwards in some form.
> 
> if AV_PKT_DATA_PARAM_CHANGE is used then other parameters would
> need to
> be handled too i think.
> For example pixel format changes alongside width and height.
> And it leaves some areas of uncertanity which may require more flags
> like does a aspect ratio change or a change of one of the colorspace
> parameters need a encoder "flush/restart". (the flush is done from
> outside the encoder in the patch so the code would need to know)
> 
> Also for symmetry, if AV_PKT_DATA_PARAM_CHANGE expects sidedata on
> the input side of the decoder, something should produce matching
> side data on the encoder side.
> 
> encoder -> decoder should continue working. So only a demuxer
> generating the side data could be a problem.

Sounds like a new flag will be more robust?