In all HEVCLocalContext instances except the first one, the bitreader is
never used for actually reading bits, but merely for passing the buffer
to ff_init_cabac_decoder(), which is better done directly.
The instance that actually is used for bitreading gets moved to stack in
decode_nal_unit(), which makes its lifetime clearer.
Do it in hls_slice_header() rather than cabac_init_decoder() - the
former is a more logical place as according the spec the byte alignment
is a part of the slice header, not slice data. Avoids a second instance
of alignment handling in vaapi_hevc.
Also, check that alignment_bit_equal_to_one is, in fact, equal to one.
USAC supports up to 64 audio channels, but puts no limit on the total
number of extensions that may be present. Which may mean that there's
a single audio channel, with 65 thousand extension elements.
We assume that 64 elements is the maximum for now. So check the value.
Some calls to get_escaped_value() specify 0 bits as the third value.
This would result in get_bits(0), which is not a correct usage of the
get_bits API.
Codec IDs have split from `avcodec.h` into `codec_id.h` after commit
c6978418b8.
General documentation contents (which are now in
`general_contents.texi`) have split from the header in `general.texi`
after commit 6accb7718a.
Update the developer documentation to match these changes.
Signed-off-by: Marcus B Spencer <marcus@marcusspencer.xyz>
Fixes "libavcodec/aac/aacdec_usac.c(543): error C2440: 'type cast': cannot convert from 'GetBitContext' to 'GetBitContext'"
from msvc.
Signed-off-by: James Almer <jamrial@gmail.com>
If its not replaced we would have a negative index used in an array potentially
Helps: CID1440385 Negative array index read
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It seems nothing prevents such overflow even though odd
Fixes: CID1441934 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This might not be needed for correctness but it could
help general reproducability of issues
Related to: CID1560037 Uninitialized scalar variable
Related to: CID1560044 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found while reviewing: CID1500309 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This issue cannot happen with the current function parameters
Fixes: CID1500309 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit adds a decoder for the frequency-domain part of USAC.
What works:
- Mono
- Stereo (no prediction)
- Stereo (mid/side coding)
- Stereo (complex prediction)
What's left:
- SBR
- Speech coding
Known issues:
- Desync with certain sequences
- Preroll crossover missing (shouldn't matter, bitrate adaptation only)
AAC uses an unconventional system to send scalefactors
(the volume+quantization value for each band).
Each window is split into either 1 or 8 blocks (long vs short),
and transformed separately from one another, with the coefficients
for each being also completely independent. The scalefactors
slightly increase from 64 (long) to 128 (short) to accomodate
better per-block-per-band volume for each window.
To reduce overhead, the codec signals scalefactor sizes in an obtuse way,
where each group's scalefactor types are sent via a variable length decoding,
with a range.
But our decoder was written in a way where those ranges were carried through
the entire decoder, and to actually read them you had to use the range.
Instead of having a dedicated array with a range for each scalefactor,
just let the decoder directly index each scalefactor.
This also switches the form of quantized scalefactors to the format
the spec uses, where for intensity stereo and regular, scalefactors
are stored in a scalefactor - 100 form, rather than as-is.
USAC gets rid of the complex scalefactor handling. This commit permits
for code sharing between both.
The 8x8 pixel arrays are not necessarily aligned to 64 bits, so the
current code leads to Bus error on real hardware. This reproducible
with FATE's vc1_ilaced_twomv test case.
The new "pessimist" code can trivially be shared for 16x16 pixel
arrays so we also do that. FWIW, this also nominally reduces the
hardware requirement from Zve64x to Zve32x.
T-Head C908:
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 14.7
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 3.5
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 3.7
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i32: 1.5
SpacemiT X60:
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 13.0
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 3.0
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 3.2
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i32: 1.2
Anton Khirnov
James Almer
Lynne
Rémi Denis-Courmont
Andreas Rheinhardt
Tomas Härdin
Stefano Sabatini
Marcus B Spencer
Michael Niedermayer