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

[James Almer <jamrial@gmail.com>]

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-request@ffmpeg.org with subject "unsubscribe".