[FFmpeg-devel] Project orientation

Paul B Mahol onemda at gmail.com
Sun Jul 5 01:06:19 EEST 2020


On 7/4/20, Jean-Baptiste Kempf <jb at videolan.org> wrote:
> On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
>> Another area as we are already on the subject is stuff falling a little
>> outside what FFmpeg covers.
>> Not every filter that anyone wants to write should have to be in FFmpeg
>
> Thank $deity that you are saying this!
>
> FFmpeg is used more and more and numerous people want to put everything in
> it.
>
> The project needs to learn to say no to features and define the scope of
> each library.
>
> For libavcodec, the scope is quite clear, even if there are some debates
> about experimental codecs.
>
> But for the other libraries, including avformat and avfilter, there are
> dubious things in.
>
> For example and in my opinion, I don't see why there is support in avformat
> for things that are not standards, like AMQP/ZMQ, who are neither a
> multimedia format nor a multimedia protocol.
> In the same way, if you start to need tensorflow or openvinno for a filter,
> the code has no place in FFmpeg: you can use the api and use that
> externally. Importing tensorflow is probably more lines of code, than
> FFMpeg.
> Or speech-recognition (sphinx) or OCR (tesseract)...

This is personal attack against me and my work.

> And now comes the debate with synthesizers or complex filters that are
> almost reinventing GStreamer inside libavfilter ("let's use libavcodec as a
> filter, since everything is a filter")...
>
> When you look at the FFmpeg dependency graph on distributions like Debian,
> this is getting scrary, and this increases a lot the binary size and
> resources usage.

Nobody forces them to enable every single thing.

>
> At some point, the project needs to decide what is in and what is out, and
> since FFmpeg has numerous APIs, people can plug them externally. It's not a
> problem to say "No" to a feature, especially when, the number of people
> using that feature is under 0,01% of FFmpeg users, and when people can build
> that externally anyway.
>
>
> --
> Jean-Baptiste Kempf - President
> +33 672 704 734
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list