Fixes: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int'
Fixes: 24011/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5486376610168832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The default for the chromaoffset field in AVCodecContext
is zero, which until now always ended up overriding the
AVOption-set value, thus leading to the AVOption not working.
Additionally, the previous usage prevented the usage of
negative values, while both the variable as well as x264's
API would successfully handle such.
Thus, the default value of the AVOption is changed to match
the default of x264 (and what is currently the default for
the AVCodecContext chromaoffset field), and the checks are
changed to check for nonzero values.
This way:
1. the library default is still utilized if the value is zero.
2. both negative and positive values are correctly passed to
x264.
For historical context, this was initially similarly
implemented in 5764d38173661c29d954711dd5abfddf709e9ba4, and
then b340bd8a58c32453172404a8e4240e3317e341da broke the
value.
Partially reverts commit b340bd8a58c32453172404a8e4240e3317e341da.
Signed-off-by: Takio Yamaoka <y.takio@gmail.com>
Fixes: shift exponent 32 is too large for 32-bit type 'int'
Fixes: 24566/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6033783737024512
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Gautam Ramakrishnan <gautamramk@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch allows the encoder to use SOP and EPH
markers. This would be useful as these markers
provide better error detection mechanisms.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Respecting the framerate in the libopenh264enc codec context.
Both the libx264 and libx265 encoders already contain similar logic
to first check the framerate before falling back to the timebase.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This differs from the MPEG specification as the actual real world
files do compute their CRC over variable areas and not the fixed
ones listed in the specification. This is also the reason for
the complexity of this code and the need to perform the CRC
check for layer2 in the middle of layer2 decoding.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
