[FFmpeg-devel] [PATCH] [SOCIS] [WIP] libavfilter: add vf_hue.c
stefasab at gmail.com
Mon Aug 6 19:06:01 CEST 2012
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
More information about the ffmpeg-devel