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

[Stefano Sabatini <stefasab@gmail.com>]

On date Wednesday 2023-12-27 14:16:24 -0300, James Almer wrote:
> On 12/27/2023 8:37 AM, Stefano Sabatini wrote:
> > 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
> 
> That's a build system change, so not really relevant. Last real change was https://github.com/dlbeer/quirc/commit/cc673124335785d220dbb9057b21c51e4a87e0b2,
> also from March 2023, but the one before it is from August 2021.
> 

> I really think this should be ported as a native filter. It's not big and
> complex like a scaler (sws, zscale) which should not live within
> libavfilter.

> Any change can be contributed back to libquirc

This is not realistic, given that a reimplementation would be possibly
completely refactored to fit into FFmpeg.

> (A library
> that's not going to be abandoned like it happened with libdcadec after it
> was merged into lavc,

OTOH, this library is quite outside the scope of the FFmpeg, so it
makes sense to keep it as external dependency. This is a quite
different use case than a decoder, a QR-decoder library can make sense
outside of a multimedia library, for a decoder you would need a
complete multimedia library anyway.

I was checking the code, and porting would be a serious effort and
comprise several thousands lines of code (against the moderate effort
of wrapping it - which is already done), also some of the logic would
not really fit into FFmpeg because it is quite specific to this
application domain (QR code decoding), so it makes sense for it to
live within an external library. Not to mention that this would be
a duplication of effort.

*Unless* someone is willing to port/reimplement the code, but this
should not be a blocker for the wrapper and can be done as a separate
step.
_______________________________________________
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".