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

[Clément Bœsch]

On Tue, Oct 28, 2014 at 06:30:34PM +0100, Stefano Sabatini wrote:
[...]
> How much effort would it take to implement the remaining scaling modes?
> 

According to
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164574.html

"I think 4x can be done fast enough, but 3x will take time."

[...]
> > +typedef struct {
> > +    uint32_t rgbtoyuv[1<<24];
> 
> We should avoid this 64MiB. Also the table should be possibly static,
> so you don't have to fill it per each xBR instance.
> 

So, I requested to do it exactly the same as HQx because this part is
common according to the specifications. This should be kept the same
vf_hqx, and then factorized.

Now about removing this allocation, I did benchmark this LUT vs
computation (see attached patch for comp. version). And the problem is
that it's slightly slower, probably due to the /1000.

I wasn't able to make it bitexact with the current code using bithacks,
and while this sounds like a tolerable inaccuracy, it actually isn't and
has an impact of the output. For example, doing this (on top of attached
patch):

diff --git a/libavfilter/vf_hqx.c b/libavfilter/vf_hqx.c
index 41a77cf..f4d8006 100644
--- a/libavfilter/vf_hqx.c
+++ b/libavfilter/vf_hqx.c
@@ -29,6 +29,7 @@
 
 #include "libavutil/opt.h"
 #include "libavutil/avassert.h"
+#include "libavutil/colorspace.h"
 #include "libavutil/pixdesc.h"
 #include "internal.h"
 
@@ -58,9 +59,9 @@ static av_always_inline uint32_t rgb2yuv(uint32_t c)
     const int r = c >> 16 & 0xff;
     const int g = c >>  8 & 0xff;
     const int b = c       & 0xff;
-    const uint32_t y = (uint32_t)(( 299*r + 587*g + 114*b)/1000);
-    const uint32_t u = (uint32_t)((-169*r - 331*g + 500*b)/1000) + 128;
-    const uint32_t v = (uint32_t)(( 500*r - 419*g -  81*b)/1000) + 128;
+    const uint32_t y = RGB_TO_Y(r, g, b);
+    const uint32_t u = RGB_TO_U(r, g, b, 0);
+    const uint32_t v = RGB_TO_V(r, g, b, 0);
     return y<<16 | u<<8 | v;
 }
 

...leads to this: https://lut.im/S9sJXgGU/ttB0B1j1 vs
https://lut.im/9iRC6VMx/ef3PKqYd (look at the sorcerers typically, or
bomberman)

Even with a higher bit depth and checking the rounding, I had differences.

So for now, I prefer to keep the LUT unless someone has a better idea. And
anyway, this is orthogonal to this patch.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-avfilter-hqx-WIP-remove-LUT.patch
Type: text/x-diff
Size: 11294 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141028/eafbc8d7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141028/eafbc8d7/attachment.asc>