Fixes: two use-of-uninitialized-value
Fixes: 70856/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-5539349918187520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Related: CID1473562 Unchecked return value
Related: CID1473592 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references the SPS, the SPS/PPS
needs to come first.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
binutils 2.43 has stricter validation for labels[1] and results in errors
when building ffmpeg for armv5:
src/libavcodec/arm/mlpdsp_armv5te.S:232: Error: junk at end of line, first unrecognized character is `0'
Remove the leading zero in the "01" label to resolve this error.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Reorganize the code such that the frame threading code does not call the
decoders directly, but instead calls back into the generic decoding
code. This avoids duplicating the logic that wraps the decoder
invocation and allows receive_frame()-based decoders to use frame
threading.
Further work by Timo Rothenpieler <timo@rothenpieler.org>.
Also, set draining=1 in case a bitstream filter returns an
internally-triggered EOF. While no bitstream filters currently inserted
by decoders will do that, that may change in the future and it is better
to cover this case.
thread.h currently contains both API for decoder use and functions
internal to lavc generic layer. Move the latter to avcodec_internal.h,
which is a more appropriate place for them.
That variable is shared between frame threads in the same defective way
described in the previous commit. Fix it by adding a RefStruct-managed
arrays of flags that is propagated across frame threads in the standard
manner.
Remove now-unused FFV1Context.fsrc
layered_dpb only makes sense when dedicated_dpb is set to 1.
For some mysterious reason, some Nvidia drivers stopped indicating
SEPARATE_REFRENCES, but kept the COINCIDE flag, which broke
the code.
Fixes runtime error: member access within misaligned address
<addr> for type 'av_alias64', which requires 8 byte alignment.
VP9mv is aligned to 4 bytes, so instead doing 8 bytes clear, let's do
2 times 4 bytes.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use-of-uninitialized value
Fixes: clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-5458626041413632
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes use of uninitialized value, reported by MSAN.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: 70852/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5179190066872320
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There is no known (real) hardware with V and without the complete B
extension. B was indeed required in the RISC-V application profile from
2022, earlier than V. There should not be any relevant hardware in the
future either.
In practice, different R-V Vector optimisations in FFmpeg already depend on
every constituent of the B extension anyhow, so it would not work well.
These are really just wrappers for idct4_add16intra functions, which are in
turn mostly wrappers for idct4_add and idct4_dc_add functions.
For benchmarks refer to the later two sets.
Before the patch, the method to generate DTS only works with
timebase equal to 1/fps. With timebase like 1/1000
./ffmpeg -i foo.mp4 -an -c:v h264_nvenc -enc_time_base 1/1000 bar.mp4
pts 0 dts -3
pts 160 dts 37
pts 80 dts 77
pts 40 dts 117 <-- invalid
pts 120 dts 157
pts 320 dts 197
pts 240 dts 237
pts 200 dts 277 <-- invalid
pts 280 dts 317 <-- invalid
The generated DTS can be larger than PTS, since it only reorder the
input PTS and minus the number of frame delay, which doesn't take
timebase into account. It should minus the "time" of frame delay.
9a245bd trying to fix the issue, but the implementation is incomplete,
which only use time_base.num. Then it got reverted by ac7c265b33.
After this patch:
pts 0 dts -120
pts 160 dts -80
pts 80 dts -40
pts 40 dts 0
pts 120 dts 40
pts 320 dts 80
pts 240 dts 120
pts 200 dts 160
pts 280 dts 200
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This was added along side the original SSE(one) DSP function in
0a68cd876e without rationale. This was
presumably faster on x87, which is no longer relevant since we pretty
much assume SSE2 or later on x86.
Meanwhile this function is ~2.5x slower than the normal floating point
one on SiFive-U74.
Given that source and destination can alias, the compiler was forced to
perform each read-modify-write sequentially. We cannot use the `restrict`
qualifier to avoid this here because the AC-3 encoder uses the function
in-place. Instead this commit provides an explicit guarantee to the
compiler that batches of 8 elements will not overlap, so that it can
interleave calculations.
In practice contemporary optimising compilers are able to unroll and keep
the temporary array in FPU registers (without spilling).
On SiFive-U74, this speeds the same signs branch by 4x, and the
opposite signs branch 1.5x.
The current code assumes that we have unaligned rows, which hurts on
platforms with slower unaligned accesses. (Also, this lets the compiler
unroll manually, which it seems to do in practice.)