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

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Samstag, 29. März 2025 02:17
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: Proof of Concept: enable
> out-of-tree filters
> 
> 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

Hi Michael,

I suppose you haven't looked at the video. What it is showing are conflicts in exactly all of those files where you think it would be easy going for Git, but unfortunately that's not the case. Even a simple one-line addition can create large conflicting blocks (many lines). This is what I'm talking about and I've created that video because it's not what you would expect to happen, but it happens all the time and it's often a much bigger annoyance than API adaptions.

It's not quite clear why it happens, maybe it has something to do with how Git identifies the context areas of changes. I'm wondering whether it could handle it better if there were one or two blank lines in-between..?

> 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

configure, makefile, allfilters and these kinds of files are the troublemakers - from my experience at least.


> 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)

😊 

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