this can result in an alignment hint on arm causing a SIGBUS. casting
the input ptr to anything aside from its type is unnecessary for memcpy
and is contrary to the intent of this function.
Change-Id: I9a4d3f4be90f80cd8c3e96ccbe557e51e34cf7a5
when targeting NEON C functions with NEON equivalents won't be used, but
will contribute to binary size. the same goes for sse2, etc., but this
change is primarily concerned with binary sizes for android arm targets.
note '-noasm' or otherwise modifying VP8GetCPUInfo will have no effect
on the use of NEON functions.
this decision can be overridden by defining WEBP_DSP_OMIT_C_CODE to 0.
Change-Id: I47bd453c84a3d341ca39bc986a39eb9c785aface
* changes:
{dec,enc}_neon: harmonize function suffixes x2
upsampling_neon: harmonize function suffixes
yuv_neon: harmonize function suffixes
rescaler_neon: harmonize function suffixes
lossless_neon: harmonize function suffixes
lossless_enc_neon: harmonize function suffixes
filters_neon,cosmetics: fix indent
enc_neon: harmonize function suffixes
dec_neon: harmonize function suffixes
and all older versions.
force Sub3() to not be inlined, otherwise the code in Select() will be
incorrect.
extends the check add previously in:
637b3888 dsp/lossless: workaround gcc-4.9 bug on arm
BUG=webp:363
Change-Id: I1403b558f8660b764f3a570a3326822d5ef0be29
the incorrect bit was being extracted from the lossless bitstream header
causing the alpha flag in VP8X to be misreported. previously the
signature byte was ignored in the calculation of the offset.
since:
8ba1bf61 Stricter check for presence of alpha when writing lossless
images
BUG=webp:361
Change-Id: I7c618b5f01a37f5e4b799dee11a7949efaf88046
avoids over reading if the reported ANMF payload is < 8 bytes.
likely broken since:
81b8a741 Design change in ANMF and FRGM chunks:
Change-Id: I3e267bafea348a50545587dea8fafb2199c6b650
ssse3 is bit #9 in ecx, bit 1 is sse3. this only controls the check for
slow ssse3 and likely had no ill effect.
Change-Id: I84ce73dc480e1cdbd085e37be06f3f402116c201
It is still redefined, but to the same constant,
hence no more warning as mentioned on BUG=webp:358
Change-Id: I80a834c139d5d60cd693d468b0e2ea399729ab3e
This patch fixes the compatibility for loop-count handling.
This aims at addressing the change in Chrome handling of loop-count
prior to M63.
Before M63: loop-count interpretation was aligned to GIF's behaviour in
Chrome, but incompatible with WebP's spec. In particular, you couldn't
loop exactly once.
Post-M63: loop-count in WebP is really the total number of loops. Gif2webp
will convert correctly from a GIF source by adjusting the loop count.
Note: The Chrome version can be retrieved from the User-Agent
string (chrome://version).
An M63 version will contain the pattern:
Chrome/63.x.xxxx.xx
for instance.
Change-Id: Ie6dc13227e6498f4d7af2f09247913648997648a
