this function produces different results from the C code due to
use of double/float resulting in output differences when compared to
-noasm.
Bug: webp:499
Change-Id: Ia039b168c0a66da723fb434656657ba1948db8ae
Some PNG input contain chunks larger than libpng's default
memory-alloc limit (8M).
Raise this limit reasonably if it looks like the input bitstream
is larger than libpng's default limit.
BUG=webp:497
Change-Id: I2c9fbed727424042444b82cbf15e0781cefb38dc
(cherry picked from commit 8696147da4)
add IOS_MIN_VERSION, MACOSX_MIN_VERSION and MACOSX_CATALYST_MIN_VERSION
to allow control of the minimum versions supported based on the
deployment target; based on feedback from:
e8e8db98 add xcframeworkbuild.sh
e8e8db985a
Change-Id: I9fbca072bf00c4cb8e59143371a2d3522d22808b
somewhat arbitrary version selection, but this matches what's currently
in use in ExoPlayer in the dev-v2 branch
fixes:
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine java version from '11.0.9.1'.
and removes the wrapper task as this is predefined in later versions:
Build file '/home/jzern/external/libwebp/build.gradle' line: 437
* What went wrong:
A problem occurred evaluating root project 'libwebp'.
> Cannot add task 'wrapper' as a task with that name already exists.
Change-Id: Ib9ef757d874cd6d4b08da3e7cef3ac5316935966
It's explicitly safe (and recommended!) to plug external data into
the pic->y/u/v/argb fields. They are guaranteed to be preserved
by the encoding process if no conversion is needed.
Change-Id: I325ca41a6a834f7f028431c605dddef67e9542cc
this is similar to iosbuild.sh, but will create .xcframework variants to
support Catalyst targets. currently it includes libs for:
ios-arm64_armv7_armv7s
ios-arm64_x86_64-maccatalyst
ios-i386_x86_64-simulator
macos-arm64_x86_64
this script requires Xcode 12+ to target arm64 for mac/catalyst, Xcode
11 builds will create x86_64 libraries only. iosbuild.sh remains for
compatibility purposes
Change-Id: I289c54c4b85848392a99bea698d45d54a9781f49
Since
a376e7b9 Fix compilation on windows and clang-cl+ninja.
the highest level assembly flag (/arch:AVX / -msse4.1) would be applied
to all assembly files. This could result in higher level instructions
being used which would defeat the runtime cpu detection check and could
result in a crash.
With this change -m style flags are used with clang-cl as it supports
them and allows the correct level to be set. With at least Visual
Studio 12 (2013)+ /arch is not necessary to build SSE2 or SSE4 code
unless a lesser /arch is forced so these flags are avoided. This matches
the nmake build.
For emscripten only sse2 and sse4.1 are tested (NEON will succeed in
being enabled, but fail to build). This is consistent with
the current behavior added in:
commit 36c81ff6a9
WASM-SIMD: port 2 patches from rreverser@'s tree
* Stop on first found SIMD version
* Imply lower SSE version when higher is found
Bug: webp:488
Change-Id: I34d01274e5204a477b6b9f35ed566048a62b4c57
Tested: msvc 2013-2019 debug win32/x64 builds; clang-cl under 2019
Add a stub file to object only library targets.
https://cmake.org/cmake/help/v3.18/command/add_library.html#object-libraries
Some native build systems (such as Xcode) may not like targets that have
only object files, so consider adding at least one real source file to
any target that references $<TARGET_OBJECTS:objlib>.
Bug: webp:477
Change-Id: I5d404c921d84433c7a0b22e0736ab0dbe699d264
- Add `-msimd128` to flags to actually enable WebAssembly SIMD
when performing SIMD detection. It's currently required in
addition to `-msse*` / `-mfpu=neon` flags which only perform
translation of corresponding intrinsics to Wasm SIMD ones.
See a discussion at emscripten-core/emscripten#12714 for
automating this and making easier in the future.
- Remove compilation branch that prevented definitions of
`WEBP_USE_SSE` and `WEBP_USE_NEON` on Emscripten even when
SIMD support was detected at compile-time.
- Add an implementation of `VP8GetCPUInfo` for Emscripten which
uses static `WEBP_USE_*` flags to determine if a corresponding
SIMD instruction is supported. This is because Wasm doesn't
have proper feature detection (yet) and requires making separate
build for SIMD version anyway.
Change-Id: I77592081b91fd0e4cbc9242f5600ce905184f506
The offset *can* be negative, but the sanitizer reports strange
address behaviour when row_offset is unsigned size_t.
For safety, use int64_t instead (probably overkill. int32_t is probably ok).
Change-Id: I1bd424bfdb5447b3839f40679581d6bdea075320
After ParseAnimationFrame() calls StoreFrame(), check if StoreFrame() reads
more than anmf_payload_size bytes from dmux->mem_. Treat that as PARSE_ERROR.
Change-Id: I0d03885c19d32792af78de7bed1a944ca01f1dc6
with functions that can legitimately fail when under memory pressure the
fuzzer should exit gracefully rather than abort().
+ add some more error detail to output
Bug: chromium:1140448
Change-Id: I1a8582a939e0a5b2b8631c95c0464658c99063e2
this was only used in debug builds, the build should be fast enough in
either case.
https://docs.microsoft.com/en-us/cpp/build/reference/gm-enable-minimal-rebuild?view=vs-2019
/Gm is deprecated. It may not trigger a build for certain kinds of
header file changes. You may safely remove this option from your
projects. To improve build times, we recommend you use precompiled
headers and incremental and parallel build options instead.
Change-Id: I8e3c0e7cc82e10bd1d2b0904d290fe4e050ebe8b
with WebPReplaceTransparentPixels() function signature:
src\enc\picture_tools_enc.c(86): warning C4028: formal parameter 1
different from declaration
Change-Id: I0140d61b0dfebcbb4189707e8f2f4b1af802a4d7
this provides stronger synchronization when pthreads are available as
was done in 'd77bf512 add WEBP_DSP_INIT / WEBP_DSP_INIT_FUNC' for the
other init functions.
Change-Id: I2ffe4e24454d276c2411ece34dca38d23d4756d5
