Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

[Lynne <dev@lynne.ee>]

Oct 13, 2023, 22:31 by vittorio.giovara@gmail.com:

> On Fri, Oct 13, 2023 at 3:19 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
>
>> Hi everyone
>>
>> I propose using 15k$ from SPI for funding sws cleanup work.
>> this is substantially less than what people belive this needs (see IRC
>> logs from yesterday or so)
>> So it really is more a small price for a good deed and not proper payment.
>> This of course is only available to competent developers. (exact rules or
>> how thats determined
>> would still need to be decided unless its a clear case)
>> Also the exact outcome and goal would need to be discussed by the
>> community and whoever
>> does the work.
>> But some goals would probably be to make sws
>> * pleasent to work with
>> * similar speed or faster
>> * proper multithreading
>> * proper full colorspace convertion not ignoring gamma, primaries, ...
>> * clean / understandable modular design (maybe everything can be a
>> "Filter" inside sws
>>  that get build into a chain)
>>
>> Proper payment (50k$ maybe) would be too much in relation to what SPI has
>> ATM (150k$)
>>
>> Above all, this is just my oppinion, the actual SPI funding also would
>> need to
>> be approved by the community. This can happen after a specific volunteer
>> comes forth
>> or before, whichever way the community prefers.
>>
>
> Hi Michael,
> I don't mean to rain on your parade, but I think there are better image
> libraries that are more accurate, faster, and can implement proper
> tonemapping than sws -- zimg, and libplacebo are the prime examples. I
> believe it would make more sense to integrate one of them in sws as a
> backend (and fallback) so that the api doesn't change, or, if we absolutely
> need no external deps, then write an entirely new library, but 15k$ work
> for "cleanup" on a library noone consciously wants to use seems wasteful
> IMO.
>

I agree, I'd rather see this money being spent to give libplacebo
a software path and having swscale link against it. We can
talk about importing the project as a whole separately - I don't
think it's necessary, though.
zimg would need far too much work, IMO. But I don't mind being wrong here.

I wouldn't object to writing a new library or improving swscale
either - but I do think this has to be done with a plan we could agree on.
As I said yesterday, it is easy to make a mistake.
_______________________________________________
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".