No speed difference, or slightly faster (the difference is too small so it may be noise
that this appears faster)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Infinite loop
Found-by: Michael Hanselmann <public@hansmi.ch>
Reviewed-by: Michael Hanselmann <public@hansmi.ch>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We assume that if the compressed size is bigger than if each byte is encoded in a single raw packet
that the data is invalid.
Fixes: Out of memory
Fixes: 12208/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RASC_fuzzer-5648916473708544
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In Windows if using scaling other than 100% then the grabbed window was not captured fully (cropped)
Signed-off-by: Dilshod Mukhtarov <dilshodm@gmail.com>
Fixes: Timeout
Fixes: 12192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
Before: clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264 in 15423 ms
After: clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264 in 190 ms
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 12447/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5201623956062208
Fixes: 12458/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HYMT_fuzzer-5705567736168448
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The addition is moved up into the context where the variable is unsigned avoiding
the undefined behavior
Fixes: runtime error: signed integer overflow: 2147481972 + 4096 cannot be represented in type 'int'
Fixes: 12444/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5755706244857856
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When making a new P-frame when B-frames are present the previous P-frame
is normally in the DPB because it will be referred to by subsequent
B-frames. However, this is not true if there are no B-frames, or in edge
cases where a GOP ends with two P-frames. Fix this by adding the direct
ref pics to the RPS explicitly.
Fixes#7699.
Tested-by: Ullysses A Eoff <ullysses.a.eoff@intel.com>
The timestamp of the changed input frame as well as its relevant
properties can be examined by the user. Only applicable when
reinit_filter is disabled on the input stream.
The specification requires the demuxer to only read the data
atom up to its given size, this is necessary as atoms are
allowed at the end of the file.
This patch duplicates the behaviour of the QuickTime player.
The "new" entry point actually has existed since OpenH264 1.4 in
2015 and is the the recommended decoding entry point.
The name of this function, DecodeFrameNoDelay, is rather backwards
considering that it doesn't return the latest decoded frame immediately,
but actually does proper delaying and reordering of frames.
Signed-off-by: Martin Storsjö <martin@martin.st>
The VP3/4/5/6 reference decoders all use three IDCT versions: one for the
DC-only case, another for blocks with more than 10 coefficients, and an
optimised one for blocks with up to 10 AC coefficents. VP6 relies on the
sparse 10 coefficient version, and without it, IDCT drift occurs.
Fixes: https://trac.ffmpeg.org/ticket/1282
Signed-off-by: Peter Ross <pross@xvid.org>
As .rodata isn't one of the default created sections for COFF, it was
created as a read-write data section. By using the default .rdata
section name for COFF, it automatically becomes a read-only data section.
The existing ".section .rodata" works as intended for ELF though.
This is based on an original patch and diagnose by Tom Tan
<Tom.Tan@microsoft.com>.
Signed-off-by: Martin Storsjö <martin@martin.st>
QVBR mode is to use the variable bitrate control algorithm
with constant quality.
mfxExtCodingOption3 should be supported to enable QVBR mode.
It is neccesary to specify a max_rate for QVBR, else it may be ICQ mode.
Example usage: ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v
h264_qsv -global_quality 25 -maxrate 2M test_qvbr.mp4 -v verbose
Clip QVBR quality range to be [0, 51] as Mark's commments.
It is similar to qp range of CQP but possibly should be updated when VP8/VP9
encoding can be supported.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Zhong Li <zhong.li@intel.com>
