[FFmpeg-devel] [PATCH] lavfi: add xbr filter
Clément Bœsch
u at pkh.me
Tue Oct 28 19:16:45 CET 2014
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>
More information about the ffmpeg-devel
mailing list