| Message ID | 20180501194013.9552-1-onemda@gmail.com |
|---|---|
| State | New |
| Headers | show |
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. >
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.
-- 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
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.
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.
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?
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,
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Signed-off-by: Paul B Mahol <onemda@gmail.com> --- libavcodec/avcodec.h | 1 + 1 file changed, 1 insertion(+)