[FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

Michael Niedermayer michael at niedermayer.cc
Tue Oct 17 17:36:37 EEST 2023


On Sat, Oct 14, 2023 at 07:53:04PM +0200, Stefano Sabatini wrote:
> On date Friday 2023-10-13 21:19:34 +0200, Michael Niedermayer 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.
> 
> Leaving apart the technical details about the implementation, this
> should be feasible within the SPI framework (although this would
> involve some paperwork and delays due to that).
> 
> It would be useful at this point to define the process to accept the
> proposal and potential candidates. We have a technical committee which
> might take the lead on that and probably have the last word on it,
> since "approved by the community" is a bit vague and there is the risk
> that there will be never an approval "from the community" because of
> diverging views, or that we get stuck at the design level.

I think there are several shades of this

The community might simply have a consensus that X should be funded.
We achieved this both for traval and hw in all or nearly all cases.
And quite plausibly we will achieve this too for other cases

Hypothetically the community might have a consensus some work should
be funded but not agree on technical details.
Here honestly i think the developer doing the work should be the main
decission maker. She is the one doing the work, knowing the code best.
And most likely its one of the FFmpeg team doing the work.

The technical committee could be used if reviewer and author cannot agree.

I think we should stir clear of a "Planned economy" where some group thats
"distanced" from the actual work decides on fine details. These did not work
very well in real economies and i doubt it would work well for technical
design.
Furthermore the person doing specific work really should be, when she does
the work be the one with the best understanding of the code (otherwise we
"hired" the wrong person) so to me it makes sense she also would make
decissions on technical details. At the same time she also takes
responsibility for teh decission ...

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20231017/7193f124/attachment.sig>


More information about the ffmpeg-devel mailing list