Layers 1 and 2 use lengths in bits which are not a multiple of 8,
and our CRC works on a per-byte basis.
Based on b48397e7b8
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit b48397e7b84864f2d4c70361a4c4bed93e826753.
The change did not disable crc checks for layer 1 & 2, it removed reading
the CRC field.
Fixes decoding some mp2 samples and FATE test failures.
Signed-off-by: James Almer <jamrial@gmail.com>
If a bit is reserved, it matters very much what value it has, because
otherwise a decoder conforming to a future version of the standard might
interpret the output file in an unintended manner. This implies that
one must not use skip_put_bits() for it (which does not give any
guarantees wrt what ends up in the output (in case of a little-endian
bitstream writer (as here) it writes a 0 bit)); given that the reference
encoder as well as the earlier code write a zero bit at this place, the
new code does, too.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
flush_put_bits() already fills the bitstream with zeroes, so it is
unnecessary to align the bitstream before.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Dimensions are normally specified as width x height, and this will match
the same option to libaom-av1.
Remove the indirection through the private context at the same time.
The tile_rows/cols options currently do a confusingly different thing to
the options of the same name on other encoders like libvpx and libaom.
There is no backward-compatibility reason to implement the log2 behaviour
as there was for libaom, so just get rid of them entirely.
This change makes it possible for child encoders to define custom level
option names which can be used for setting the AVCodecContext->level.
Based on 337fe4bcc2
Reviewed-by: jkqxz
Signed-off-by: James Almer <jamrial@gmail.com>
This patch makes the pgx decoder select the correct
byte order instead of selecting big endian format for
16 bit images.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
'li.s' is a synthesized instruction, it does not work properly
when compiled with clang on mips, and A segfault occurred.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Failed fate case: fate-h264-conformance-caba2_sony_e
Clang is more strict in the use of register constraint.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Clang report following error in aacsbr_mips.c,ac3dsp_mips.c and aacdec_mips.c:
"couldn't allocate output register for constraint 'r'"
Use 'f' constraint for float variable.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This option is directly copy-pasted from the SVT1-HEVC wrapper and has
no place in the options for an AV1 encoder.
AV1 has no H.264/5 IDR frames nor anything like them.
All this option does is change all real keyframes to an intra-only
AV1 frame, which is not seekable. Hence, any streams encoded with
this option enabled will not be seekable.
instead of get_ue_golomb(). The difference between the two is that the
latter also has to take into account the case in which the read code is
more than 9 bits (four preceding zeroes + at most five value bits) long,
leading to more code.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
get_ue_golomb_31() reads nine bits and an array with 512 entries to
parse golomb codes. The longest golomb codes that fit into 9 bits use
four leading zeroes and five value bits and can encode numbers in the
0..30 range. 31 meanwhile is encoded on 11 bits and if the nine bits
read coincide with the first nine bits of the encoding of 31,
get_ue_golomb_31() returns 31 (and skips 11 bits).
But looking at the first nine bits only makes it impossible to distinguish
31 from 32..34. Therefore the documentation of get_ue_golomb_31() simply
states that the return value is undefined if the value of the encountered
exp golomb code was outside the 0..31 range.
But actually get_ue_golomb_31() does not behave that bad: If the returned
value is in the range of 0..30, then this is the actually encountered value,
so that this function can be used without any problems to parse and validate
parameters whose legal values are a subset of the 0..30 range.
This commit documents this fact.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This happened in get_ue_golomb() if the cached bitstream reader was in
use, because there was no check to handle the case of the read value
not being in the supported range.
For consistency with the uncached bitstream reader and for compliance
with the documentation, every value not in the 0-8190 range is treated as
error although the cached bitstream reader could actually read values in
the range 0..65534 without problems.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This patch adds support for PPM marker for JPEG2000
decoder. It allows the samples p1_03.j2k and p1_05.j2k
to be decoded.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Said error message is not very informative and lacked a proper logging
context; furthermore, many callers already provided more descriptive
error messages of their own. So just drop this one.
Suggested-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This reverts commit 489c5db0791f39518775b12eef6d48276c17f96f.
Treating EQUAL_MULTI_ROWS in the same way as the arbitrary-size cases is
just wrong. Consider 9 rows, 4 slices - we pick 4 slices with sizes
{ 3, 2, 2, 2 }, which EQUAL_MULTI_ROWS does not allow. It isn't possible
to split the frame into 4 slices at all with the EQUAL_MULTI_ROWS
structure - the closest options are 3 slices with sizes { 3, 3, 3 } or 5
slices with sizes { 2, 2, 2, 2, 1 }.
The codeblock decoder checks whether the mqc decoder
has decoded the right number of bytes. However, this
check does not account for the fact that the mqc encoder's
flush routine adds 2 bytes of data which does not have to be
read by the decoder. The check is modified to account for
this. This patch solves issue #4827
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Later the decorrelate_stereo call is guarded by channels == 2
and non-zero decorr_left_weight. Make sure decorr_shift is in
the expected shift range for that case.
Fixes: shift exponent 128 is too large for 32-bit type 'int'
Fixes: 23860/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5751138914402304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
