[FFmpeg-devel] Project orientation

赵娟 zhaojuanamy at gmail.com
Fri Jul 31 15:00:10 EEST 2020


On Sun, Jul 5, 2020 at 5:26 AM 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)...
> 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.
>
> 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.
>

It's a good point, looking forward to the "plugin" mechanism.
Frankly speaking, some of the filters don't have to be upstreamed to
FFmpeg, but cloud service providers are using FFmpeg to build the media
pipeline. So the filters may receive some requirements to provide the
functionality through FFmpeg.
If developers can provide a standalone plugin to FFmpeg, and host them by
their own, that's something good, and reduce the complexity of FFmpeg.
But for now, developers can only maintain a patchset which may not be able
to upstream for many reasons.

Thanks,
Juan


>
>
> --
> 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