[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 Fu,
> Linjie
> Sent: Thursday, October 10, 2019 14:46
> 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
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Fu,
> > Linjie
> > Sent: Wednesday, September 11, 2019 15:12
> > 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
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> > Behalf
> > > Of Fu, Linjie
> > > Sent: Saturday, August 31, 2019 12:40
> > > 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
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> > > Behalf
> > > > Of Fu, Linjie
> > > > Sent: Thursday, August 1, 2019 22:51
> > > > 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
> > > >
> > > > > -----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?
> > >
> > > Ping for this patch set?
> > > https://patchwork.ffmpeg.org/patch/14122/
> > > https://patchwork.ffmpeg.org/patch/14139/
> > > https://patchwork.ffmpeg.org/patch/14140/
> > >
> > Anything I could do for this patch set?
> 
> Another kindly ping.
> 
Hi,

Please help to review.