When a color indexing transform with 16 or fewer colors is used,
WebP uses "pixel packing", i.e. storing several pixels in one byte,
which virtually reduces the width of the image (see WebPContext's
reduced_width field). This reduced_width should always be used when
reading and applying subsequent transforms.
Updated patch with added fate test.
The source image dual_transform.webp can be downloaded by cloning
https://chromium.googlesource.com/webm/libwebp-test-data/
Fixes: 9368
Signed-off-by: James Zern <jzern@google.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Neither the auxiliary VLC table nor the code_lengths array need to be
freed if creating the auxiliary VLC table fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They are always in the range 0..15, so using an int is not necessary.
Furthermore, using an int would not work if sizeof(int) != 4 as
ff_init_vlc_sparse() can only handle uint8_t, uint16_t and uint32_t
lengths.
Reviewed-by: zhilizhao(赵志立) <quinkblack@foxmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The WebP format uses Huffman tables and the decoder therefore uses
VLC tables. Given that WebP is a LE format, a LE bitreader is used;
yet the VLC table is not created for a LE reader (the process used to
create the tables puts the last bit to be read in the lowest bit) and
therefore custom code for reading the VLCs that reverses the bits
read is used instead of get_vlc2(). This commit changes this to use
a table designed for LE bitreader which allows to use get_vlc2() directly.
The necessary reversing of the codes is delegated to
ff_init_vlc_sparse() (and is therefore only done during init and not
when actually reading the VLCs).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
some bitstream have trailing junk, despite being valid webp data.
In case of apparent error, abort the loop and let *got_frame
decide whether this is an error or not.
fixes trac #8107 (/#7612)
Another possibility would be turning the loop into:
while (!*got_frame) {...}
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also adds some extra fields to the main context structure that may
be needed by a hwaccel decoder.
The current behaviour of the WebP decoder is maintained by adding an
additional field to the VP8 decoder private context to indicate that
it is actually being used as WebP (no hwaccel is supported for that
case).
Export the raw data as ICC Profile frame side data.
Reviwed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array access
Fixes: 1434/clusterfuzz-testcase-minimized-6314998085189632
Fixes: 1435/clusterfuzz-testcase-minimized-6483783723253760
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'b668662939de3a02454cfc9ba3e6d10b87527a40':
get_bits: Move BITSTREAM_READER_LE definition before all relevant #includes
The merge commit also includes changes for libavcodec/interplayacm.c and
libavcodec/truemotion2rt.c
Merged-by: Clément Bœsch <clement@stupeflix.com>
This avoids the danger that get_bits.h might get indirectly #included before
BITSTREAM_READER_LE is defined.
Also sort headers into canonical order where appropriate.
The loop always needs at least 8 bytes for chunk_type and chunk_size.
If fewer are left, bytestream2_get_le32 just returns 0 without
reading any bytes, leading to an infinite loop.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Every chunk needs at least 8 bytes for chunk_type and chunk_size.
Prevent a possible infinite loop.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
According to the WebP Lossless Bitstream Specification
"each transform is allowed to be used only once".
If a transform is more than once this can lead to memory
corruption.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the WebP Lossless Bitstream Specification
"each transform is allowed to be used only once".
If a transform is more than once this can lead to memory
corruption.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to the WebP Lossless Bitstream Specification the highest
allowed value for a prefix code is 39.
If prefix_code is too large, the calculated extra_bits has an invalid
value and triggers an assertion in get_bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the WebP Lossless Bitstream Specification the highest
allowed value for a prefix code is 39.
If prefix_code is too large, the calculated extra_bits has an invalid
value and triggers an assertion in get_bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
it should not be possible to be larger as its stored as 8bit value
but we would be overwriting a stack buffer if it is ...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
See https://code.google.com/p/webp/issues/detail?id=206
for a description of the problem/fix.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch makes the decoder follow the recommendation of the spec.
There is some disagreement (see "[FFmpeg-devel] [PATCH]: libavcodec/webp")
about what would be best to be written in the spec, so in case the spec
is changed again, this potentially would need to be amended or reverted
* commit 'c6698dfe7cdbc7634f33245875488ed3fa4a8ced':
webpdec: Fix decoding of the huffman group indices.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also remove "webp:" from log messages. Using the AVCodecContext is enough.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f51e3a1971045c7ed0c3d9d29d3254a4d940198e':
webp: do not call av_frame_free() on the user-provided frame
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The vlc reader cannot handle 0-bit huffman codes. For most
situations WebP uses the "simple" huffman coding for this case,
but that will only handle symbols up to 255. For the LZ77 distance
codes, larger symbol values are needed, so it can happen in rare
cases that a normal huffman table is used that only has a single
symbol.
