use 64-bit math in calculating the offsets as they may exceed 32-bits
when scaling
Bug: chromium:1196850
Change-Id: I6a484fc4dded6f6c4b82346ef145eb69c1477b3c
in Export increment the dst pointer, but in EmitRescaledRowsRGBA use
64-bit math as the number of output lines is variable and may still
overflow when incrementing.
Bug: chromium:1196850
Change-Id: I5c65b875894ee9da0fef1e24d27e507171800c4a
replace with more inclusive terms or remove the comment entirely if the
meaning was already clear.
Bug: webp:507
Change-Id: Ica3bbf751ebf79f6668df6e6209af770248ff4ca
sometimes, the last rows of the alpha plane contain more than NUM_ARGB_CACHE_ROWS
rows to process. But ExtractAlphaRows() was repeatedly calling ApplyInverseTransforms()
without updating the dec->last_row_ field, which is the starting row used as starting
point.
Fix would consist of either updating correctly dec->last_row_ before calling
ApplyInverseTransforms(). Or pass the starting row explicitly, which is simpler.
BUG=webp:439
Change-Id: Id99f2c28662d02b2b866cb79e666050be9d59e04
The standard allows for Huffman images with any coefficients.
Hence potentially big memory allocations. The previous workaround
was "trying" things out, the new one is more rigorous and
only allocates what is needed, modifying the Huffman image
to contain the minimal set of coefficients.
BUG=oss-fuzz:8623,oss-fuzz:9111,oss-fuzz:9134
Change-Id: I6a972e90e4ae509c15cb41ee22c58b775fa3f4aa
alpha processing is still required when requesting premultiplied output
since:
1b27bf8b WEBP_REDUCE_SIZE: disable all rescaler code
Change-Id: Id1b03256c4c04b8db31527e60cd31dd20ce6f3ad
The patch 21735e0 introduced a bug where a goto path was not testing
the eos_ state. If this happened just before a row_sync, a SaveState()
would be called that would store the eos_ state as '1' till the end
of the loop. This usually was not a problem, except for the very last
chunk where we disable the incremental decoding altogether (we have all
the data). The termination tests were then going wrong.
The fix is to add a proper eos_ test and avoid falling in this inconsistent
state.
(21735e06f7)
BUG=webp:332
Change-Id: Ib16773aee26bfd068fbf4e9db3d2313bd978b269
This code is ultra-critical for lossless decoding, especially on ARM.
The extra call VP8LIsEndOfStream() was causing unnecessary slow-down.
Now, we check for bitstream-end separately in the main loop.
Change-Id: I739b5d74cc29578e2b712ba99b544fd995ef0e0d
this avoids duplicates between these trees and dsp/, e.g., enc/tree.c,
dec/tree.c, making pulling the whole library source tree into one target
possible
BUG=webp:279
Change-Id: I060a614833c7c24ddd37bf641702ae6a5eef1775
