This ensures that if a codec isn't on codec_whitelist, trying to open it
will not trigger ff_codec_close(), which could invalidate useful
information still present in the context.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Implement the missing requirements from H.266 (V3) p. 106 on the
position and size of subpictures whose dimensions are provided
explicitly.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The previous logic relied on the subpicture boundaries coinciding with
the tile boundaries. Per 6.3.1 of H.266 (V3), vertical subpicture
boundaries are always tile boundaries however the same cannot be said
for horizontal subpicture boundaries. Furthermore, it is possible to
construct an illegal bitstream where vertical subpicture boundaries are
not coincident with tile boundaries. In these cases, the condition of
the while loop would never be satisfied resulting in an OOB read on
col_bd/row_bd.
Patch fixes this issue by replacing != with <, thereby not requiring
subpicture boundaries and tile boundaries to be coincident.
Signed-off-by: Frank Plowman <post@frankplowman.com>
fix
==135000== Conditional jump or move depends on uninitialised value(s)
==135000== at 0x169FF95: vvc_deblock_bs (filter.c:699)
and
==135000== Conditional jump or move depends on uninitialised value(s)
==135000== at 0x16A2E72: ff_vvc_alf_filter (filter.c:1217)
Reported-by: James Almer <jamrial@gmail.com>
BDoF used about 10%–25% of the CPU for some clips.
Here are the FPS for one run; please ignore the negative values, as they may be due to round-to-round variation
clips | before | after | delta
--------------------------------------------|--------|-------|------
RitualDance_1920x1080_60_10_420_37_RA.266 | 310.0 | 363.0 | 14.60%
NovosobornayaSquare_1920x1080.bin | 322.3 | 339.7 | 5.12%
Tango2_3840x2160_60_10_420_27_LD.266 | 71.0 | 68.7 | -3.35%
RitualDance_1920x1080_60_10_420_32_LD.266 | 250.0 | 245.3 | -1.92%
Chimera_8bit_1080P_1000_frames.vvc | 359.3 | 422.7 | 15.00%
BQTerrace_1920x1080_60_10_420_22_RA.vvc | 142.3 | 147.7 | 3.66%
Reviewed-by: James Almer <jamrial@gmail.com>
Its not really used but its passed as a argument and then not used
Fixes: 70965/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSMPEG4V1_fuzzer-5583223747313664
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 70850/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAVOICE_fuzzer-4806127362048000
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized value
Fixes: 71230/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NOTCHLC_fuzzer-4624502095413248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 71228/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-6188476880453632
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized value
Fixes: 71072/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-4835252046987264
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There are two VTCompressionSessionRef been created, one for generating
extradata, and another for normal encoding. supported_props was been
overwritten without release.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Filter init can change extradata from avcc/hvcc to annexb format.
With different passthrough logic, packets can still in avcc/hvcc
format. Use same passthrough logic for init and filter.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Current code is written around the "simple" decode API's limitation that
a single input packet (AU/coded frame) triggers the output of at most
one output frame. However the spec contains two cases where a coded
frame may cause multiple frames to be output (cf. C.5.2.2.2):
* start of a new sequence
* overflowing sps_max_dec_pic_buffering
The decoder currently contains rather convoluted logic to handle these
cases:
* decode/output/per-frame sequence counters,
* HEVC_FRAME_FLAG_BUMPING
* ff_hevc_bump_frame()
* special clauses in ff_hevc_output_frame()
However, with the receive_frame() API none of that is necessary, as we
can just output multiple frames at once. Previously added ContainerFifo
allows that to be done in a straightforward and efficient manner.
It provides a FIFO for "container" objects like AVFrame/AVPacket and
features an integrated FFRefStructPool-based pool to avoid allocating an
freeing them repeatedly.
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 70726/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-6149928703819776
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Usually the MediaCodec context will be released immediately, or it needs to stay
alive due to existing hardware buffers.
However we can free resources early in the case of
hw_buffer_count == 0 && refcount > 1, which can be reproduced by keeping frames
referenced after flushing and closing. mpv currently behaves like this.
Signed-off-by: sfan5 <sfan5@live.de>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
James Almer
Ramiro Polla
Dale Curtis
Matthieu Bouron
Rémi Denis-Courmont
Zhao Zhili
Frank Plowman
Nuo Mi
Michael Niedermayer
Anton Khirnov
sunyuechi
sfan5
Niklas Haas