[FFmpeg-devel] [PATCH/WIP] lavfi: hqx filters.

[Clément Bœsch]

On Tue, Jun 10, 2014 at 03:55:09AM +0200, Michael Niedermayer wrote:
> On Sun, Jun 08, 2014 at 11:15:17PM +0200, Clément Bœsch wrote:
> > ---
> > Only hq2x for now.
> > 
> > Original code for hq2x is about 2800 lines of unrolled code. Current filter is
> > about 300 lines of code. The code in hq2x_interp() is generated from
> > https://github.com/ubitux/hqx ("make code" - see also "make show"), which is
> > done by parsing, analyzing and cutting down hq2x.c and friends.
> > 
> > The same need to be done for hq3x and hq4x. I don't know how long it will take.
> > Help welcome for those interested.
> > 
> > See also Ticket #3404.
> [...]
> 
> > +static av_always_inline uint32_t interp_2px(uint32_t c1, int w1, uint32_t c2, int w2, int s)
> > +{
> > +    return (((((c1 & 0xff000000) >> 24) * w1 + ((c2 & 0xff000000) >> 24) * w2) << (24 - s)) & 0xff000000) |
> > +           (((((c1 & 0x00ff0000) >> 16) * w1 + ((c2 & 0x00ff0000) >> 16) * w2) << (16 - s)) & 0x00ff0000) |
> > +           (((((c1 & 0x0000ff00) >>  8) * w1 + ((c2 & 0x0000ff00) >>  8) * w2) << ( 8 - s)) & 0x0000ff00) |
> > +           (((((c1 & 0x000000ff)      ) * w1 + ((c2 & 0x000000ff)      ) * w2) >>       s ) & 0x000000ff);
> > +}
> > +
> > +static av_always_inline uint32_t interp_3px(uint32_t c1, int w1, uint32_t c2, int w2, uint32_t c3, int w3, int s)
> > +{
> > +    return (((((c1 & 0xff000000) >> 24) * w1 + ((c2 & 0xff000000) >> 24) * w2 + ((c3 & 0xff000000) >> 24) * w3) << (24 - s)) & 0xff000000) |
> > +           (((((c1 & 0x00ff0000) >> 16) * w1 + ((c2 & 0x00ff0000) >> 16) * w2 + ((c3 & 0x00ff0000) >> 16) * w3) << (16 - s)) & 0x00ff0000) |
> > +           (((((c1 & 0x0000ff00) >>  8) * w1 + ((c2 & 0x0000ff00) >>  8) * w2 + ((c3 & 0x0000ff00) >>  8) * w3) << ( 8 - s)) & 0x0000ff00) |
> > +           (((((c1 & 0x000000ff)      ) * w1 + ((c2 & 0x000000ff)      ) * w2 + ((c3 & 0x000000ff)      ) * w3) >>       s ) & 0x000000ff);
> > +}
> 
> not sure its a good idea at this point but
> even / odd samples could be scaled together
> (((c1 & 0x00FF00FF) * w1 + (c2 & 0x00FF00FF) * w2) >> s) & 0x00FF00FF
> 

Yep right, the reference code is indeed doing something like this. I went
for the naive version at first. I'll make it faster when every hq*x will
be done and tests available. Thanks

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140610/8a2d3e8c/attachment.asc>