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

[Leandro Santiago]

On 3/14/25 16:04, Michael Niedermayer wrote:
> Hi
>
> On Thu, Mar 13, 2025 at 01:18:49PM +0100, Leandro Santiago wrote:
>> This is a POC/prototype that aims to enable out of tree filters on
>> FFmpeg.
>>
>> Here I name them "extra filters".
>>
Thinking now, "extra filters" is not a good name. Maybe "external" or "oot"
>> It introduces the program `jq` as a new build dependency.
> I dont think this dependency is needed to achieve linking to filters
> in another directory
To make it clear, the "extra filters" are linked in the same way the 
current filters are: direct as part libavfilter.(so|a). They are not 
dynamically linked.
> i think its worth the few hours extra time to find a clean/nice way to do it
> with no new depeandancies

I used json as a quick way to define the filter metadata (thus the usage 
of JQ to query them), but I confess it could have been any other format. 
I used json to get the proof of concept done :-)

Ideally it would be written in a native format to the build system, if 
something like CMake or Meson was being used.

Maybe the metadata could even be in a Makefile or spread over multiple 
files with no structure. The use of json was for pure convenience. Would 
you have any format to suggest? Is there anything similar in the 
codebase I could have a look at?

This is an example of metadata file at the moment:

{
"ldflags":"-ljson-c",
"cflags":"-DFOO=234",
"check":"require_pkg_config json json-c json-c/json.h json_c_version_num",
"symbols":["ff_vf_foo","ff_vf_bar"]
}

A simpler way to represent it would be put each field in a different 
pure text file, for instance:

symbols.txt:

ff_vf_foo ff_vf_bar

The most important aspect here is that the filter metadata (symbols, 
names, flags) need to be in a format easy to parse from the `configure` 
script.

I did some improvements on my patch and I managed to get the filter to 
pass extra flags on building.

Although the use of forgejo is not yet official, I am keeping my changes 
on it for now, as I still struggle with the email workflow:

https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/13

The "example" filter can be found at:

https://gitlab.com/leandrosansilva/ffmpeg-extra-filter-example/

To use it, simply clone this repo and build ffmpeg with 
`--extra-filter=/path/to/ffmpeg-extra-filter-example`.

>
> also there is the quite intriguing option of using "git merge" to include
> external filters
> What i mean here is that there could be a script lets call it ffmerge
How would it work when using release tarballs, without git?
> "ffmerge available" would check some online repository and list whats
> compatible with the current checkout
>
> "ffmerge merge shiny_filter" would then merge the shiny filter repository/branch
Wouldn't it put more burden over the devs to maintain such 
catalog/repository and the tooling around it? I am fine with that, I 
just wonder how the community would accept it. Having no filter 
catalog/repo feels to be the simplest step one could take at the moment.
>
> Advanatge would be that this is more powerfull than just linking external
> filters.
> Disadvantage is that for this to work care needs to be taken that conflicts
> do not occur

I see that simply keeping the filter outside and linking them at build 
time put almost no burden on the ffmpeg devs.

As, provided there is no promise of a stable API, it's up to the 
developers of the "extra" filters to make their filters build.

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