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

[Leandro Santiago]

On 3/14/25 19:21, Nicolas George wrote:
> Lynne (HE12025-03-14):
>> This is a pointless patch and a pointlessly complex addition to the build
>> system. I wouldn't accept something like this.
>> Those who for some reason have custom filters simply distribute their own
>> branch with properly integrated filters.
> That works for third-party from one third-party. This feature helps
> users who want to use filters from multiple third-party. With what you
> describe, they would have to merge the branches, which might not be
> trivial.
>
> On the other hand, the JSON in this makes it look like it was designed
> by looking at how fashionable languages NIHed their own f5g package
> system.

Thx for the review and to make it clear:

it was not my intention to suggest my implementation (using json and so 
on) as the final one or to be mainlined.

I notice now my lack of netiquette, as it seems I was not clear on 
saying that this is a proof of concept (POC, in the subject): I wanted 
to try something (support for non mainlined filters), and wanted to 
check whether that was possible or not, and finally get feedback.

Using json+jq was the quickest, dirtiest way to accomplished that.

I personally conclude that the POC was successful: I managed to get a 
new filter, not mainlined, to be built into ffmpeg. Next steps would be 
throw the code away and implement it properly

Obviously I need the agreement from you experienced ffmpeg devs for such 
conclusion.

I should probably have called it a RFC or similar. My mistake. I still 
struggle with using the mailing list contribution model, as in a PR/MR 
model I would simply keep a WIP request until it gets to a good shape. 
With the ML model, I feel doing so is very error prone, but this is 
probably my lack of experience with it.

My goal now is to know whether there is any interest from the ffmpeg 
devs on having such feature (regardless of the implementation), as there 
seems to be lots of disagreement.

I am personally interested on it, due to the fact I am writing a filter 
in Rust that is very unlikely to ever me mainlined. Right now I need to 
constantly rebase branches, but I'd be way happier if I could simply 
rely on some "official" support in the ffmpeg codebase to use it.

Another benefit could be moving out some filters that are "not very 
loved" or that tend to "get rotten". My impression/opinion is that the 
DNN stuff could very well be moved out, to evolve independently from the 
main ffmpeg repo. I totally respect the developers who worked on it, to 
be very clear. I benefit from the DNN code and want to keep it working well.

>
> If instead it was designed by asking “what would a ffmpeg developer do”,
> it would just have configure run ext/*/configure and then Makefile
> include $(CONFIG_EXT_WHATEVER).

Thank you for the feedback. I requested some thoughts on the topic a few 
days ago [1], and I see that probably the message was not clear.

I find this `simply run ext/configure approach` interesting and will 
have a look at it and later let you know my findings.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2025-March/340895.html

>
> Regards,
>