There's no need for this in libsharpyuv currently. This avoids an ABI
bump and library size increase.
Change-Id: I3e4c79052fdb4d628a2d36491547233dd0b6dc34
Basic version for 8 bit only and C only (no simd).
Hidden behind a compile flag because the precompiled table is
fairly large (114kiB) and more than triples the size of the library.
Change-Id: I165c78e863df6a17b32f578bdbffe3adda9ac1d0
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
