Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Lynne <dev@lynne.ee>]

Apr 17, 2024, 16:34 by jamrial@gmail.com:

> On 4/17/2024 11:22 AM, Lynne wrote:
>
>> Apr 17, 2024, 15:58 by michael@niedermayer.cc:
>>
>>> Hi all
>>>
>>> The pace of inovation in FFmpeg has been slowing down.
>>> Most work is concentarted nowadays on code refactoring, and adding
>>> support for new codecs and formats.
>>>
>>> Should we
>>> * make a list of longer term goals
>>> * vote on them
>>> * and then together work towards implementing them
>>> ?
>>>
>>> (The idea here is to increase the success of larger efforts
>>>  than adding codecs and refactoring code)
>>> It would then also not be possible for individuals to object
>>> to a previously agreed goal.
>>> And it would add ideas for which we can try to get funding/grants for
>>>
>>> (larger scale changes need consensus first that we as a whole want
>>>  them before we would be able to ask for funding/grants for them)
>>>
>>> Some ideas and why they would help FFmpeg:
>>>
>>> * Switch to a plugin architecture
>>>  (Increase the number of developers willing to contribute and reduce
>>>  friction as the team and community grows)
>>>
>>
>> Just no.
>>
>
> Can you elaborate on why? The one thing i think would be problematic is making the AVCodec internals public, which could get in the way of improvements.
>

First, we'd have the bad SoC vendors making binary plugins, with
no attempts made of using existing standards like V4L2 or Vulkan.
Then, we'd have the shit companies making hardware CUDA encoders
and decoders life much easier by no longer having to ship patches,
point to a git version, plus a binary.
We'd have closed-source filters circulating around. Closed-source
improved MPEG-TS or HLS demuxers that we haven't had enough
power to fix.

All of the users of those will send their issues to us.
None of the authors will open-source their work.
We'd receive zero benefits from any of this.
The whole multimedia ecosystem will not benefit from it.
License-wise, it would be like we have an MIT license.
We'd be bound to keep the ABI stable for what may very
well be a very long time, with any breakage creating a Python 3
situation.

It's a bad idea.
_______________________________________________
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".