[FFmpeg-devel] [PATCH v2 00/13] YUVJ removal

[Lynne]

Oct 14, 2023, 17:16 by vittorio.giovara at gmail.com:

> On Sat, Oct 14, 2023 at 9:11 AM Lynne <dev at lynne.ee> wrote:
>
>> Oct 14, 2023, 00:22 by vittorio.giovara at gmail.com:
>>
>> > On Fri, Oct 13, 2023 at 5:14 PM Lynne <dev at lynne.ee> wrote:
>> >
>> >> Oct 13, 2023, 20:33 by vittorio.giovara at gmail.com:
>> >>
>> >> > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas <ffmpeg at haasn.xyz>
>> wrote:
>> >> >
>> >> >> Changes since v1:
>> >> >>
>> >> >> - Remove unneeded patch (AVCodecContext.colorspace init)
>> >> >> - Merge auto-range conversion into auto-scale filter
>> >> >> - Replace vf_zscale by vf_colorspace in fftools
>> >> >>
>> >> >
>> >> > Why is this? I haven't checked what vf_colorspace supports in a hot
>> >> second,
>> >> > but iirc zscale can handle non linear spaces better and hdr conversion
>> >> > If it's because it's a built in filter, do you think we could first
>> check
>> >> > for zscale presence and fallback to colorspace?
>> >> >
>> >>
>> >> vf_colorspace != swscale
>> >>
>> >
>> > I am aware, thanks, not sure why's related here
>> >
>> >
>> >> Relying on external library for basic functionality that we have
>> >> no control over, which may break its ABI or API at any moment,
>> >> when we have a built-in one is a no.
>> >> I wouldn't agree to having it optional in this case either. Users
>> >> can explicitly request it as a filter and use it, which fits in better
>> >> with its very explicit programming model too.
>> >>
>> >
>> > except colorspace doesn't implement necessary features and conversions
>> that
>> > are present in zscale afair
>> > if it's an automation to facilitate the life of a user it shouldn't come
>> at
>> > the cost of producing actual good results
>> >
>>
>> colorspace doesn't make it impossible to introduce all that is needed.
>> It's a cleaner codebase that we can extend.
>>
>
> * that only works on a subset of colorspaces.
> Last time I checked, it would have required a massive lift to support
> anything with constant luminance or the icpct formats.
>
> As for HDR, I think anything but what libplacebo does is sufficient.
>
>>
>>
>
> Right but it's also important to avoid reinventing the wheel. We could find
> better solutions like having a library with different backends and bundle
> them as needed.
>

But we also need determinism. Tests have to pass, and bitexactness
is often required by users.