Initially added to workaround gcc implementation issues that clang
does not have. (gcc hardcodes rbx as the PIC register, clang uses a
virtual register)
Change-Id: I1a3277abf02b1ff437b4aea4d28f4cb1c0176b80
This syncs the document with the draft RFC.
block_xsize -> transform_width
i -> distance_code
x/ysize -> image_width/height
Change-Id: Ief442c90157e82c518e8cb175a522c519b16ac69
Provides the missing symbols in WebP.framework & WebP.xcframework:
Undefined symbols for architecture arm64:
"_SharpYuvConvert", referenced from:
_ImportYUVAFromRGBA in libwebp.a(libwebpencode_la-picture_csp_enc.o)
"_SharpYuvGetConversionMatrix", referenced from:
_ImportYUVAFromRGBA in libwebp.a(libwebpencode_la-picture_csp_enc.o)
"_SharpYuvInit", referenced from:
_ImportYUVAFromRGBA in libwebp.a(libwebpencode_la-picture_csp_enc.o)
This was missed in:
c3d0c2d7 fix ios build scripts after sharpyuv dep added
Bug: webp:623
Change-Id: I1c4582ec2cee801b52867674d553900d6028bea8
Fixed: webp:623
in the 'Canvas Assembly from Frames' section. This matches the format in
the RFC draft; assert was not defined
Change-Id: Ib943b42f75fd1b4c281848f14e0626df9c868f59
When WebPSafeMalloc fails on VP8LHuffmanTablesAllocate,
next is not initialized to NULL.
VP8LHuffmanTablesDeallocate uses next to know the following nodes.
A patch fixes this issue.
Change-Id: I144ae84cd97e5bca227018ef1afa95361267902c
The first condition is only necessary if we have not read enough
(enough being defined by src_last, not src_end which is the end
of the image).
The second condition now fits the comment below: "if not
incremental, and we are past the end of buffer".
BUG=oss-fuzz:62136
Change-Id: I0700f67c62db8e1c02c2e429a069a71e606a5e4f
First, BuildHuffmanTable is called to check if the data is valid.
If it is and the table is not big enough, more memory is allocated.
This will make sure that valid (but unoptimized because of unbalanced
codes) streams are still decodable.
Bug: chromium:1479274
Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
(cherry picked from commit 902bc91903)
First, BuildHuffmanTable is called to check if the data is valid.
If it is and the table is not big enough, more memory is allocated.
This will make sure that valid (but unoptimized because of unbalanced
codes) streams are still decodable.
Bug: chromium:1479274
Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
According to https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/how-to-use-inline-assembly-language-in-c-code.html
For the C language, the asm keyword is a GNU extension. When
writing C code that can be compiled with -ansi and the -std options
that select C dialects without GNU extensions, use __asm__ instead
of asm (see Alternate Keywords). For the C++ language, asm is a
standard keyword, but __asm__ can be used for code compiled with
-fno-asm.
Change-Id: I4af950e67c857c890290c1e3d9cc886da0748784
place the unknown 'XYZW' chunk at the end of the file to agree with the
order given by the 'Extended File Format' section.
Change-Id: I5cec5a61069a03f3487f5f9ff9209f5ead6de24c
This makes it easier to read and copy/paste, though this is just rough
pseudo-code. It also matches the formatting of the advanced decoder
example.
Change-Id: I6a4d0a04a12bfc1f1956ac965ff4869cefc4f3df
4 bits are read ([0, 15]) with 4 added to the result. The check that the
result is not > NUM_CODE_LENGTH_CODES (19) is redundant. This makes the
check an assert for documentation purposes.
webp-lossless-bitstream-spec.txt is updated accordingly.
Bug: webp:611
Change-Id: Ie461017dc9de3da4cfe6856543d3dcf58f53a180
In Section 6.2 Details, use uppercase after a :. This is more consistent
with the rest of the doc.
Bug: webp:611
Change-Id: I7ac862c90fd8e5fe0bad0dd5e3515d3095a6dc9a
in ordered list in "6.2. Details". This is more consistent with the rest
of the document.
Bug: webp:611
Change-Id: Ie467c771afd5813a30855b24c80cf92673a5281c
