[FFmpeg-devel] [RFC] Funded Task Ideas

[FFmpeg-devel] [RFC] Funded Task Ideas

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]

Hi Everyone

As we are now looking for sponsors, we also should look for tasks to fund.
I suggest, we first do some brainstorming and make a list, and then figure out which
tasks we want to sponsor (or maybe someone wants to do one as a volunteer)

Heres some random ideas from me /mostly things for which i am not able to find the time ATM
(that is, iam happy if someone else does these)
please add your ideas.

* cherry pick the remaining codecs and demuxers from almpeg
* cleanup new tickets on trac (aka close (invalid/needs more info/fixed) or open
* do something about the difference between mitre and our CVE list (that is go over the output from tools/compare-cvelists.sh)
* do we have any bugs or feature requests that have alot of votes on them ?

thx

PS: once we have enough yearly income we can look at hiring / funding people fulltime.

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1120 bytes --]

On Tue, Oct 14, 2025 at 04:40:06AM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi Everyone
> 
> As we are now looking for sponsors, we also should look for tasks to fund.
> I suggest, we first do some brainstorming and make a list, and then figure out which
> tasks we want to sponsor (or maybe someone wants to do one as a volunteer)
> 
> Heres some random ideas from me /mostly things for which i am not able to find the time ATM
> (that is, iam happy if someone else does these)
> please add your ideas.
> 
> * cherry pick the remaining codecs and demuxers from almpeg
> * cleanup new tickets on trac (aka close (invalid/needs more info/fixed) or open
> * do something about the difference between mitre and our CVE list (that is go over the output from tools/compare-cvelists.sh)
> * do we have any bugs or feature requests that have alot of votes on them ?

If you are a end user or lib user, please reply too



thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 2527 bytes --]

Hi

so many great awnsers, thanks everyone!!!
please keep the ideas comming, we already ordered fast SSD disks to handle the load of ideas

On Tue, Oct 14, 2025 at 04:40:06AM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi Everyone
> 
> As we are now looking for sponsors, we also should look for tasks to fund.
> I suggest, we first do some brainstorming and make a list, and then figure out which
> tasks we want to sponsor (or maybe someone wants to do one as a volunteer)
> 
> Heres some random ideas from me /mostly things for which i am not able to find the time ATM
> (that is, iam happy if someone else does these)
> please add your ideas.
> 
> * cherry pick the remaining codecs and demuxers from almpeg
> * cleanup new tickets on trac (aka close (invalid/needs more info/fixed) or open
> * do something about the difference between mitre and our CVE list (that is go over the output from tools/compare-cvelists.sh)
> * do we have any bugs or feature requests that have alot of votes on them ?

* finish teh work needed for the FFV1 IETF CELLAR document

Heres the stuff from trac (only open not new tickets)
Has some of this been resolved alreay ?

enhancement	#8349	45	Dolby AC-4 Support
enhancement	#4907	21	Support decoding animated WebP images
defect	        #2078	14	FFMPEG created WTV files cannot be fast forwarded or fast rewound in Windows Media Center
defect  	#5419	10	HLS EXT-X-DISCONTINUITY tag is not supported
defect  	#1598	8	Muxing raw h264 into mpegts (and mkv) fails.
defect  	#4209	8	GPS coordinates location and other iOS metadata in MOV are not copied to output MP4
defect  	#6037	8	Embedded subtitle stream may cause malfunction of "-max_interleave_delta"
enhancement	#4141	8	HEVC: 1920x1080i file decoded as 1920x540p
enhancement	#4448	8	Support writing album cover art image embedded in ogg / opus metadata
enhancement	#3356	7	feature request: Segment HLS streams on SCTE 35 markers
defect  	#5641	5	Support WebVTT according to MKV specs
defect  	#5718	5	ffmpeg not remapping channels for libopus automatically
defect  	#6275	5	mov to libvorbis conversion fails

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Timo Rothenpieler via ffmpeg-devel]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1209 bytes --]

On 14.10.2025 04:40, Michael Niedermayer via ffmpeg-devel wrote:
> Hi Everyone
> 
> As we are now looking for sponsors, we also should look for tasks to fund.
> I suggest, we first do some brainstorming and make a list, and then figure out which
> tasks we want to sponsor (or maybe someone wants to do one as a volunteer)
> 
> Heres some random ideas from me /mostly things for which i am not able to find the time ATM
> (that is, iam happy if someone else does these)
> please add your ideas.
> 
> * cherry pick the remaining codecs and demuxers from almpeg
> * cleanup new tickets on trac (aka close (invalid/needs more info/fixed) or open
> * do something about the difference between mitre and our CVE list (that is go over the output from tools/compare-cvelists.sh)
> * do we have any bugs or feature requests that have alot of votes on them ?
> 
> thx
> 
> PS: once we have enough yearly income we can look at hiring / funding people fulltime.

Since we have just been approved for the EUs YesWeHack program, someone 
will need to work through the incoming bugs and triage/fix/look at them.

That could definitely be something someone could use some sponsoring for.



Timo

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3203 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 2265 bytes --]

Hi Timo

On Wed, Oct 15, 2025 at 12:28:20AM +0200, Timo Rothenpieler via ffmpeg-devel wrote:
> On 14.10.2025 04:40, Michael Niedermayer via ffmpeg-devel wrote:
> > Hi Everyone
> > 
> > As we are now looking for sponsors, we also should look for tasks to fund.
> > I suggest, we first do some brainstorming and make a list, and then figure out which
> > tasks we want to sponsor (or maybe someone wants to do one as a volunteer)
> > 
> > Heres some random ideas from me /mostly things for which i am not able to find the time ATM
> > (that is, iam happy if someone else does these)
> > please add your ideas.
> > 
> > * cherry pick the remaining codecs and demuxers from almpeg
> > * cleanup new tickets on trac (aka close (invalid/needs more info/fixed) or open
> > * do something about the difference between mitre and our CVE list (that is go over the output from tools/compare-cvelists.sh)
> > * do we have any bugs or feature requests that have alot of votes on them ?
> > 
> > thx
> > 
> > PS: once we have enough yearly income we can look at hiring / funding people fulltime.
> 
> Since we have just been approved for the EUs YesWeHack program, someone will
> need to work through the incoming bugs and triage/fix/look at them.
> 
> That could definitely be something someone could use some sponsoring for.

great, i agree.

Can we make this a bit more specific (so that in case we choose this) we have
something clear we can pass to SPI.

Should this be payment per bug fixed?
or payment per hour ?

1. I expect we need to first have a specific developer who wants to do this
2. then have SPI draft a contract for the specific jurisdiction where the developer works
3. SPI and the developer sign that
4. only then can the work start

Iam saying above because if the YesWeHack thing begins at a specific time, all above needs
to be done first, also including us finding a consensus that we do want to fund this.

(SPI has contracts for some jurisdictions already so, uncommon jurisdictions likely
 will need more time)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Kieran Kunhya via ffmpeg-devel]

On Tue, 14 Oct 2025, 23:53 Michael Niedermayer via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Hi Timo
>
> On Wed, Oct 15, 2025 at 12:28:20AM +0200, Timo Rothenpieler via
> ffmpeg-devel wrote:
> > On 14.10.2025 04:40, Michael Niedermayer via ffmpeg-devel wrote:
> > > Hi Everyone
> > >
> > > As we are now looking for sponsors, we also should look for tasks to
> fund.
> > > I suggest, we first do some brainstorming and make a list, and then
> figure out which
> > > tasks we want to sponsor (or maybe someone wants to do one as a
> volunteer)
> > >
> > > Heres some random ideas from me /mostly things for which i am not able
> to find the time ATM
> > > (that is, iam happy if someone else does these)
> > > please add your ideas.
> > >
> > > * cherry pick the remaining codecs and demuxers from almpeg
> > > * cleanup new tickets on trac (aka close (invalid/needs more
> info/fixed) or open
> > > * do something about the difference between mitre and our CVE list
> (that is go over the output from tools/compare-cvelists.sh)
> > > * do we have any bugs or feature requests that have alot of votes on
> them ?
> > >
> > > thx
> > >
> > > PS: once we have enough yearly income we can look at hiring / funding
> people fulltime.
> >
> > Since we have just been approved for the EUs YesWeHack program, someone
> will
> > need to work through the incoming bugs and triage/fix/look at them.
> >
> > That could definitely be something someone could use some sponsoring for.
>
> great, i agree.
>
> Can we make this a bit more specific (so that in case we choose this) we
> have
> something clear we can pass to SPI.
>
> Should this be payment per bug fixed?
> or payment per hour ?
>
> 1. I expect we need to first have a specific developer who wants to do this
> 2. then have SPI draft a contract for the specific jurisdiction where the
> developer works
> 3. SPI and the developer sign that
> 4. only then can the work start
>
> Iam saying above because if the YesWeHack thing begins at a specific time,
> all above needs
> to be done first, also including us finding a consensus that we do want to
> fund this.
>
> (SPI has contracts for some jurisdictions already so, uncommon
> jurisdictions likely
>  will need more time)
>

FFmpeg should move to an LTS and development version like Ubuntu.

Then companies can pay for older versions to have backports of security
fixes (like Ubuntu).

Kieran

>
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Nicolas George via ffmpeg-devel]

Kieran Kunhya via ffmpeg-devel (HE12025-10-15):
> FFmpeg should move to an LTS and development version like Ubuntu.
> 
> Then companies can pay for older versions to have backports of security
> fixes (like Ubuntu).

Absolutely not. Quite the opposite: we should stop making releases.
Focus on making good code state of the art and let people who want
stability work for it.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Nicolas George via ffmpeg-devel]

Michael Niedermayer via ffmpeg-devel (HE12025-10-14):
> As we are now looking for sponsors, we also should look for tasks to fund.

> PS: once we have enough yearly income we can look at hiring / funding
> people fulltime.

I will step into it:

This is severely misguided.

FFmpeg is a Libre Software project: its goal is to make beautiful and/or
useful software.

FFmpeg's goal is NOT to gain market shares.

FFmpeg's goal is NOT to turn a profit.

FFmpeg's goal is ABSOLUTELY NOT to get a livelihood for its authors.

The problem with people getting paid to work on FFmpeg is that it is a
misaligned incentive. It creates the incentive to push the code as is
instead of polishing it, instead of accepting suggestions to make it
better. It creates the incentive to work alone rather than seek the
insights of our peers.

I am sure some developers are able to resist the incentive and not let
the fact that they are paid for it reduce the quality of their code in
favor of speed at all. But I am also sure they are not a majority.

So, sponsorships?

Sponsorship in the form of hosting, absolutely!

Sponsorship in the form of hardware, server hardware that can benefit
the whole project as a FATE instance or remote development computer,
absolutely.

Sponsorship in the form of hardware personal for one developer in
particular: that is already more problematic.

Sponsorship in the form of funding people to code: this is where it
becomes difficult.

I think we can fund tasks that have a very precise scope:
straightforward tasks that require no creativity from the coder and
where the completion status is objective and unambiguous.

But beyond that, we should not try to fund: anything that requires
design choices, anything involving new API, etc., we should favor people
who do it because they want to do it.

We cannot prevent people from obtaining funding on their own, of course,
and neither should we. But at least we will not be in a situation of
conflict of interest: if the task is harder than they thought, if we
demand they do it better, it is between them and their sponsor, and we
are not in an awkward position.

Also, I think we should demand people to disclose when they have
specific funding like that, on pain of getting their Git write access
suspended if they neglected to do it and it gets known. We should know
when somebody's loyalty is to themselves and their sponsor rather than
to the project.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Kieran Kunhya via ffmpeg-devel]

On Wed, 15 Oct 2025, 09:32 Nicolas George via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Kieran Kunhya via ffmpeg-devel (HE12025-10-15):
> > FFmpeg should move to an LTS and development version like Ubuntu.
> >
> > Then companies can pay for older versions to have backports of security
> > fixes (like Ubuntu).
>
> Absolutely not. Quite the opposite: we should stop making releases.
> Focus on making good code state of the art and let people who want
> stability work for it.
>

It's a bit on the extreme side for me but I don't inherently have an issue
with not having releases (like x264).

Probably many others here would want that though.

Kieran
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 1294 bytes --]

Hi Nicolas, Kieran

On Wed, Oct 15, 2025 at 10:31:35AM +0200, Nicolas George via ffmpeg-devel wrote:
> Kieran Kunhya via ffmpeg-devel (HE12025-10-15):
> > FFmpeg should move to an LTS and development version like Ubuntu.
> > 
> > Then companies can pay for older versions to have backports of security
> > fixes (like Ubuntu).

I like that this would result in a steady income stream.
I think its a good idea, and iam happy to provide companies with
extended security support on old releases.


> 
> Absolutely not. Quite the opposite: we should stop making releases.
> Focus on making good code state of the art and let people who want
> stability work for it.

I certainly can relate to the "no releases" design, and like this too
But i think FFmpeg is too big to have no releases

I mean, We have companies who want releases (cant say who and what
exactly because its non public info)
These companies will pay for releases, so someone will continue making
releases. Its better if that someone is us, better for the quality of
releases and better for our income

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What is kyc? Its a tool that makes you give out your real ID, while criminals
give out a forged ID card.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org

[FFmpeg-devel] Re: [RFC] Funded Task Ideas

[Michael Niedermayer via ffmpeg-devel]

[-- Attachment #1.1: Type: text/plain, Size: 3316 bytes --]

Hi Nicolas

On Wed, Oct 15, 2025 at 04:53:28PM +0200, Nicolas George via ffmpeg-devel wrote:
> Michael Niedermayer via ffmpeg-devel (HE12025-10-14):
> > As we are now looking for sponsors, we also should look for tasks to fund.
> 
> > PS: once we have enough yearly income we can look at hiring / funding
> > people fulltime.
> 
> I will step into it:
> 
> This is severely misguided.
> 
> FFmpeg is a Libre Software project: its goal is to make beautiful and/or
> useful software.
> 
> FFmpeg's goal is NOT to gain market shares.
> 
> FFmpeg's goal is NOT to turn a profit.
> 
> FFmpeg's goal is ABSOLUTELY NOT to get a livelihood for its authors.
> 

> The problem with people getting paid to work on FFmpeg is that it is a
> misaligned incentive. It creates the incentive to push the code as is
> instead of polishing it, instead of accepting suggestions to make it
> better. It creates the incentive to work alone rather than seek the
> insights of our peers.

I think you see only one possible way of doing this.
But really there are MANY ways

For example, one can pay for maintaince, for fixing issues.
One can pay developers and leave it up to them what to work on.

Just imagine for a moment we had 1M$ income per year in SPI or a ffmpeg foundation
we could pay 10+ developers fulltime and still leave it completely to them
what they work on.
There is no incentive to do things quick and ugly.


> 
> I am sure some developers are able to resist the incentive and not let
> the fact that they are paid for it reduce the quality of their code in
> favor of speed at all. But I am also sure they are not a majority.

From what iam reading on the subject of code quality and people, in general
developers care about code quality (also in commersial settings) this can
be a matter of pride and such stuff. Noone wants "their" code to be ugly
while management and also customers may push for "quick"

Of course if the developer doing the work is not competent the code will
show it but thats not "because its funded", its "because the developer had
a bad teacher or no teacher", or maybe because he wasnt given enough time

Also the real goal of funding, which i think people miss is to
facilitate that people can work on teh code.

That is very few can work fulltime on FFmpeg because, they need to pay rent
for their appartment, pay food, taxes, ... bascially the cost of living isnt 0

Funding a developer, be that as a contractor or emplyoee, is to allow him/her
to work more on FFmpeg.

You can also see it as,
* you pick people who want to work fulltime on FFmpeg and who have demonstrated
  previously they can and produce good code (or whatever other contribution they did) and ...
* then get them funded so they can work fulltime on FFmpeg

Theres no incentive here to produce bad code.

Also theres in fact often incentives to produce better code.
If you hire a contractor for a specific coding job. And the code she
produces is bad quality. Will you hire her again ?
No, so thats an incentive to produce good quality

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 163 bytes --]

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org