[FFmpeg-devel] [PATCH] avfilter: Proof of Concept: enable out-of-tree filters

[Leandro Santiago]

On 3/28/25 22:38, Michael Niedermayer wrote:
> Hi Leandro
>
> On Mon, Mar 24, 2025 at 05:20:02PM +0100, Leandro Santiago wrote:
>> In this iteration I've made the following changes, based on the received feedback:
>>
>> - No external tools are needed by the build system.
>>
>> - The external filters should be put in ext/libavfilter. Anything there will be included.
>>
>> - The build system will execute a file called `configure.sh` in the directory of the external filter. This script has access to the functions and variables defined on `./configure`, as it's included via `.` on sh.
>>
>> - I will document the "API" for the external filters as soon the approach is approved, but an example of filter can be found at https://gitlab.com/leandrosansilva/ffmpeg-extra-filter-example . If you are unhappy with the example code hosted on gitlab.com, I can move it elsewhere where it gets easier for you to have access to the code.
>>
>> - Essentially, an external filter is composed by at least a `configure.sh` and a `Makefile`.
>>
>> 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 :-)
> How does this compare to simply using
> git merge

The main difference is being 100% resistant to merge/rebase/cherry-pick conflicts :-)

There is of course the possibility that the filter won't compile at all (or compile and be buggy) due to the changes in libavfilter or build system.

The good side of it is that it's up to the developer of the external filter to worry about keeping track with changes in the ffmpeg core, not the other way round.

>
> That is each filter developer simply maintaining a fork of ffmpeg and their
> filter, in that fork. Adding lines to configure, Makefile, ...
>
> If we take the last filter as a random example, what it chanegd looks like this:
>
>     avfilter/interlace_vulkan: add interlace_vulkan filter
>
>     This is a Vulkan-accelerated version of the existing interlace filter.
>
>  configure                         |   1 +
>  doc/filters.texi                  |   2 +-
>  libavfilter/Makefile              |   1 +
>  libavfilter/allfilters.c          |   1 +
>  libavfilter/vf_interlace_vulkan.c | 313 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 317 insertions(+), 1 deletion(-)
Interesting, the case of documentation integration is still an open issue on my proposal. I'll have a look at it.
>
> The advantage of "git merge" wether by hand or by a automated tool
> is that its not limited to what it can do. Its much more powerfull

How would that work when the user is building ffmpeg+external-filters via release tarballs?

>
> and the changes outside adding the filter itself are very basic.
> Conflicts are something that we can workaround in many ways if they
> become a problem
>
> Also it much easier alows transitioning between actually including a filter
> in git master, if the community desires that for a filter later.

For those cases, git has good support for merging unrelated repositories with unrelated histories those days. I have experienced using it on less complex codebases and it worked really well.

Do you think it would be problematic? [1]

[1] https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---allow-unrelated-histories

>
>
> thx
>
> [...]
>
> _______________________________________________
> 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".