On Tue, 15 Oct 2024 18:12:21 +0200 Michael Niedermayer <mich...@niedermayer.cc> wrote: > Hi all > > This is a quick RFC about peoples oppinions on AVFilter > > The question: Should anyone be able to write a filter (which > other people can use) ? > Or should only we be able to add filters ?
As a compromise, we could allow external filters with a more strict ABI requirement, i.e. the filter must be built against the exact same version of libavfilter. That way, we could still change the API as needed, without needing to maintain long-term ABI compatibility. I think that from a corrent PoV, the status quo of external filters being added out-of-tree at build time is fine, and maybe we could make that process a bit easier. Another thing to mention is that a lot of downstream use cases for custom filters could be solved by adding a single proprammable "custom" filter that calls a user-provided callback function. This filter could be given a more limited but stable API, without limiting our ability to change the internal details. Think of something like buffersink/buffersrc, but for custom filters. > > (This relates to what parts of the API are publically accessable) > > So whats the point of this RFC ? > > If we want a public API that allows writing filters then work on the API > has to be compatible with that direction. > > "compatible" for example would be, "Adding whats missing to the public API" > or "deprecating existing API and writing a better API that makes all needed > parts public" > > "incompatible" for example is "making bits and pieces private that are needed > by filters > > Some of the currently pending patches seem to fall into the "incompatible" > category, while iam not sure what peoples oppinions is on the direction > of AVfilter, which is why iam bringing this up > > Thx > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is a danger to trust the dream we wish for rather than > the science we have, -- Dr. Kenneth Brown > _______________________________________________ > 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". _______________________________________________ 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".