"Ronald S. Bultje" <[email protected]> writes:

> Hi,
>
> 2011/5/13 Måns Rullgård <[email protected]>:
>> "Ronald S. Bultje" <[email protected]> writes:
>>
>>> ---
>>>  libswscale/swscale.c |   36 +++++++++++++++++++-----------------
>>>  1 files changed, 19 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/libswscale/swscale.c b/libswscale/swscale.c
>>> index b63a386..8131927 100644
>>> --- a/libswscale/swscale.c
>>> +++ b/libswscale/swscale.c
>>> @@ -209,6 +209,7 @@ DECLARE_ALIGNED(8, const uint8_t, 
>>> dither_8x8_220)[8][8]={
>>>  };
>>>  #endif
>>>
>>> +#define POW2CLIP(x,max) (((x) & ~max) ? (-(x))>>31 & max : (x))
>>
>> There is already at least one macro similar to this somewhere.
>> Consolidating them in libavutil would probably be a good idea.
>> Don't let this hold up the patch, on which I don't have an opinion,
>> though.
>
> Yeah I copied it verbatim from vp8.c. I can give it a sweet av_ prefix
> and dump it in libavutil/common.h in a subsequent patch, or maybe even
> in this one.

I'd prefer if argument were the number of bits to saturate at.  It could
also be used in few places in ac3dsp.c.

Here's a patch I had sitting around for the unsigned version:

diff --git a/libavutil/common.h b/libavutil/common.h
index 5814297..b694e63 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -169,6 +169,12 @@ static av_always_inline av_const int32_t 
av_clipl_int32_c(int64_t a)
     else                                         return a;
 }
 
+static av_always_inline av_const unsigned av_clip_uintp2_c(int a, int p)
+{
+    if (a & ~((1<<p) - 1)) return -a >> 31 & ((1<<p) - 1);
+    else                   return  a;
+}
+
 /**
  * Clip a float value into the amin-amax range.
  * @param a value to clip
@@ -362,6 +368,9 @@ static av_always_inline av_const int av_popcount_c(uint32_t 
x)
 #ifndef av_clipl_int32
 #   define av_clipl_int32   av_clipl_int32_c
 #endif
+#ifndef av_clip_uintp2
+#   define av_clip_uintp2   av_clip_uintp2_c
+#endif
 #ifndef av_clipf
 #   define av_clipf         av_clipf_c
 #endif


-- 
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to