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

[Vittorio Giovara <vittorio.giovara@gmail.com>]

On Sat, Oct 14, 2023 at 9:11 AM Lynne <dev@lynne.ee> wrote:

> Oct 14, 2023, 00:22 by vittorio.giovara@gmail.com:
>
> > On Fri, Oct 13, 2023 at 5:14 PM Lynne <dev@lynne.ee> wrote:
> >
> >> Oct 13, 2023, 20:33 by vittorio.giovara@gmail.com:
> >>
> >> > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas <ffmpeg@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.
-- 
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".