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, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
