On date Friday 2023-12-01 16:08:23 +0100, Tomas Härdin wrote:
> tor 2023-11-30 klockan 15:39 +0000 skrev Cosmin Stejerean via ffmpeg-
> devel:
> >
> > > On Nov 30, 2023, at 03:07, Tomas Härdin <g...@haerdin.se> wrote:
> > >
> > > tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
> > > > This is meant to introduce functionality to handle QR codes.
> > >
> > > Why?
> > >
> >
> > The why seems to be answered below the section you quoted in the
> > original email
> >
> > > QR codes are robust to lossy coding, therefore it should be
> > > possible to use them to compare a generated video with a reference
> > > one (in case
> > they cannot be compared frame-by-frame).
>
> Is the intent to generate per-frame QR codes? I guess that has some
> merit. [...]
Yes, this was the main use case (if you see the patches I'm reusing
the same expansion mechanism we have in drawtext, for example we can
specify "%{n}" to encode the picture number). Then I plan to extend it
with a filter overlaying on the input frame, and with a decoder
(thinking to use again an external library - quirc - assuming there
are no objections in that direction).
> Otherwise it seems pointless if it's just for generating a
> single QR code which could just as well be done with an external
> program and then overlaying the resulting image.
But in general, having integrated QR encoding it's more than
overlaying a single static QR code, you might want to encode some
specific frame metadata or change/disable the QR to encode through a
filter command, so it would be IMO good to have it for many different
use cases.
_______________________________________________
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".
