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...@intel.com>: > >> > >>> -----Original Message----- > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > >>> Of Carl Eugen Hoyos > >>> Sent: Tuesday, July 30, 2019 16:06 > >>> To: FFmpeg development discussions and patches <ffmpeg- > >>> de...@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...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
