Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Mon, Oct 23, 2023 at 05:56:48PM -0700, Vittorio Giovara wrote: > On Sat, Oct 21, 2023 at 4:20 PM Michael Niedermayer > wrote: > > > On Fri, Oct 20, 2023 at 07:13:00PM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < > > > vittorio.giov...@gmail.com> wrote: > > > > > > > tbh while it's great that this functionality exists *somewhere* in > > ffmpeg, > > > > this is really something that should belong to the scaler filter > > (whichever > > > > implementation) > > > > > > > > > > I agree. The reason this was done separately was to be able to have it at > > > all. I considered doing it in sws and realized I probably wouldn't finish > > > it. This was a path of less resistance. > > > > sws supports cascaded_context, with that a sws can just spawn multiple > > sws to implement a path. > > so if a sws can do just colorspace1->colorspace2 and one can scale > > colorspace2 you can quite easily make it support > > colorspace1 scaling into colorspace2 for example > > > > so anything should be quite add-able into sws that you have an > > implementation for > > > > Nothing is quite easily add-able to sws, If you have any difficulty with sws, please ask me, iam here to help > or developers would have done so > instead of writing 4 different scaling libraries People create new libraries, new platforms and new applications all the time for a wide range of reasons other that "Nothing is quite easily add-able" thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Sat, Oct 21, 2023 at 4:20 PM Michael Niedermayer wrote: > On Fri, Oct 20, 2023 at 07:13:00PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> wrote: > > > > > tbh while it's great that this functionality exists *somewhere* in > ffmpeg, > > > this is really something that should belong to the scaler filter > (whichever > > > implementation) > > > > > > > I agree. The reason this was done separately was to be able to have it at > > all. I considered doing it in sws and realized I probably wouldn't finish > > it. This was a path of less resistance. > > sws supports cascaded_context, with that a sws can just spawn multiple > sws to implement a path. > so if a sws can do just colorspace1->colorspace2 and one can scale > colorspace2 you can quite easily make it support > colorspace1 scaling into colorspace2 for example > > so anything should be quite add-able into sws that you have an > implementation for > Nothing is quite easily add-able to sws, or developers would have done so instead of writing 4 different scaling libraries -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, Oct 20, 2023 at 07:13:00PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > > > tbh while it's great that this functionality exists *somewhere* in ffmpeg, > > this is really something that should belong to the scaler filter (whichever > > implementation) > > > > I agree. The reason this was done separately was to be able to have it at > all. I considered doing it in sws and realized I probably wouldn't finish > it. This was a path of less resistance. sws supports cascaded_context, with that a sws can just spawn multiple sws to implement a path. so if a sws can do just colorspace1->colorspace2 and one can scale colorspace2 you can quite easily make it support colorspace1 scaling into colorspace2 for example so anything should be quite add-able into sws that you have an implementation for thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Hi, On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > tbh while it's great that this functionality exists *somewhere* in ffmpeg, > this is really something that should belong to the scaler filter (whichever > implementation) > I agree. The reason this was done separately was to be able to have it at all. I considered doing it in sws and realized I probably wouldn't finish it. This was a path of less resistance. Thanks for the difficult-to-add feature list. (I may have some more questions later on - need to do some research for understanding.) Ronald ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, Oct 20, 2023 at 7:30 AM Niklas Haas wrote: > On Fri, 13 Oct 2023 14:33:11 -0400 Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas 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? > > > > - Add some miscellaneous fixes for various FATE tests > > > - Clean up some additional vestigiaul YUVJ remnants > > > > > N.B.: Another issue with vf_scale/vf_colorspace is that vf_scale > currently doesn't handle colorspace metadata at all, which is blocking > the ability to add this (easily) to filter negotiation, since filter > negotiation hard-codes the "scale" filter for auto-converting between > any mismatch. > IMO having a solution that improves the status quo is welcome, so as long as there is /a/ way in which ffmpeg can output correct colorspaces automatically it should be added, even if this requires pulling in external dependencies like for zscale. Like I believe that producing correct conversion should be the priority, and once the design is good enough we can address the presence of the functionality in the codebase or not. > I am considering even just dropping the extended colorspace metadata > (primaries, trc) from this series completely, or at least splitting them > into separate patchsets. One to only remove YUVJ and add the color range > + filter negotiation, and one to add all of the remaining colorspace > metadata. +1 to splitting the set a bit more, like proposed -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, Oct 20, 2023 at 8:14 AM Ronald S. Bultje wrote: > Hi, > > On Sat, Oct 14, 2023 at 11:16 AM Vittorio Giovara < > vittorio.giov...@gmail.com> wrote: > > > On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote: > > > 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. > > > > Not at all related to the patchset anymore... But I'm curious what's > missing here, could you elaborate? It would be nice to have that documented > somewhere. > basically the constant luminance colorspaces (bt2020c), the various ICtCp variants, and all the HDR transfers like hlg or pq (which, to my understanding, cannot be easily added to the filter due to how the gamma function is built) tbh while it's great that this functionality exists *somewhere* in ffmpeg, this is really something that should belong to the scaler filter (whichever implementation) -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Hi, On Sat, Oct 14, 2023 at 11:16 AM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote: > > 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. > Not at all related to the patchset anymore... But I'm curious what's missing here, could you elaborate? It would be nice to have that documented somewhere. Ronald ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, 13 Oct 2023 14:33:11 -0400 Vittorio Giovara wrote: > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas 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? > > - Add some miscellaneous fixes for various FATE tests > > - Clean up some additional vestigiaul YUVJ remnants > > N.B.: Another issue with vf_scale/vf_colorspace is that vf_scale currently doesn't handle colorspace metadata at all, which is blocking the ability to add this (easily) to filter negotiation, since filter negotiation hard-codes the "scale" filter for auto-converting between any mismatch. I am considering even just dropping the extended colorspace metadata (primaries, trc) from this series completely, or at least splitting them into separate patchsets. One to only remove YUVJ and add the color range + filter negotiation, and one to add all of the remaining colorspace metadata. Then the bikeshed about how to convert between these remaining bits of metadata can be left to that series, and not block YUVJ removal. ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Oct 14, 2023, 17:16 by vittorio.giov...@gmail.com: > On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote: > >> Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com: >> >> > On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote: >> > >> >> Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: >> >> >> >> > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas >> 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote: > Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com: > > > On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote: > > > >> Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: > >> > >> > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas > 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Oct 14, 2023, 00:22 by vittorio.giov...@gmail.com: > On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote: > >> Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: >> >> > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas 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. As for HDR, I think anything but what libplacebo does is sufficient. ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote: > Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: > > > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas 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 -- 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas 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 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. ___ 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".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas 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? - Add some miscellaneous fixes for various FATE tests > - Clean up some additional vestigiaul YUVJ remnants > -- 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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
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 - Add some miscellaneous fixes for various FATE tests - Clean up some additional vestigiaul YUVJ remnants ___ 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".
