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

[Michael Niedermayer]

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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190731/9c412e68/attachment.sig>