Oct 14, 2023, 17:16 by vittorio.giov...@gmail.com: > On Sat, Oct 14, 2023 at 9:11 AM Lynne <d...@lynne.ee> wrote: > >> Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com: >> >> > On Fri, Oct 13, 2023 at 5:14 PM Lynne <d...@lynne.ee> wrote: >> > >> >> Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: >> >> >> >> > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas <ffm...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
