Hi

On Sat, Mar 29, 2025 at 03:52:52PM +0100, Leandro Santiago wrote:
[...]
> The good side of it is that it's up to the developer of the external filter to worry about keeping track with changes in the ffmpeg core, not the other way round.
> 
> >
> > That is each filter developer simply maintaining a fork of ffmpeg and their
> > filter, in that fork. Adding lines to configure, Makefile, ...
> >
> > If we take the last filter as a random example, what it chanegd looks like this:
> >
> >     avfilter/interlace_vulkan: add interlace_vulkan filter
> >
> >     This is a Vulkan-accelerated version of the existing interlace filter.
> >
> >  configure                         |   1 +
> >  doc/filters.texi                  |   2 +-
> >  libavfilter/Makefile              |   1 +
> >  libavfilter/allfilters.c          |   1 +
> >  libavfilter/vf_interlace_vulkan.c | 313 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  5 files changed, 317 insertions(+), 1 deletion(-)
> Interesting, the case of documentation integration is still an open issue on my proposal. I'll have a look at it.
> >
> > 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
> 
> How would that work when the user is building ffmpeg+external-filters via release tarballs?

If one seriously wanted this, we could include the .git directory in the tarball.

But someone who wants to include any type of module at compile time will
have to work with various tools. like a compiler and configure
and some way to obtain the module into the right place.

typing
git pull --no-rebase --no-edit https://github.com/author/project branch
is simpler

ATM, i see a system we need to maintain that supports only libavfilter
and git which we dont have to maintain that supports every module
Iam lazy, so iam drawen toward git

If git fails to work, then we can look into other solutions,
can you try simply using git and check if it would work ?


> 
> >
> > 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
> >
> > Also it much easier alows transitioning between actually including a filter
> > in git master, if the community desires that for a filter later.
> 
> For those cases, git has good support for merging unrelated repositories with unrelated histories those days. I have experienced using it on less complex codebases and it worked really well.
> 

> Do you think it would be problematic? [1]
> 
> [1] https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---allow-unrelated-histories

yes

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin