[FFmpeg-devel] Fwd: [RFC] libpostproc splitout

[Rémi Denis-Courmont]

Le perjantaina 22. marraskuuta 2024, 20.45.39 EET Michael Niedermayer a écrit 
:
> How much do you charge to split out libpostproc ?
>
> Note you _have to_ maintain the code afterwards,

Who says that it has to be maintained, how and why?

> not just treat it as if split out means deleting it from ffmpeg.

Err, but yes. From the perspective of FFmpeg-devel, once libpostproc is spun 
off from FFmpeg, then it is no longer maintained by FFmpeg developers. So we 
_must_ treat the hypothesis as a deletion from FFmpeg.

You can argue all you want about the cost of maintainance on libpostproc-
devel. As Vittorio noted, you probably find nobody who actually cares. But even 
if you do, it is no longer a question for FFmpeg-devel.

> It must in the end include a bugtracker, wiki,

If it stays in FFmpeg, then it does not need those things because it gets them 
from FFmpeg. And if it does not stay in FFmpeg, then those are no longer our 
problem.

> packages in distributions,

I think that distributions will gladly remove it if FFmpeg-devel acknowledges 
that it is dead. Even on Debian, it has very few reverse dependencies outside 
of FFmpeg, the usual culprits: Kodi, MEncoder, MPlayer, VLC, Xine. And I don't 
think that it is being used much even then.

> documentation, self tests and so on and probably a lot more needs would come
> up

> also git history must be bisectable, and future changes from ffmpeg
> buildsystem must be merged

WTH? It would take an insane amount of time to rewrite a synthetic bisectable 
history. That would definitely not be worth the effort (or not worth paying 
someone hourly wage for it anyway).

Surely there is more impactful potential use of STF funding.

> also look at libpostproc, this code is not upto todays standards.
> Iam sure you agree ?

Most probably but that's not a problem if we kill it or spin it off.

> This thing needs a new API, it needs a clean internal filter interface
> Theres no way or sense in copy and pasting this and then "maintaining" it

Who needs the thing to have a new API? Sure the API may be old and poorly 
designed but that is not worth fixing _per_se_. It would be worth fixing if it 
caused security issues, real bugs, prevented wanted new features, impeded 
writing new code around it, etc.

With my VLC TC hat on, I don't expect us to have time to rewrite the VLC 
libpostproc plugin considering how little (if any) use it gets. I imagine that 
Kodi is in a similar position, not to speak of the state of the Xine project.

> I intended to do all the above and likely more for 15k euro.
> And i have yet to see someone offer to do this for less. Its easy to
> say "its worth less", iam still waiting for the one who actually does
> it for less.

Didn't Kieran, I and a few other warn you against using FFmpeg-devel for 
making decisions on usage of STF funding? Can't say you weren't warned. Once 
again, you can't have it both ways.

You can choose to eat your words, ignore all the motivated opposition here, 
and take STF funding without the FFmepg community acquiescing. Or you live 
with the consequences of your own decisions and do not fund libpostproc, - 
because clearly nobody other than you cares about it.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/