Hi Ronald, > -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Ronald > S. Bultje > Sent: Dienstag, 25. März 2025 19:05 > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: Proof of Concept: enable > out-of-tree filters > > Hi, > > On Mon, Mar 24, 2025 at 12:20 PM Leandro Santiago > <leandrosansi...@gmail.com> > wrote: > > > I really hope this can be the last iteration, as I ran out of ideas on > how > > to simplify the process, so please let me know your thoughts :-) > > > I'm not sure I understand the rationale or goal of this. It seems you're > trying to create a process for extending the source/build tree with > components not part of our git. Is this something people are interested > in?
Yes. > I've never heard this use case before. It had been discussed here (tangentially): https://ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338807.html and here: https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2025-February/340030.html It's kind of an alternative to a run-time plugin-model to which some have expressed reservations. Interests are multifold. It makes it easier to maintain custom filters across branches and versions of the main code, it allows people to create things which don't have a chance to get into the codebase for various reasons: like being too specific for general use, being tied to a specific vendor, using remote APIs that are too volatile, being too experimental or whatever else can be. Needless to mention the many AI related use cases. Without providing any kind of extensibility, other solutions will fill that gap and Ffmpeg relevancy will drop in the coming years IMO. Best, sw _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
