From: Leandro Santiago <leandrosansilva@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters Date: Fri, 14 Mar 2025 17:13:23 +0100 Message-ID: <66647849-682a-45d1-8015-e6173a8e51f8@gmail.com> (raw) In-Reply-To: <20250314150455.GJ4991@pb2> 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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2025-03-14 16:13 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-03-13 12:18 Leandro Santiago 2025-03-13 12:20 ` Leandro Santiago 2025-03-14 15:04 ` Michael Niedermayer 2025-03-14 16:13 ` Leandro Santiago [this message] 2025-03-14 20:58 ` Michael Niedermayer 2025-03-14 16:57 ` Lynne 2025-03-14 18:21 ` Nicolas George 2025-03-14 19:43 ` Leandro Santiago 2025-03-14 22:45 ` Soft Works
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=66647849-682a-45d1-8015-e6173a8e51f8@gmail.com \ --to=leandrosansilva@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git