webpdecoder_static is reused to create libwebpdecoder.so and
libwebp.{a,so}
(cherry picked from commit 8697a3bcc8)
Change-Id: I940293cb755040c0ea45dc13f22624de8f355867
the standard vtbl functions are available there [1][2].
based on a patch from: aaroncrespo
fixes issue #243.
[1]
http://adcdownload.apple.com//Developer_Tools/Xcode_6.3_beta/Xcode_6.3_beta_Release_Notes.pdf
[2] Apple LLVM Compiler Version 6.1
- Xcode 6.3 updates the Apple LLVM compiler to version 6.1.0.
[...]
Support for the arm64 architecture has been significantly revised to
align with ARM's implementation, where the most visible impact is that a
few of the vector intrinsics have changed to match ARM's specifications.
(cherry picked from commit 602a00f93f)
Change-Id: I79a0016f44b9dbe36d0373f7f00a50ab3c2ca447
partially normalize indent, vertical whitespace and capitalization with
the copy used on developers.google.com/speed/webp
(cherry picked from commit e7d3df2314)
Change-Id: I8044418eeb9eaf5bd5c799675c74f6f845d503d6
this is in line with the recommendation in the spec, cf.,
5603947 webp-container-spec: clarify background clear on loop
(cherry picked from commit 1579de3cae)
Change-Id: Id3910395b05a1a1f2804be841b61f97bd4bac593
at the beginning of the loop there's an implicit clear of the entire
canvas to the background (or application defined) color. this avoids
adding the final composited frame to the first.
(cherry picked from commit 560394798f)
Change-Id: Ia3a52cf4482c6176334a5c9c99a0ddd07d1776e7
previously the first frame would be redisplayed, which might be
unexpected if the final frame was meant to be a composite, for example.
(cherry picked from commit 0f017b56f3)
Change-Id: I4da795623c71501e2fa426e8fba8fb2ffcbab58a
DitherRow() only checks this value, not 'skip_' so previously it was
uninitialized for these blocks.
(cherry picked from commit 66935fb9ee)
Change-Id: I0f698b81854ee9d91edacb51c1e3bdab9cba96f2
similar to:
1ba61b0 enable NEON intrinsics in aarch64 builds
vtbl1_u8 is available everywhere but Xcode-based iOS arm64 builds, use
vtbl1q_u8 there.
performance varies based on the input, 1-3% on encode was observed
(cherry picked from commit 416e1cea9b)
Change-Id: Ifec35b37eb856acfcf69ed7f16fa078cd40b7034
Reported here: https://code.google.com/p/webp/issues/detail?id=239
At the beginning of method 'DecodeImageData', pixels up to
'dec->last_pixel_' are assumed to be already cached. So, at the end of
previous call to that method also, that assumption should hold true.
Hence, we should cache all pixels up to 'src' regardless of 'src_last'.
This affects lossless incremental decoding only, as that is when
src_last and src_end differ.
Note: alpha decoding is implicitly incremental, as alpha decoding of
only the rows 'y_end - y_start' happens during FinishRow() call. So, this bug
affects alpha decoding in non-incremental decoding flow as well.
This bug was introduced in: https://gerrit.chromium.org/gerrit/#/c/59716.
(cherry picked from commit 783a8cda24)
Change-Id: Ide6edfeb2609b02aff701e1bd9fd776da0a16be0
add additional return checks and asserts to avoid:
C6102: Using 'XXX' from failed function call ...
(cherry picked from commit 9b228b5416)
Change-Id: I51f5fa630324e0cd7b2d9fceefecb4f4021474b1
width / height are unsigned; fixes a warning with msvs /analyze:
C6340: Mismatch on sign: 'const unsigned int' passed as _Param_(4) when
some signed type is required in call to 'fprintf'.
(cherry picked from commit 47d26be760)
Change-Id: I5f1fad4c93745baf17d70178a5e66579ccd2b155
check enc->argb_ to quiet an msvs /analyze warning:
C6387: 'enc->argb_+y*width' could be '0': this does not adhere to the
specification for the function 'memcpy'.
(cherry picked from commit f0e0677b87)
Change-Id: I87544e92ee0d3ea38942a475c30c6d552f9877b7
and only use it on x86 / x64 where it's available.
has the side-effect of quieting a msvs /analyze warning:
C6001: Using uninitialized memory 'cpu_info'.
(cherry picked from commit 0de5f33e31)
Change-Id: Iae51be3b22b2ee949cfc473eeea9fd9fb6b3c2cb
explicitly add immintrin.h instead of transitively picking it up via
windows.h presumably. makes the code easier to move around.
(cherry picked from commit b6c0428e8c)
Change-Id: If70d5143ac94fc331da763ce034358858e460e06
reported in https://code.google.com/p/webp/issues/detail?id=237
An empty partition #0 should be indicative of a bitstream error.
The previous code was correct, only an assert was triggered in debug mode.
But we might as well handle the case properly right away...
(cherry picked from commit 205c7f26af)
Change-Id: I4dc31a46191fa9e65659c9a5bf5de9605e93f2f5
allows the sources to be #include'd in some hackish builds (don't do
that!)
(cherry picked from commit 67f601cd46)
Conflicts:
src/dsp/alpha_processing.c
src/dsp/argb.c
src/dsp/dec.c
src/dsp/enc.c
src/dsp/lossless.c
src/dsp/upsampling.c
src/dsp/yuv.c
Change-Id: I0c7a43acbebd0e2d5068845e6daa8ce47361cd91
can be useful, not sure they are a subset of the flags we
use already...
(cherry picked from commit 80d950d94e)
Change-Id: Iec742a99427a791d9527368302a1136df2ff96cd
we compare the current VP8GetCPUInfo pointer to the last used.
This is less code overall and each implementation is still
testable separately (by just changing VP8GetCPUInfo, but not
a separate threads!)
(cherry picked from commit a437694a17)
Conflicts:
src/dsp/alpha_processing.c
src/dsp/argb.c
src/dsp/dec.c
src/dsp/enc.c
src/dsp/lossless.c
src/dsp/upsampling.c
src/dsp/yuv.c
Change-Id: Ia13fa8ffc4561a884508f6ab71ed0d1b9f1ce59b
check for __apple_build_version__ to distinguish the two; a version
check could work as Apple bumped Xcode's to 5.x/6.x, but it's unclear
how upstream will deal with their versioning as they go 3.6+, so avoid
it for now.
(cherry picked from commit a3946b8956)
Change-Id: I67cda67c4f68e262a92d805a63cc1496374be063
This wasn't working for this specific scenario:
- Encode an RGBA 'pic' (with trivial alpha) using lossy encoding.
(so that pic->a == NULL after import happens).
- Modify the 'pic->argb' so that it has non-trivial alpha.
- Encode the same 'pic' again.
This used to fail to encode alpha data as pic->a == NULL.
(cherry picked from commit e4f4dddba3)
Change-Id: Ieaaa7bd09825c42f54fbd99e6781d98f0b19cc0c
at least clang 3.[45] in c++ mode with -std=c++11 define __STRICT_ANSI__
this change set WEBP_INLINE to inline for c++/non-strict-ansi/> c99
fixes crbug.com/428383
(cherry picked from commit 6638710b9e)
Change-Id: Ief2b934353c336a75865c73c90cc3dc5e4f83913
This is much faster and the compression is slightly better too.
(cherry picked from commit c94ed49efd)
Change-Id: Ibf0d10eea83bfabfcc44ee497074767462ff41b1
Snapping odd offsets in GIF to even offsets in WebP was causing extra row/column
being disposed in such cases.
Code is rewritten to maintain previous and current canvas (it used to maintain
previous canvas and current frame earlier). And we recompute change rectangles
as those from GIF may no longer apply.
Also, this renders methods like ReduceTransparency() and ConvertToKeyFrame()
redundant, as internally maintained current canvas is always independent of
previous canvases.
Disposal method choice: we pick the disposal method that results in the smallest
change rectangle.
(cherry picked from commit e4c829efe9)
Conflicts:
examples/gif2webp_util.c
Change-Id: Ic31186d98fe1a2a790a89d1571b17e3abd127e79
avoids an ICE with NDK r10b + NDK_TOOLCHAIN_VERSION=4.9
In function 'SSE16x16':
enc_mips32.c (684) internal compiler error: Segmentation fault
Change-Id: I1a3d33c0a9534c97633ab93bcdf9bf59d3a7e473
(cherry picked from commit 0ce27e715e)
the number of segments are previously validated, but an explicit check
is needed to avoid a warning under gcc-4.9
(cherry picked from commit c8a87bb62d)
Change-Id: Ifa7c0dd7f3f075b3860fa8ec176d2c98ff54fcea
iOS 5 support isn't available in the Xcode 6 install; iOS 6 covers
phones starting at the 3GS, so should be a reasonable base line
(cherry picked from commit 9f7d9e6dda)
Change-Id: Ie5603c9e30cb52114b372509e183febbf679a69a
