On 5/2/18, 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.
Patches and actual proposals are better than agreeing of some written text that glorifies status quo. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
