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

[Stefano Sabatini]

On date Friday 2023-12-29 12:57:15 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-12-27 21:57:19 -0300, James Almer wrote:
> > On 12/27/2023 8:20 PM, Stefano Sabatini wrote:
> [...]
> > > > 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.
> > 
> > Image analysis is within FFmpeg's scope, which QR code identification and
> > decoding would be about.
> > 
> > > 
> > > *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.
> > 
> > No, i'm not blocking anything. Just stating that ideally this would be a
> > native module.
> 
> I'm not against this of course, but as I already stated this would
> require more effort. It is probably worth it (polynomials and Galois
> fields based error correction) as they would be probably reused in
> other parts of the code. Ditto for the QR encoder.
> 
> But I plan to have this functionality in with the wrappers - this
> should also help with an eventual native port of the features.
> 
> I plan to push this patch in a few days, unless I see comments.
> 
> Thanks for the feedback.

Applied.