--
On Wed May 2 01:45:47 EEST 2018 Rostislav Pehlivanov wrote:
> 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.
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.
Paul, if warnings are what's bothering you, just drop the warnings, instead
of introducing a years long, user facing, difficult to remove API.
Since I fear this message will be ignored too, it will be my last one on this
topic as well.
Regards,
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
