note that config.exact defaults to 0 and point users to WebPEncode() if
the default isn't acceptable.
BUG=webp:424
Change-Id: I179c34649834aeadc1606d0856f33e8255048ea1
This is to prevent resizing to dimension 0
+ added some safety checks about src_width > 0 and src_height > 0
BUG=webp:418
Change-Id: Ic04a53ad26455d80538bc8681882a554fca2a340
Taking the comments from the internal ParseHeadersInternal.
(which is called by GetFeatures).
BUG=webp:411
Change-Id: I9999b4a183805e2db1456610a30024a0d8be4d00
It's safer to clip the passed param instead of doing 32b arithmetic
and clipping afterward.
Output is unchanged, but code no longer rely on UB.
Change-Id: Ia5b4de6e8863981753f1d17f062965a6a5da5bed
dst->cur_ was not set.
The bug occurred only with several VP8LBitWriter instances
(thread_level > 0) and in 32-bit (in 64-bit, src->cur_ was
always 0 in VP8LBitWriterClone()).
BUG=chromium:917029
Change-Id: I0d94a3d8e62b247fd616eebe1009868dc8a5ed2e
Move IsFlat to its own header. This allows it to continue to be
inlined. Using the RTCD and creating a distinct function slows down arm
builds.
flower mug
C 3.59 2.12
NEON 3.47 2.01
BUG=b/118740850
Change-Id: Id77e8f76d9e9790c498806e7070bbe37c10bc2e9
thresh is defined by FLATNESS_LIMIT_* which ranges from 2-10.
score_t is int64 which is a touch overkill.
Change-Id: I308bd440bf11643665d3642fe361495a257b6e52
Direct copy of sse2. Slight improvement because neon has
abs().
flower.ppm had minimal improvement. Somewhat expected because
GetResidualCost_C is only ~3.6%
mug.ppm had a better improvement because GetResidualCost_C is
almost 9%.
C 2.150
NEON 2.130
BUG=b/118740850
Change-Id: Ibc0dd97a81596635f5599cf568205974b4fd2597
Much faster with aarch64. Still somewhat faster without vmaxv.
C: 3.700s
ArmV7: 3.675
aarch64: 3.600
BUG=b/118740850
Change-Id: I3be852da89633eca4bddce443c87f5e4a2f55868
The old code simply did not make sense.
The effect is that the pair would be popped from the
queue no matter what; as the queue is small, it does
not matter that much on the results.
But it will matter for a later CL.
Change-Id: If50c9fa9d7f3ac3c48bb7336d81479287d4944c4
(cherry picked from commit 485ff86fbb)
The old code simply did not make sense.
The effect is that the pair would be popped from the
queue no matter what; as the queue is small, it does
not matter that much on the results.
But it will matter for a later CL.
Change-Id: If50c9fa9d7f3ac3c48bb7336d81479287d4944c4
Also, histograms in a HistogramSet can be initialized all
at once.
Change-Id: Ibbfa6034dce58dca8bb9113487e2ae507222ce7d
(cherry picked from commit 6752904b2f)
When histograms are empty, it is easy to add them.
They should also not be considered when merging histograms
(it is a waste of CPU).
This does not change the compression performance,
just the speed.
Change-Id: I42c721ca0f9c5ea067e73b792aa3db6d5e71d01f
(cherry picked from commit decf6f6b87)
When histograms are empty, it is easy to add them.
They should also not be considered when merging histograms
(it is a waste of CPU).
This does not change the compression performance,
just the speed.
Change-Id: I42c721ca0f9c5ea067e73b792aa3db6d5e71d01f
We should be using 'floor' when doing the final divide.
-> new MACRO is MULT_FIX_FLOOR()
XXX*** Mips code is DISABLED for now ***XXX
I'll update and re-enable it in a later
patch, since this code needs some refactoring first.
BUG=oss-fuzz:9179
Change-Id: Ic0693cdca4e71f5beab1029475e35c4d06b12d13
* Assert chunklist
* fix potential memory leak and
* fix null pointer access
There should not be several alpha_ or img_ chunks in SynthesizeBitstream. Use ChunkListDelete in MuxImageRelease to be safe.
A null pointer accessed in WebPMuxPushFrame triggered a harmless runtime error.
Change-Id: I3027f8752093652bd41f55e667d041c0de77ab6e
The chunk list only has two operations: append and set
to one element. The two operations are split and the append
one is sped up by storing the last element.
Corrupted data could make a very long list to search through.
BUG=oss-fuzz:9190
Change-Id: I1aa813ca629df29efaa3b46dbd4c4c42dbeaa34c
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
