On 09/16/2013 04:04 AM, Kostya Shishkov wrote:
On Sun, Sep 15, 2013 at 07:24:24PM -0400, Justin Ruggles wrote:
---
I just squashed the two patches together for easier review. Aneesh is
included in the Copyright header and as one of the @author for his
contributions.
Changelog | 1 +
configure | 1 +
doc/general.texi | 2 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h | 1 +
libavcodec/codec_desc.c | 8 +
libavcodec/mathops.h | 9 +
libavcodec/version.h | 2 +-
libavcodec/vp8.c | 18 +-
libavcodec/vp8.h | 7 +
libavcodec/webp.c | 1327 +++++++++++++++++++++++++++++++++++++++++++++++
libavformat/img2.c | 1 +
13 files changed, 1369 insertions(+), 10 deletions(-)
create mode 100644 libavcodec/webp.c
[...]
+static av_always_inline uint8_t clamp_add_subtract_half(int a, int b, int c)
+{
+ int d = a + b >> 1;
+ return av_clip_uint8(d + (d - c) / 2);
+}
nit: d + ((d - c) >> 1) for consistency?
Using shift there gives incorrect results. (d - c) can be negative.
+static av_always_inline uint8_t color_transform_delta(uint8_t color_pred,
+ uint8_t color)
+{
+ return ff_u8_to_s8(color_pred) * ff_u8_to_s8(color) >> 5;
+}
I'm not sure about range expansion here
(i.e. (int)ff_u8_to_s8() * ff_u8_to_s8() >> 5)
Works ok with gcc, but yeah from what I can tell it's
implementation-defined behavior if the result of the multiplication
doesn't fit in int8_t. So I'll add the cast.
-Justin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
