There are 2 types of problems when using adaptive deinterlace with cuvid:
1. Sometimes, in the middle of transcoding, cuvid outputs frames with visible horizontal lines (as though weave deinterlace method was chosen);
2. Occasionally, on scene changes, cuvid outputs a wrong frame, which should have been shown several seconds before (as if the frame was assigned some wrong PTS value).
The reason is that sometimes CUVIDPARSERDISPINFO has property progressive_frame equal to 1 with interlaced videos.
In order to fix the problem we should check if the video is interlaced or progressive in the beginning of a video sequence (cuvid_handle_video_sequence).
And then we just use this information instead of the property progressive_frame in CUVIDPARSERDISPINFO (which is unreliable).
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Fixes: SEGV on unknown address
Fixes: 14198/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5723579234123776
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I do not know if such vlc trees are allowed in agm, I have no specification
So i do not know if these should be treated as error, or not.
But the code does contain a check for idx < 0 already ...
Fixes: Stack-buffer-overflow in get_tree_codes
Fixes: 14189/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5745747003179008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: index 20 out of bounds for type 'const char *[4][128]'
Fixes: 14367/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CCAPTION_fuzzer-5718819672162304
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Improves overall speed by about 3%
Testcase: 14124/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-5633887734071296
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It seems the specification does not limit the value to 32bit
Fixes: signed integer overflow: -109611143 * 24 cannot be represented in type 'int'
Fixes: 13477/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5648337460527104
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes a bogus compiler warning (max_samples_per_frame is checked):
libavcodec/alac.c: In function ‘allocate_buffers’:
./libavutil/internal.h:142:9: warning: argument 1 value ‘18446744073709551552’ exceeds maximum object size 9223372036854775807
The spec defines it as an array of signed values, inferred to 0 when not
present.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 255 + 2147483634 cannot be represented in type 'int'
Fixes: 13472/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5712444142387200
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: 14110/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5649184864075776
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
153372 UNITS in postfilter_c, 65536 runs, 0 skips
73164 UNITS in postfilter_neon, 65536 runs, 0 skips -> 2.1x speedup
80591 UNITS in deemphasis_c, 131072 runs, 0 skips
43969 UNITS in deemphasis_neon, 131072 runs, 0 skips -> 1.83x speedup
Total decoder speedup: ~15% on a Raspberry Pi 3 (from 28.1x to 33.5x realtime)
Deemphasis SIMD based on the following unrolling:
const float c1 = CELT_EMPH_COEFF, c2 = c1*c1, c3 = c2*c1, c4 = c3*c1;
float state = coeff;
for (int i = 0; i < len; i += 4) {
y[0] = x[0] + c1*state;
y[1] = x[1] + c2*state + c1*x[0];
y[2] = x[2] + c3*state + c1*x[1] + c2*x[0];
y[3] = x[3] + c4*state + c1*x[2] + c2*x[1] + c3*x[0];
state = y[3];
y += 4;
x += 4;
}
Unlike the x86 version, duplication is used instead of pslldq so
the structure and tables are different.
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 13999/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5644405991538688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 13997/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5701427252428800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
GPB is the default type, just contains forward references but the
slice_type is B slice with higher encoding efficiency than regular P
slice, but lower performance.
Add an option to allow user to set regular P slice.
Fix ticket#6870
Test data on Intel Kabylake (i7-7567U CPU @ 3.50GHz):
1. ffmpeg -hwaccel qsv -c:v h264_qsv -i bbb_sunflower_1080p_30fps_normal.mp4 -vsync passthrough
-vframes 1000 -c:v hevc_qsv -gpb 0 -bf 0 -q 25 test_gpb_off_bf0_kbl.mp4
transcoding fps: 85
encoded file size of test_gpb_off_bf0_kbl.mp4: 21960100 (bytes)
2. ffmpeg -hwaccel qsv -c:v h264_qsv -i bbb_sunflower_1080p_30fps_normal.mp4 -vsync passthrough
-vframes 1000 -c:v hevc_qsv -gpb 1 -bf 0 -q 25 test_gpb_on_bf0_kbl.mp4
transcoding fps: 79
encoded file size oftest_gpb_on_bf0_kbl.mp4: 21211449 (bytes)
In this case, enable gpb can bring about 7% performance drop but 3.4% encoding efficiency improvment.
Signed-off-by: Zhong Li <zhong.li@intel.com>
This brings the channel order in line with that used in 32-bit mode (BGR0).
24-bit decoding is disabled by default (#ifdef ZMBV_ENABLE_24BPP), and no
prior encoders or sample videos are known to exist for this bit depth, so
I consider this change in implementation is unlikely to affect anyone.
The decision has been made in agreement with the DOSBox Development Team
(dosbox.crew@gmail.com), specifically with harekiet, who wrote the original
codec.
