[FFmpeg-devel,01/24] avcodec: add color_range to AVCodec struct

Submitted by Paul B Mahol on May 1, 2018, 7:39 p.m.

Details

Message ID 20180501194013.9552-1-onemda@gmail.com
State New
Headers show

Commit Message

Paul B Mahol May 1, 2018, 7:39 p.m.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
---
 libavcodec/avcodec.h | 1 +
 1 file changed, 1 insertion(+)

Comments

James Almer May 1, 2018, 7:48 p.m.
On 5/1/2018 4:39 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol <onemda@gmail.com>
> ---
>  libavcodec/avcodec.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fae70..3a8f69243c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
>      uint8_t max_lowres;                     ///< maximum value for lowres supported by the decoder
>      const AVClass *priv_class;              ///< AVClass for the private context
>      const AVProfile *profiles;              ///< array of recognized profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +    const enum AVColorRange *color_ranges;  ///< array of supported color ranges by encoder, or NULL if unknown, array is terminated by AVCOL_RANGE_UNSPECIFIED

Breaks ABI...

Place it below wrapper_name, right above the notice about non public
section.

>  
>      /**
>       * Group name of the codec implementation.
>
Paul B Mahol May 1, 2018, 8:01 p.m.
On 5/1/18, James Almer <jamrial@gmail.com> wrote:
> On 5/1/2018 4:39 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol <onemda@gmail.com>
>> ---
>>  libavcodec/avcodec.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index fb0c6fae70..3a8f69243c 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
>>      uint8_t max_lowres;                     ///< maximum value for lowres
>> supported by the decoder
>>      const AVClass *priv_class;              ///< AVClass for the private
>> context
>>      const AVProfile *profiles;              ///< array of recognized
>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
>> +    const enum AVColorRange *color_ranges;  ///< array of supported color
>> ranges by encoder, or NULL if unknown, array is terminated by
>> AVCOL_RANGE_UNSPECIFIED
>
> Breaks ABI...
>
> Place it below wrapper_name, right above the notice about non public
> section.
>
>>
>>      /**
>>       * Group name of the codec implementation.
>>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Done locally.
Vittorio Giovara May 1, 2018, 8:46 p.m.
--

On 5/1/2018 4:39 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol <onemda at gmail.com>
> ---
>  libavcodec/avcodec.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fae70..3a8f69243c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
>      uint8_t max_lowres;                     ///< maximum value for lowres supported by the decoder
>      const AVClass *priv_class;              ///< AVClass for the private context
>      const AVProfile *profiles;              ///< array of recognized profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +    const enum AVColorRange *color_ranges;  ///< array of supported color ranges by encoder, or NULL if unknown, array is terminated by AVCOL_RANGE_UNSPECIFIED
>  
>      /**
>       * Group name of the codec implementation.
> 

While I appreciate this effort to remove the year-long deprecated J-pixel
format, I have a feeling that this is not the right way to do it.

I have no doubt that the code presented here works as expected, however
adding YetAnotherField to the AVCodec structure is a slippery road. Namely
only adding color range as an extra feature of the pixel format is incomplete.

We should add every other single color parameter in this structure, insert
the appropriate conversion filters (which swscale is not fully able to
produce) and handle correct format negotiation across the chain, which is
not exactly trivial (ie. which color space should be favoured? which one has
a larger gamut? and so on).

This creates a precedent that, I think, is bad API-wise and user-wise.
I would rather keep the J-format around than creating a years long user-facing
problem. Additionally having this field (or these fields if we are to include
the other color properties) around makes the intrisic problem even harder
to properly fix.

I am aware that the goal of this patchset is not to properly support all
color conversion properties, and it's just to being able to drop the J-formats,
but I hope that this feedback will give a larger picture of the problem
involved, that it will help you in making the right decision about this set.

Regards
Vittorio
Paul B Mahol May 1, 2018, 9:06 p.m.
On 5/1/18, Vittorio Giovara <vittorio.giovara@gmail.com> wrote:
> --
>
> On 5/1/2018 4:39 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>> ---
>>  libavcodec/avcodec.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index fb0c6fae70..3a8f69243c 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
>>      uint8_t max_lowres;                     ///< maximum value for lowres
>> supported by the decoder
>>      const AVClass *priv_class;              ///< AVClass for the private
>> context
>>      const AVProfile *profiles;              ///< array of recognized
>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
>> +    const enum AVColorRange *color_ranges;  ///< array of supported color
>> ranges by encoder, or NULL if unknown, array is terminated by
>> AVCOL_RANGE_UNSPECIFIED
>>
>>      /**
>>       * Group name of the codec implementation.
>>
>
> While I appreciate this effort to remove the year-long deprecated J-pixel
> format, I have a feeling that this is not the right way to do it.
>
> I have no doubt that the code presented here works as expected, however
> adding YetAnotherField to the AVCodec structure is a slippery road. Namely
> only adding color range as an extra feature of the pixel format is
> incomplete.
>
> We should add every other single color parameter in this structure, insert
> the appropriate conversion filters (which swscale is not fully able to
> produce) and handle correct format negotiation across the chain, which is
> not exactly trivial (ie. which color space should be favoured? which one has
> a larger gamut? and so on).
>
> This creates a precedent that, I think, is bad API-wise and user-wise.
> I would rather keep the J-format around than creating a years long
> user-facing
> problem. Additionally having this field (or these fields if we are to
> include
> the other color properties) around makes the intrisic problem even harder
> to properly fix.
>
> I am aware that the goal of this patchset is not to properly support all
> color conversion properties, and it's just to being able to drop the
> J-formats,
> but I hope that this feedback will give a larger picture of the problem
> involved, that it will help you in making the right decision about this set.

Then why are they deprecated at all?

There is even warning displayed all the time.

Not mentioning that color range does not work at all unless explicitly
managed.

Because you are not proposing solution, and just complaining, I will
ignore this mail.
Rostislav Pehlivanov May 1, 2018, 10:45 p.m.
On 1 May 2018 at 22:06, Paul B Mahol <onemda@gmail.com> wrote:

> On 5/1/18, Vittorio Giovara <vittorio.giovara@gmail.com> wrote:
> > --
> >
> > On 5/1/2018 4:39 PM, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol <onemda at gmail.com>
> >> ---
> >>  libavcodec/avcodec.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >> index fb0c6fae70..3a8f69243c 100644
> >> --- a/libavcodec/avcodec.h
> >> +++ b/libavcodec/avcodec.h
> >> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
> >>      uint8_t max_lowres;                     ///< maximum value for
> lowres
> >> supported by the decoder
> >>      const AVClass *priv_class;              ///< AVClass for the
> private
> >> context
> >>      const AVProfile *profiles;              ///< array of recognized
> >> profiles, or NULL if unknown, array is terminated by
> {FF_PROFILE_UNKNOWN}
> >> +    const enum AVColorRange *color_ranges;  ///< array of supported
> color
> >> ranges by encoder, or NULL if unknown, array is terminated by
> >> AVCOL_RANGE_UNSPECIFIED
> >>
> >>      /**
> >>       * Group name of the codec implementation.
> >>
> >
> > While I appreciate this effort to remove the year-long deprecated J-pixel
> > format, I have a feeling that this is not the right way to do it.
> >
> > I have no doubt that the code presented here works as expected, however
> > adding YetAnotherField to the AVCodec structure is a slippery road.
> Namely
> > only adding color range as an extra feature of the pixel format is
> > incomplete.
> >
> > We should add every other single color parameter in this structure,
> insert
> > the appropriate conversion filters (which swscale is not fully able to
> > produce) and handle correct format negotiation across the chain, which is
> > not exactly trivial (ie. which color space should be favoured? which one
> has
> > a larger gamut? and so on).
> >
> > This creates a precedent that, I think, is bad API-wise and user-wise.
> > I would rather keep the J-format around than creating a years long
> > user-facing
> > problem. Additionally having this field (or these fields if we are to
> > include
> > the other color properties) around makes the intrisic problem even harder
> > to properly fix.
> >
> > I am aware that the goal of this patchset is not to properly support all
> > color conversion properties, and it's just to being able to drop the
> > J-formats,
> > but I hope that this feedback will give a larger picture of the problem
> > involved, that it will help you in making the right decision about this
> set.
>
> Then why are they deprecated at all?
>
> There is even warning displayed all the time.
>
> Not mentioning that color range does not work at all unless explicitly
> managed.
>
> Because you are not proposing solution, and just complaining, I will
> ignore this mail.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I agree with you, they need to be gone. The purpose of the patchset also
isn't just to get rid of them, its to have a good api to handle color
ranges and how it ought to be handled by filters and codecs. His only
objection was that there's a stigma to adding more fields to avctx, which
can't be avoided in this case _because_ the color range is an essential
property of images.
Vittorio Giovara May 1, 2018, 11:30 p.m.

wm4 May 2, 2018, 2:40 a.m.
On Tue,  1 May 2018 16:46:37 -0400
Vittorio Giovara <vittorio.giovara@gmail.com> wrote:

> --
> 
> On 5/1/2018 4:39 PM, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > ---
> >  libavcodec/avcodec.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index fb0c6fae70..3a8f69243c 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
> >      uint8_t max_lowres;                     ///< maximum value for lowres supported by the decoder
> >      const AVClass *priv_class;              ///< AVClass for the private context
> >      const AVProfile *profiles;              ///< array of recognized profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> > +    const enum AVColorRange *color_ranges;  ///< array of supported color ranges by encoder, or NULL if unknown, array is terminated by AVCOL_RANGE_UNSPECIFIED
> >  
> >      /**
> >       * Group name of the codec implementation.
> >   
> 
> While I appreciate this effort to remove the year-long deprecated J-pixel
> format, I have a feeling that this is not the right way to do it.
> 
> I have no doubt that the code presented here works as expected, however
> adding YetAnotherField to the AVCodec structure is a slippery road. Namely
> only adding color range as an extra feature of the pixel format is incomplete.
> 
> We should add every other single color parameter in this structure, insert
> the appropriate conversion filters (which swscale is not fully able to
> produce) and handle correct format negotiation across the chain, which is
> not exactly trivial (ie. which color space should be favoured? which one has
> a larger gamut? and so on).
> 
> This creates a precedent that, I think, is bad API-wise and user-wise.
> I would rather keep the J-format around than creating a years long user-facing
> problem. Additionally having this field (or these fields if we are to include
> the other color properties) around makes the intrisic problem even harder
> to properly fix.
> 
> I am aware that the goal of this patchset is not to properly support all
> color conversion properties, and it's just to being able to drop the J-formats,
> but I hope that this feedback will give a larger picture of the problem
> involved, that it will help you in making the right decision about this set.

I think the patch at hand is OK if it can finally get rid of the J
formats. To me as an API users these actually cause nothing but
annoyance, so it's really great to get rid of them.

Sure, this doesn't solve negotiating of video attributes in
libavfilter, or accurately exposing all encoder capabilities. There are
plenty of other such cases (ask if you want examples). Solving this in
a general and complete way is _hard_. It's not just about adding
missing fields. On a side note, we should think of something that
doesn't require us duplicating all these metadata fields in AVCodec,
AVCodecContext, AVFrame, avfilter buffer sink, avfilter buffer src, and
having to touch every single to "negotiate" the attribute.

So just adding support for color range for the sole purpose of removing
the J formats sounds good to me.

What do you suggest?
Nicolas George May 2, 2018, 11:44 a.m.
Vittorio Giovara (2018-05-01):
> Well no, let's step back a little.
> 
> First of all there is no stigma about adding fields to AVCodecContext,
> in fact, the more, the merrier, right?
> 
> Secondly, there _is_ concern about adding a field to AVCodec (not avctx),
> since is a delicate point of entry, and very sensitive to ABI (which in fact
> was broken in the first iteration of this patch).
> 
> Finally, I immensely disagree that this is a good API at all, just throwing
> fields to structure is rarely a good approach to anything. On a separate note
> I also disagree that color_range (despite its importance) is an "essential
> property of images", at least not any more than the other color propeties:
> it is simply being noticed because there are special purpose enum values, but
> that doesn't mean that the other properties will work "just fine". Because
> they don't.
> The transfer characteristics for example is a much more impactful and
> delicate property that can affect the the color of the image in a much
> more profund way than color range.
> Similar arguments could be made for primaries and matrix.
> 
> As much as you may hate hear it, this proposed filtering system does *not*
> belong to neither lavfi, lavf or lavc, but rather to the scaling library.
> Unfortunately the one used by default, swscale, is a monster spaghetti code
> and too difficult to work around. That however should not affect the design
> of APIs used in the other libraries: if swscale is not suited anymore for
> its job it should be replaced, you shouldn't be adding workarounds to AVCodec.

Thanks for taking the time to express the reservations. I fully agree
with what you wrote.

Regards,
Paul B Mahol May 2, 2018, 11:51 a.m.
On 5/2/18, Nicolas George <george@nsup.org> wrote:
> Vittorio Giovara (2018-05-01):
>> Well no, let's step back a little.
>>
>> First of all there is no stigma about adding fields to AVCodecContext,
>> in fact, the more, the merrier, right?
>>
>> Secondly, there _is_ concern about adding a field to AVCodec (not avctx),
>> since is a delicate point of entry, and very sensitive to ABI (which in
>> fact
>> was broken in the first iteration of this patch).
>>
>> Finally, I immensely disagree that this is a good API at all, just
>> throwing
>> fields to structure is rarely a good approach to anything. On a separate
>> note
>> I also disagree that color_range (despite its importance) is an
>> "essential
>> property of images", at least not any more than the other color
>> propeties:
>> it is simply being noticed because there are special purpose enum values,
>> but
>> that doesn't mean that the other properties will work "just fine".
>> Because
>> they don't.
>> The transfer characteristics for example is a much more impactful and
>> delicate property that can affect the the color of the image in a much
>> more profund way than color range.
>> Similar arguments could be made for primaries and matrix.
>>
>> As much as you may hate hear it, this proposed filtering system does
>> *not*
>> belong to neither lavfi, lavf or lavc, but rather to the scaling library.
>> Unfortunately the one used by default, swscale, is a monster spaghetti
>> code
>> and too difficult to work around. That however should not affect the
>> design
>> of APIs used in the other libraries: if swscale is not suited anymore for
>> its job it should be replaced, you shouldn't be adding workarounds to
>> AVCodec.
>
> Thanks for taking the time to express the reservations. I fully agree
> with what you wrote.

Patches and actual proposals are better than agreeing of some written
text that glorifies status quo.
Nicolas George May 2, 2018, 1:35 p.m.
Paul B Mahol (2018-05-02):
> Patches and actual proposals are better than agreeing of some written
> text that glorifies status quo.

Depends on the quality of the patches.
Paul B Mahol May 2, 2018, 1:36 p.m.
On 5/2/18, Nicolas George <george@nsup.org> wrote:
> Paul B Mahol (2018-05-02):
>> Patches and actual proposals are better than agreeing of some written
>> text that glorifies status quo.
>
> Depends on the quality of the patches.

Depends on who sends patches and reviewer.
wm4 May 2, 2018, 4:39 p.m.
On Wed, 2 May 2018 13:44:48 +0200
Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (2018-05-01):
> > Well no, let's step back a little.
> > 
> > First of all there is no stigma about adding fields to AVCodecContext,
> > in fact, the more, the merrier, right?
> > 
> > Secondly, there _is_ concern about adding a field to AVCodec (not avctx),
> > since is a delicate point of entry, and very sensitive to ABI (which in fact
> > was broken in the first iteration of this patch).
> > 
> > Finally, I immensely disagree that this is a good API at all, just throwing
> > fields to structure is rarely a good approach to anything. On a separate note
> > I also disagree that color_range (despite its importance) is an "essential
> > property of images", at least not any more than the other color propeties:
> > it is simply being noticed because there are special purpose enum values, but
> > that doesn't mean that the other properties will work "just fine". Because
> > they don't.
> > The transfer characteristics for example is a much more impactful and
> > delicate property that can affect the the color of the image in a much
> > more profund way than color range.
> > Similar arguments could be made for primaries and matrix.
> > 
> > As much as you may hate hear it, this proposed filtering system does *not*
> > belong to neither lavfi, lavf or lavc, but rather to the scaling library.
> > Unfortunately the one used by default, swscale, is a monster spaghetti code
> > and too difficult to work around. That however should not affect the design
> > of APIs used in the other libraries: if swscale is not suited anymore for
> > its job it should be replaced, you shouldn't be adding workarounds to AVCodec.  
> 
> Thanks for taking the time to express the reservations. I fully agree
> with what you wrote.

Please don't prevent us from fixing libavfilter.
Rostislav Pehlivanov May 2, 2018, 4:49 p.m.
On 2 May 2018 at 17:39, wm4 <nfxjfg@googlemail.com> wrote:

> On Wed, 2 May 2018 13:44:48 +0200
> Nicolas George <george@nsup.org> wrote:
>
> > Vittorio Giovara (2018-05-01):
> > > Well no, let's step back a little.
> > >
> > > First of all there is no stigma about adding fields to AVCodecContext,
> > > in fact, the more, the merrier, right?
> > >
> > > Secondly, there _is_ concern about adding a field to AVCodec (not
> avctx),
> > > since is a delicate point of entry, and very sensitive to ABI (which
> in fact
> > > was broken in the first iteration of this patch).
> > >
> > > Finally, I immensely disagree that this is a good API at all, just
> throwing
> > > fields to structure is rarely a good approach to anything. On a
> separate note
> > > I also disagree that color_range (despite its importance) is an
> "essential
> > > property of images", at least not any more than the other color
> propeties:
> > > it is simply being noticed because there are special purpose enum
> values, but
> > > that doesn't mean that the other properties will work "just fine".
> Because
> > > they don't.
> > > The transfer characteristics for example is a much more impactful and
> > > delicate property that can affect the the color of the image in a much
> > > more profund way than color range.
> > > Similar arguments could be made for primaries and matrix.
> > >
> > > As much as you may hate hear it, this proposed filtering system does
> *not*
> > > belong to neither lavfi, lavf or lavc, but rather to the scaling
> library.
> > > Unfortunately the one used by default, swscale, is a monster spaghetti
> code
> > > and too difficult to work around. That however should not affect the
> design
> > > of APIs used in the other libraries: if swscale is not suited anymore
> for
> > > its job it should be replaced, you shouldn't be adding workarounds to
> AVCodec.
> >
> > Thanks for taking the time to express the reservations. I fully agree
> > with what you wrote.
>
> Please don't prevent us from fixing libavfilter.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


+1

also what Vittorio complained about (AVCodec fields) has NOTHING to do with
lavfi or swscale.
wm4 May 2, 2018, 5:16 p.m.
On Wed, 2 May 2018 17:49:05 +0100
Rostislav Pehlivanov <atomnuker@gmail.com> wrote:

> On 2 May 2018 at 17:39, wm4 <nfxjfg@googlemail.com> wrote:
> 
> > On Wed, 2 May 2018 13:44:48 +0200
> > Nicolas George <george@nsup.org> wrote:
> >  
> > > Vittorio Giovara (2018-05-01):  
> > > > Well no, let's step back a little.
> > > >
> > > > First of all there is no stigma about adding fields to AVCodecContext,
> > > > in fact, the more, the merrier, right?
> > > >
> > > > Secondly, there _is_ concern about adding a field to AVCodec (not  
> > avctx),  
> > > > since is a delicate point of entry, and very sensitive to ABI (which  
> > in fact  
> > > > was broken in the first iteration of this patch).
> > > >
> > > > Finally, I immensely disagree that this is a good API at all, just  
> > throwing  
> > > > fields to structure is rarely a good approach to anything. On a  
> > separate note  
> > > > I also disagree that color_range (despite its importance) is an  
> > "essential  
> > > > property of images", at least not any more than the other color  
> > propeties:  
> > > > it is simply being noticed because there are special purpose enum  
> > values, but  
> > > > that doesn't mean that the other properties will work "just fine".  
> > Because  
> > > > they don't.
> > > > The transfer characteristics for example is a much more impactful and
> > > > delicate property that can affect the the color of the image in a much
> > > > more profund way than color range.
> > > > Similar arguments could be made for primaries and matrix.
> > > >
> > > > As much as you may hate hear it, this proposed filtering system does  
> > *not*  
> > > > belong to neither lavfi, lavf or lavc, but rather to the scaling  
> > library.  
> > > > Unfortunately the one used by default, swscale, is a monster spaghetti  
> > code  
> > > > and too difficult to work around. That however should not affect the  
> > design  
> > > > of APIs used in the other libraries: if swscale is not suited anymore  
> > for  
> > > > its job it should be replaced, you shouldn't be adding workarounds to  
> > AVCodec.  
> > >
> > > Thanks for taking the time to express the reservations. I fully agree
> > > with what you wrote.  
> >
> > Please don't prevent us from fixing libavfilter.
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >  
> 
> 
> +1
> 
> also what Vittorio complained about (AVCodec fields) has NOTHING to do with
> lavfi or swscale.

Well, it sort of strides all components (my fault), but surely we don't
want to just stop solving this problem just because we have no
"perfect" solution.

Also this is the typical ffmpeg bikeshed brake: someone wants to solve
a small problem, others bikeshed it to death because they really want
to solve a much bigger problem that requires much more effort, and thus
doesn't get solved.
Rostislav Pehlivanov May 12, 2018, 7:28 p.m.
On 1 May 2018 at 20:39, Paul B Mahol <onemda@gmail.com> wrote:

> Signed-off-by: Paul B Mahol <onemda@gmail.com>
> ---
>  libavcodec/avcodec.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fae70..3a8f69243c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
>      uint8_t max_lowres;                     ///< maximum value for lowres
> supported by the decoder
>      const AVClass *priv_class;              ///< AVClass for the private
> context
>      const AVProfile *profiles;              ///< array of recognized
> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
> +    const enum AVColorRange *color_ranges;  ///< array of supported color
> ranges by encoder, or NULL if unknown, array is terminated by
> AVCOL_RANGE_UNSPECIFIED
>
>      /**
>       * Group name of the codec implementation.
> --
> 2.11.0
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Ping? I think we should ignore koda's remarks and go through with this.
Paul B Mahol May 12, 2018, 7:40 p.m.
On 5/12/18, Rostislav Pehlivanov <atomnuker@gmail.com> wrote:
> On 1 May 2018 at 20:39, Paul B Mahol <onemda@gmail.com> wrote:
>
>> Signed-off-by: Paul B Mahol <onemda@gmail.com>
>> ---
>>  libavcodec/avcodec.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index fb0c6fae70..3a8f69243c 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
>>      uint8_t max_lowres;                     ///< maximum value for lowres
>> supported by the decoder
>>      const AVClass *priv_class;              ///< AVClass for the private
>> context
>>      const AVProfile *profiles;              ///< array of recognized
>> profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
>> +    const enum AVColorRange *color_ranges;  ///< array of supported color
>> ranges by encoder, or NULL if unknown, array is terminated by
>> AVCOL_RANGE_UNSPECIFIED
>>
>>      /**
>>       * Group name of the codec implementation.
>> --
>> 2.11.0
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Ping? I think we should ignore koda's remarks and go through with this.

I moved to another stuff, sorry.

I wait for non-power of 2 DCT/FFT.
Rostislav Pehlivanov May 12, 2018, 7:52 p.m.
On 12 May 2018 at 20:40, Paul B Mahol <onemda@gmail.com> wrote:

> On 5/12/18, Rostislav Pehlivanov <atomnuker@gmail.com> wrote:
> > On 1 May 2018 at 20:39, Paul B Mahol <onemda@gmail.com> wrote:
> >
> >> Signed-off-by: Paul B Mahol <onemda@gmail.com>
> >> ---
> >>  libavcodec/avcodec.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> >> index fb0c6fae70..3a8f69243c 100644
> >> --- a/libavcodec/avcodec.h
> >> +++ b/libavcodec/avcodec.h
> >> @@ -3433,6 +3433,7 @@ typedef struct AVCodec {
> >>      uint8_t max_lowres;                     ///< maximum value for
> lowres
> >> supported by the decoder
> >>      const AVClass *priv_class;              ///< AVClass for the
> private
> >> context
> >>      const AVProfile *profiles;              ///< array of recognized
> >> profiles, or NULL if unknown, array is terminated by
> {FF_PROFILE_UNKNOWN}
> >> +    const enum AVColorRange *color_ranges;  ///< array of supported
> color
> >> ranges by encoder, or NULL if unknown, array is terminated by
> >> AVCOL_RANGE_UNSPECIFIED
> >>
> >>      /**
> >>       * Group name of the codec implementation.
> >> --
> >> 2.11.0
> >>
> >> _______________________________________________
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > Ping? I think we should ignore koda's remarks and go through with this.
>
> I moved to another stuff, sorry.
>
> I wait for non-power of 2 DCT/FFT.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Just send a v2 of this patch to move the color_range field to where it
doesn't break the ABI and it'll be good.

Patch hide | download patch | download mbox

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index fb0c6fae70..3a8f69243c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3433,6 +3433,7 @@  typedef struct AVCodec {
     uint8_t max_lowres;                     ///< maximum value for lowres supported by the decoder
     const AVClass *priv_class;              ///< AVClass for the private context
     const AVProfile *profiles;              ///< array of recognized profiles, or NULL if unknown, array is terminated by {FF_PROFILE_UNKNOWN}
+    const enum AVColorRange *color_ranges;  ///< array of supported color ranges by encoder, or NULL if unknown, array is terminated by AVCOL_RANGE_UNSPECIFIED
 
     /**
      * Group name of the codec implementation.