[FFmpeg-devel] [PATCH] [SOCIS] [WIP] libavfilter: add vf_hue.c

[Stefano Sabatini]

On date Monday 2012-08-06 17:33:54 +0200, Nicolas George encoded:
> Le decadi 20 thermidor, an CCXX, Stefano Sabatini a écrit :
> > > +            if (new_u & 768)
> > > +                new_u = (-new_u) >> 31;
> > > +            if (new_v & 768)
> > > +                new_v = (-new_v) >> 31;
> > I'm not sure about this: these should handle overflow (right now you
> > have 16 bits values which need to be expressed in the 8-bits range).
> > 
> > Indeed what this seems to do is to convert the overflowing values to
> > 0, but maybe I'm wrong.
> 
> As far as I understand it:
> 
> If new_u is between 256 and 1023 or between -1 and -768, new_u & 768 is not
> 0, so this is a cheap test for overflows in both directions, as long as the
> overflow is not too large.
> 

> And then, because of the sign extensions:
> 
> new_u = 256 + 42 -> (-new_u) >> 31 = (int)0xFFFFFFFF;
> new_u =   0 - 42 -> (-new_u) >> 31 = (int)0;
> 
> It relies on two's complement arithmetic, as, quoting the C standard:
> 
> # [ E1 >> E2 ] If E1 has a signed type and a negative value, the resulting
> # value is implementation-defined.

So the question is: should we rely on this behavior?

The plain C variant would be:
            if (new_x & 0x300)
                new_x = av_clip_uint8(new_x);

Thanks for the explanation.
-- 
FFmpeg = Faithful & Free Meaningless Prodigious Easy Genius