On Wed, 2 May 2018 13:44:48 +0200 Nicolas George <geo...@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
