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

[Clément Bœsch]

On Mon, Oct 27, 2014 at 10:02:25AM +0100, Nicolas George wrote:
> Le sextidi 6 brumaire, an CCXXIII, arwa arif a écrit :
> > I have done all the changes except rgb to yuv conversion. I will most
> > probably do it by tonight.
> 
> > +    /*Convert RGB to Y'UV*/
> > +    int y = r * .299000 + g * .587000 + b * .114000;
> > +    int u = r * -.168736 + g * -.331264 + b * .500000;
> > +    int v = r * .500000 + g * -.418688 + b * -.081312;
> > +
> > +    /*Add HQx filters threshold & return*/
> > +    return (y*48) + (u*7) + (v*6);
> 
> A bit of maths would greatly help simplifying the code here. I am too lazy
> to make the computations myself, so according to PARI/GP, just copy-pasting
> your formulas (and trimming useless zeros from the output to make it more
> readable):
> 
> ? y = r * .299000 + g * .587000 + b * .114000;
> ? u = r * -.168736 + g * -.331264 + b * .500000;
> ? v = r * .500000 + g * -.418688 + b * -.081312;
> ? (y*48) + (u*7) + (v*6)
> %4 = 16.170848*r + (23.345024*g + 8.484128*b)
> 
> Since your numbers are all integers in the [-255;+255] range and your
> computations are made on 32-bits integers, scaling everything by a factor K
> would work for K between roughly 256 and 170000. Using 65536 seems like a
> good choice:
> 
> return (1059773 * r + 1529939 * g + 556016 * b) >> 16;
> 
> Of course, in this kind of case, a comment must be added to explain where
> the numbers come from.
> 

The specs says it's the same algorithm as HQx, the code just needs to be
refactored, the integer convertion is already written there.

[...]

-- 
Clément B.
-------------- 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/20141027/30762601/attachment.asc>