theora_init_huffman_tables() does essentially the same as
ff_init_vlcs_from_lengths().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Expressions like array[get_vlc2()] can be optimized by using a symbols
table if the array is always the same for a given VLC. This requirement
is fulfilled for the VLC used for VP3 motion vectors. The reason it
hasn't been done before is probably that the array in this case
contained entries in the range -31..31; but this is no problem with
ff_init_vlc_from_lengths(): Just apply an offset of 31 to the symbols
before storing them in the table used to initialize VP3 motion vectors
and apply an offset of -31 when initializing the actual VLC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is possible by switching to ff_init_vlc_from_lengths() because it
allows to replace codes of type uint16_t by symbols of type uint8_t; in
some cases (like here) it also allows to replace explicitly coded
codes by implicitly coded symbols.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
By switching to ff_init_vlc_from_lengths() one can apply both positive
as well as negative offsets for free; in this case it even saves space
because one replaces codes tables that don't fit into an uint8_t by
symbols tables that fit into an uint8_t or can even be completely
avoided as they are trivial.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Theora allows to use custom Huffman tables which are coded in the
bitstream as a tree: Whether the next node is a leaf or not is coded
in a bit; each node itself contains a five bit token. Each tree can
contain at most 32 leafs; typically they contain exactly 32 with the 32
symbols forming a permutation of 0..31. Yet the standard does not impose
either of these requirements. It explicitly allows less than 32 leafs
and multiple codes with the same token.
But our decoder used an algorithm that required the codes->token mapping
to be injective and that also presumed that there be at least two leafs:
Instead of using an array for codes, tokens and code lengths, the
decoder only had arrays for codes and code lengths. The code and length
for a given token were stored in entry[token]. As no symbols table was
used when initializing the VLC, the default one applied and therefore
the entry[token] got the symbol token (if the length of said entry is >0).
Yet if multiple codes had the same token, the codes and lengths from the
later token would overwrite the earlier codes and lengths.
Furthermore, less than 32 leafs could also lead to problems: Namely if
this was not the first time Huffman tables have been parsed in which
case the array is not zeroed initially so that old entries could make
the new table invalid.
libtheora seems to always use 32 leafs and no duplicate tokens; I am not
aware of any existing valid files that do not.
This is fixed by using a codes, symbols and lengths array when
initializing the VLC. In order to reduce the amount of stuff kept in the
context only the symbols and lengths (which both fit into an uint8_t)
are kept in the context; the codes are derived from the lengths
immediately before creating the tables.
There is now only one thing left which is not spec-compliant: Trees with
only one node (which has length zero) are not supported by
ff_init_vlc_sparse() yet.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there was no cleanup in case initializing the Theora VLC
tables failed, leading to memleaks. This commit gets rid of them by
setting the FF_CODEC_CAP_INIT_CLEANUP flag for all decoders in vp3.c;
this also allows to remove some (now redundant) cleanup code.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to follow, so it is abandoned. Instead, the
same init function is used to init each per-thread context. Where
necessary, AVCodecInternal.is_copy can be used to differentiate between
the first thread and the other ones (e.g. for decoding the extradata
just once).
throughout vp3_decode_frame the error code was being captured (ret) but never returned.
Signed-off-by: Peter Ross <pross@xvid.org>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
VP4 applies a loop filter during motion compensation, causing the block offset
will often by unaligned. This produces a bus error on some platforms, namely
ARMv7 NEON.
This patch adds a unaligned version of the loop filter function pointer
to VP3DSPContext.
Reported-by: Mike Melanson <mike@multimedia.cx>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Theora is forced to be non zero if it is zero and a sample
is asked for, as suggested by reimar
Fixes: Timeout (2min -> 600ms)
Fixes: 15366/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5737849938247680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This merges commit 1202b71269 from libav,
originally written by Anton Khirnov and skipped in
fc63d5ceb3.
libavcodec/vp3.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
Michael Niedermayer