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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3156 bytes --]

Hi

On Fri, Mar 28, 2025 at 10:23:50PM +0000, softworkz . wrote:
[...]
> >
> > 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
> 
> Git merge only works when there's a common baseline and the only difference is the filter commit on top that you want to merge. It cannot be used when there are different baselines, e.g. the filter is on top of a the latest master branch and you want to merge it into an older (release) branch, as that would add all the differences, not just the filter.
> What you can do is cherry-picking the commit which adds the filter, but the bigger the differences of the baseline, the bigger the problems when cherry-picking. 
> 
> 
> > 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
> 
> The changes are basic in fact, but the trouble it is causing each time is beyond basic.
> 
> To give you an idea of what I'm talking about I've recorded a short screencast to illustrate what I mean:
> 
> https://gist.github.com/softworkz/750da15adb259fa13c6b32277647d54e 

Conflicts can only occur in areas belonging to more than one module
ATM, when adding a filter thats allfilters.c, Makefile, doc/filters.text and configure
(and very similar files for other things than filters)

As nicolas suggested, if each filter is in its own directory no conflict
is possible.
configure just needs to include the Makefile, doc/*.texi, allwhatever.c
from each of these directories

About merges and revission differences.
A filter for ffmpeg 2.0 will possibly not work with 1.0 (in the currect
designs of using the internal API/ABI)

So if you have a filter based on 1.0, one on 1.0.3 and one on 1.0.8
and you merge these with the ffmpeg release 1.0.12
you get exactly the right thing full automatically

You can cherry pick too and the effect is about the same but if filters
share a common component merging will likely be less conflicting

What iam suggesting, i guess is,
* allow new modules to live in seperate directories
    (even without any external modules this gives us fewer conflicts)
* maintain a simple list of such externally maintained modules on
  ffmpeg.org (users need a place to find these modules, especially
  in a world where mallicious code is becoming more widespread)
* really the user can use git merge directly but we could give him
  a tool that gives a clearer success/fail and leaves no failed merges

secret-plan: every halloween we release ffmpeg-monster that merges EVERY
actively maintained module which dosnt conflict. (this would also
encourage module maintainers, to maintain their code)

thx
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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