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

[epirat07@gmail.com]

On 18 Apr 2024, at 10:46, Stefano Sabatini wrote:

> On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote:
>> 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:
>>
> [...]
>> * client side / in browser support
>>     (expand towards webapps, webpages using ffmpeg client side in the browser)
>>     bring in more users and developers, and it will be costly for us
>>     if we let others take this area as its important and significant
>
> There are already several projects on github, the most prominent one:
> https://github.com/ffmpegwasm/ffmpeg.wasm/
>
> In general it would be useful to provide libav* bindings to other
> languages, for example:
> https://github.com/PyAV-Org/PyAV
> https://github.com/zmwangx/rust-ffmpeg
>
> Not sure these should be really moved to FFmpeg though.
>
> One option I'm currenly exploring is having a python filter enabling
> to specify a custom filter implemented in python (needed for custom
> ad-hoc logic you don't really want to implement in C since it's not
> generic enough) and to enable using python modules when effiency is
> not an issue.

Lua would probably be a better choice for this from ease of integration
and also speed PoV last I checked. IIRC Python had some rather complex
threading implications when used in a library.

But I agree having something like this in general seems nice for some
prototyping and debugging with filters as well.

> _______________________________________________
> 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".
_______________________________________________
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".