On 12/27/2023 8:20 PM, Stefano Sabatini wrote:
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.
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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
