It simplifies freeing them and reduces the amount of allocations.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Follow the same pattern as the previous commits for H.264 and H.265.
Reviewed-By: Jan Ekström <jeebjp@gmail.com>
Tested-By: Xu, Yefeng <yefengx.xu@intel.com>
The properties should always be set; only the presence flags want to be
conditional.
Fixes#8959.
Reviewed-By: Jan Ekström <jeebjp@gmail.com>
Tested-By: Xu, Yefeng <yefengx.xu@intel.com>
Fixes: shift exponent 95 is too large for 32-bit type 'int'
Fixes: 26590/clusterfuzz-testcase-minimized-ffmpeg_dem_SMACKER_fuzzer-5120609937522688
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Canopus Lossless decoder uses several VLCs and if initializing the
ith VLC fails, all the VLCs 0..i have been freed; the ith VLC's table is
initialized to NULL for this purpose. Yet it is totally unnecessary to
free the ith VLC table at all: ff_init_vlc_sparse() cleans up after
itself on error and if an error happens before ff_init_vlc_sparse(),
the ith VLC hasn't been touched yet and doesn't need freeing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It's only used in the codec2 demuxers, and can be simplified with an AV_RB16()
call instead.
Suggested-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Partially implements setup_past_independence() and load_previous().
These ensures they are always set, even if the values were not coded
in the input bitstream and will not be coded in the output bitstream.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Partially implements setup_past_independence() and load_previous().
These ensures they are always set, even if the values were not coded
in the input bitstream and will not be coded in the output bitstream.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
This function is so extremely simple that it is preferable to make it
inline rather than deal with all the complications arising from it being
an exported symbol.
Keep avpriv_align_put_bits() around until the next major bump to
preserve ABI compatibility.
Allocating one temporary entry more than needed was made necessary by
the COPY loop below writing an element before having checked that it
should be written at all. But given that this behaviour changed, the
need for overallocating is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
fix ticket: 8932
For poc 2, we have tile boundary at x = 640.
When we predict cu(640,912),the top left pixel is not avaliable to the cu.
So, we can not check it's intra or not. We need set top[-1] = top[0] directly.
see 8.4.4.2.1 for details
Signed-off-by: Xu Guangxin <oddstone@gmail.com>
Signed-off-by: Linjie Fu <linjie.justin.fu@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>
If a static VLC table gets initialized a second time (or concurrently by
two threads) and if said VLC table uses symbols that have the sign bit
of VLC_TYPE (a typedef for int16_t) set, initializing the VLC fails. The
reason is that the type of the symbol in the temporary array is an
uint16_t and so comparing it to the symbol read from the VLC table will
fail, because only the lower 16bits coincide. Said failure triggers an
assert.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The longest code of any of the VLC tables used is eight bits long, so
using nine bits long VLC tables is wasteful. Furthermore, there are only
seven VLC tables used, yet the code up until now made it look like there
should be eight. This has been corrected, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -9223372036854775807 - 48000 cannot be represented in type 'long long'
Fixes: 26521/clusterfuzz-testcase-minimized-ffmpeg_dem_DIRAC_fuzzer-5635536506847232
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Even though the length of these codes is > 8, only the lowest seven bits
are ever set (because the long codes are on the left of the tree), so
one can use an uint8_t for them, saving space.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The longest motion vector VLC for mobiclip is six bits long, so using
eight bits for the VLC table is wasteful. Furthermore, the length can be
inlined.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
For both RealVideo 3.0 as well as RealVideo 4.0 the VLC table to use
depends upon the slice's quantization parameter; these are coded on five
bits in the bitstream and are therefore in the range of 0..31; yet the
last element here is not valid and therefore the quantizer is clipped to
the range 0..30 to get the index. But this is unnecessary: One can just
add one element more to the relevant array to avoid the clipping.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
