ff_slice_thread_init() uses a static variable to hold a function
pointer, although the value of said pointer needn't be saved between
different runs of this function at all.
The reason for this being so is probably that said pointer points to
a static function (if used); but storage class specifiers like "static"
are not part of the type of an object and so including it in the pointer
declaration is wrong (anyway, "static" means different things in both
contexts: for the function declaration it affects linkage, for the
variable storage duration).
Using a static variable here can lead to races, e.g. when initializing
VP9 (for which said function pointer was added) and H.264 with slice
threading. The latter has the FF_CODEC_CAP_INIT_THREADSAFE flag set and
is therefore unaffected by the lock guarding initializations of
decoders.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using MPEG-2 intra VLC tables is spec-incompliant for MPEG-1 and given
that an MPEG-1 bitstream can't signal whether MPEG-2 intra VLC tables
have been used the output is broken. Therefore this option is removed
immediately without any deprecation period.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They are not always coded in the bistream for each frame. In some cases, the
values need to be taken from a reference frame.
See section 6.8.20 from the AV1 spec.
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit f9eec62983.
This does not effectively cover all cases. The values for some frames need
to be inferred by the decoder.
Signed-off-by: James Almer <jamrial@gmail.com>
The max depth is 16bps, the max allowed coefficient depth is depth+6
Fixes: signed integer overflow: 1074266112 + 1073725439 cannot be represented in type 'int'
Fixes: 26493/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5657763331702784
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These fields are not signed in the spec (1.0) so they cannot be negative
Changing bytes_per_packet to unsigned would not solve this as it is exported
as block_align which is signed
Fixes: Infinite loop
Fixes: 26492/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5632087614554112
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a pathological case where the fuzzer provides only 2 bytes per iteration.
Fixes: Timeout (>30 -> 0.9sec)
Fixes: 26488/clusterfuzz-testcase-minimized-ffmpeg_dem_MPEGTS_fuzzer-5911031077142528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also changes some default values for options after this change.
This makes distinction between feedback and wet option.
Before they would produce same output if values were swapped.
Currently a repeating setup request (with the same stream id) will
simply overwrite rtp_handle/transport_priv without freeing the
resources first. This is fixed by closing the previous setup request.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
