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: Sonntag, 30. März 2025 00:30
> 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 Sat, Mar 29, 2025 at 01:45:38AM +0000, softworkz . wrote:
> >
> >
> > > -----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..?
> 
> 
> git merge is widely used in project MUCH bigger than our codebase

When the branch to merge has the same baseline with only the additional commits on top it works fine of course. That's equivalent to the patchsets on the ML needing to be created against the master branch.
It also works fine for larger merges like when you have a beta that's far ahead of a stable branch and merge it finally into stable. But merging something from an older and possible diverged baseline on top of a newer baseline is a different story.


> can you show an example with command line git ?
> like a simple sequence of commands that result in problems, that i can
> replicate to look at what happens exactly


Sure:


git clone https://git.ffmpeg.org/ffmpeg.git

cd ffmpeg

git checkout master

git remote add softworkz https://github.com/softworkz/FFmpeg

git fetch softworkz

# Test 1
git cherry-pick 39bb78e449a1df67ed5b3b0fafa86af7e115cb36


# Test 2
git cherry-pick --abort
git cherry-pick 7dbb6890f2eb6035eb9123ce2039f6dbbc082b3d


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