[FFmpeg-devel] [PATCH] lavfi: add quirc filter

[Tomas Härdin]

ons 2023-12-27 klockan 12:37 +0100 skrev Stefano Sabatini:
> On date Tuesday 2023-12-26 22:33:36 -0300, James Almer wrote:
> > On 12/26/2023 10:25 PM, Stefano Sabatini wrote:
> > > On date Tuesday 2023-12-26 17:20:33 +0100, Stefano Sabatini
> > > wrote:
> > > > ---
> > > >   Changelog                |   1 +
> > > >   configure                |   4 +
> > > >   doc/filters.texi         |  35 ++++++++
> > > >   libavfilter/Makefile     |   1 +
> > > >   libavfilter/allfilters.c |   1 +
> > > >   libavfilter/vf_quirc.c   | 183
> > > > +++++++++++++++++++++++++++++++++++++++
> > > >   6 files changed, 225 insertions(+)
> > > >   create mode 100644 libavfilter/vf_quirc.c
> > > 
> > > V2 with a few fixes and all corners put in the metadata (e.g. in
> > > case
> > > the QR code is rotated).
> > 
> 
> > Looking at the library, the license is very permissive and the code
> > hasn't
> > been touched in many years. It is also pretty small, so why not
> > just add it
> > as a native filter instead of requiring an external dependency for
> > what
> > seems to be a relatively simple process?
> 
> I see pros and cons, in total that would be about 3K lines of pretty
> clean code and data, and this would simplify integration for end-
> users
> (since they would not need to build the library, which seems not
> packaged by many distributions), and having the code would help to
> solve similar problems and probably could be generalized and
> optimized
> (e.g. to support other pixel formats).
> 
> OTOH it would add to the maintenance burden since we would be owners
> of the code, which also means we would not benefit from fixes to the
> upstream project, in case they happen (last commit is from March
> 2023, so not very old):
> https://github.com/dlbeer/quirc/commit/542848dd6b9b0eaa9587bbf25b9bc67bd8a71fca

We could use git-subtree to keep in sync with upstream and to
contribute patches back. This is something I've done with other
projects. It has the following benefits:

1) Not having to deal with git-submodule
2) Having a copy of the code in case upstream goes down
3) Possibility of applying FFmpeg-only changes, say to the build
system, without having to have scripts that apply patches on top of the
submodule
4) Development can be concentrated on one implementation rather than
many. This is a point I've made with MXF but it applies here too

However, a bit of work is necessary to make packagers happy with such
an arrangeent, since I expect they would want libquirc to be a separate
package.

On the other hand we can just force users to build and install
libquirc. This is less work for us.

/Tomas