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

Submitted by Linjie Fu on July 30, 2019, 4:45 a.m.

Details

Message ID 1564461924-4772-1-git-send-email-linjie.fu@intel.com
State New
Headers show

Commit Message

Linjie Fu July 30, 2019, 4:45 a.m.
Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate whether encoder
supports variable dimension encoding.

Signed-off-by: Linjie Fu <linjie.fu@intel.com>
---
[v2]: update API changes.
 doc/APIchanges       | 3 +++
 fftools/cmdutils.c   | 2 ++
 libavcodec/avcodec.h | 5 +++++
 libavcodec/rawenc.c  | 1 +
 libavcodec/version.h | 2 +-
 5 files changed, 12 insertions(+), 1 deletion(-)

Comments

Carl Eugen Hoyos July 30, 2019, 8:05 a.m.
Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu <linjie.fu@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?

Carl Eugen
Linjie Fu July 30, 2019, 9:25 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Carl Eugen Hoyos

> Sent: Tuesday, July 30, 2019 16:06

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@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@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"?

- linjie
Carl Eugen Hoyos July 30, 2019, 9:33 a.m.
Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie <linjie.fu@intel.com>:
>
> > -----Original Message-----
> > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
> > Of Carl Eugen Hoyos
> > Sent: Tuesday, July 30, 2019 16:06
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@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@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
James Almer July 30, 2019, 1:27 p.m.
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@intel.com>:
>>
>>> -----Original Message-----
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
>>> Of Carl Eugen Hoyos
>>> Sent: Tuesday, July 30, 2019 16:06
>>> To: FFmpeg development discussions and patches <ffmpeg-
>>> devel@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@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.
Linjie Fu July 30, 2019, 4:10 p.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of James Almer

> Sent: Tuesday, July 30, 2019 21:27

> To: ffmpeg-devel@ffmpeg.org

> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add

> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

> 

> 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@intel.com>:

> >>

> >>> -----Original Message-----

> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On

> Behalf

> >>> Of Carl Eugen Hoyos

> >>> Sent: Tuesday, July 30, 2019 16:06

> >>> To: FFmpeg development discussions and patches <ffmpeg-

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


Thanks.
Saw the modification in fe75dc8583b65612f3a94144ee090e741dc926d5,
and it seems it was designed for decoder at first, like "rawdec/nellymoserdec/interplayvideo".

"Also define a codec capability for codecs that can handle
 parameters changed externally between decoded packets. "

Since currently no encoder is engaged with this flag, it's good for me to reuse this if there is no
other concern.

- linjie
Michael Niedermayer July 31, 2019, 6:03 a.m.
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@intel.com>:
> >>
> >>> -----Original Message-----
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
> >>> Of Carl Eugen Hoyos
> >>> Sent: Tuesday, July 30, 2019 16:06
> >>> To: FFmpeg development discussions and patches <ffmpeg-
> >>> devel@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@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.

[...]
Linjie Fu Aug. 1, 2019, 2:51 p.m.
> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Wednesday, July 31, 2019 14:04
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@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@intel.com>:
> > >>
> > >>> -----Original Message-----
> > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On
> Behalf
> > >>> Of Carl Eugen Hoyos
> > >>> Sent: Tuesday, July 30, 2019 16:06
> > >>> To: FFmpeg development discussions and patches <ffmpeg-
> > >>> devel@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@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?
Linjie Fu Aug. 31, 2019, 4:39 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Fu, Linjie

> Sent: Thursday, August 1, 2019 22:51

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@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@ffmpeg.org] On

> Behalf

> > Of Michael Niedermayer

> > Sent: Wednesday, July 31, 2019 14:04

> > To: FFmpeg development discussions and patches <ffmpeg-

> > devel@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@intel.com>:

> > > >>

> > > >>> -----Original Message-----

> > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]

> On

> > Behalf

> > > >>> Of Carl Eugen Hoyos

> > > >>> Sent: Tuesday, July 30, 2019 16:06

> > > >>> To: FFmpeg development discussions and patches <ffmpeg-

> > > >>> devel@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@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/
Linjie Fu Sept. 11, 2019, 7:11 a.m.
> -----Original Message-----

> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf

> Of Fu, Linjie

> Sent: Saturday, August 31, 2019 12:40

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@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@ffmpeg.org] On

> Behalf

> > Of Fu, Linjie

> > Sent: Thursday, August 1, 2019 22:51

> > To: FFmpeg development discussions and patches <ffmpeg-

> > devel@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@ffmpeg.org] On

> > Behalf

> > > Of Michael Niedermayer

> > > Sent: Wednesday, July 31, 2019 14:04

> > > To: FFmpeg development discussions and patches <ffmpeg-

> > > devel@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@intel.com>:

> > > > >>

> > > > >>> -----Original Message-----

> > > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]

> > On

> > > Behalf

> > > > >>> Of Carl Eugen Hoyos

> > > > >>> Sent: Tuesday, July 30, 2019 16:06

> > > > >>> To: FFmpeg development discussions and patches <ffmpeg-

> > > > >>> devel@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@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?
Linjie Fu Oct. 10, 2019, 6:45 a.m.
> -----Original Message-----

> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Fu,

> Linjie

> Sent: Wednesday, September 11, 2019 15:12

> To: FFmpeg development discussions and patches <ffmpeg-

> devel@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@ffmpeg.org] On

> Behalf

> > Of Fu, Linjie

> > Sent: Saturday, August 31, 2019 12:40

> > To: FFmpeg development discussions and patches <ffmpeg-

> > devel@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@ffmpeg.org] On

> > Behalf

> > > Of Fu, Linjie

> > > Sent: Thursday, August 1, 2019 22:51

> > > To: FFmpeg development discussions and patches <ffmpeg-

> > > devel@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@ffmpeg.org] On

> > > Behalf

> > > > Of Michael Niedermayer

> > > > Sent: Wednesday, July 31, 2019 14:04

> > > > To: FFmpeg development discussions and patches <ffmpeg-

> > > > devel@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@intel.com>:

> > > > > >>

> > > > > >>> -----Original Message-----

> > > > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org]

> > > On

> > > > Behalf

> > > > > >>> Of Carl Eugen Hoyos

> > > > > >>> Sent: Tuesday, July 30, 2019 16:06

> > > > > >>> To: FFmpeg development discussions and patches <ffmpeg-

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

-linjie

Patch hide | download patch | download mbox

diff --git a/doc/APIchanges b/doc/APIchanges
index 07331b1..2e855f2 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@  libavutil:     2017-10-21
 
 API changes, most recent first:
 
+2019-07-xx - xxxxxxxxxx - lavc 58.55.101 - avcodec.h
+  Add AV_CODEC_CAP_VARIABLE_DIMENSIONS
+
 -------- 8< --------- FFmpeg 4.2 was cut here -------- 8< ---------
 
 2019-06-21 - a30e44098a - lavu 56.30.100 - frame.h
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 9cfbc45..25ea1c6 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1424,6 +1424,8 @@  static void print_codec(const AVCodec *c)
         printf("hardware ");
     if (c->capabilities & AV_CODEC_CAP_HYBRID)
         printf("hybrid ");
+    if (c->capabilities & AV_CODEC_CAP_VARIABLE_DIMENSIONS)
+        printf("multidimension ");
     if (!c->capabilities)
         printf("none");
     printf("\n");
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d234271..a7704ea 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1092,6 +1092,11 @@  typedef struct RcOverride{
 #define AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE (1 << 20)
 
 /**
+ * Codec supports variable dimensions in encoding.
+ */
+#define AV_CODEC_CAP_VARIABLE_DIMENSIONS (1 << 21)
+
+/**
  * Pan Scan area.
  * This specifies the area which should be displayed.
  * Note there may be multiple such areas for one frame.
diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index d181b74..486c0d7 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -92,4 +92,5 @@  AVCodec ff_rawvideo_encoder = {
     .id             = AV_CODEC_ID_RAWVIDEO,
     .init           = raw_encode_init,
     .encode2        = raw_encode,
+    .capabilities   = AV_CODEC_CAP_VARIABLE_DIMENSIONS,
 };
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 43c8cdb..e70ebc0 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@ 
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  55
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
                                                LIBAVCODEC_VERSION_MINOR, \