decode_user_data() attempts to create an integer |build|
value with 8 bits of spacing for 3 components. However
each component is an int32_t, so shifting each component
is undefined for values outside of the 8 bit range.
This patch simply clamps input to 8-bits per component
and prints out a warning that the values were clamped.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: left shift of negative value -255
Fixes: 4037/clusterfuzz-testcase-minimized-5290998163832832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously the codec kept an entire copy of the SPS, and restarted the VT decoder
session whenever it changed. This fixed decoding errors in [1], as
described in 9519983c. On further inspection, that sample features an SPS change
from High/4.0 to High/3.2 while moving from one scene to another.
Yesterday I received [2], which contains minor SPS changes where the
profile and level do not change. These occur frequently and are not associated with
scene changes. After 9519983c, the VT decoder session is recreated unnecessarily when
these are encountered causing visual glitches.
This commit simplifies the state kept in the VTContext to include just the first three
bytes of the SPS, containing the profile and level details. This is populated initially
when the VT decoder session is created, and used to detect changes and force a restart.
This means minor SPS changes are fed directly into the existing decoder, whereas
profile/level changes force the decoder session to be recreated with the new parameters.
After this commit, both samples [1] and [2] playback as expected.
[1] https://s3.amazonaws.com/tmm1/videotoolbox/spschange.ts
[2] https://s3.amazonaws.com/tmm1/videotoolbox/spschange2.ts
Signed-off-by: Aman Gupta <aman@tmm1.net>
This was predictably nightmarish, given how ridiculous mpeg4 is.
I had to stare at the cuvid parser output for a long time to work
out what each field was supposed to be, and even then, I still don't
fully understand some of them. Particularly:
vop_coded: If I'm reading the decoder correctly, this flag will always
be 1 as the decoder will not pass the hwaccel any frame
where it is not 1.
divx_flags: There's obviously no documentation on what the possible
flags are. I simply observed that this is '0' for a
normal bitstream and '5' for packed b-frames.
gmc_enabled: I had a number of guesses as to what this mapped to.
I picked the condition I did based on when the cuvid
parser was setting flag.
Also note that as with the vdpau hwaccel, the decoder needs to
consume the entire frame and not the slice.
The 'simple' hwaccels (not h.264 and hevc) all use the same bitstream
management and reference lookup logic so let's refactor all that into
common functions.
I verified that casting a signed int -1 to unsigned char produces 255
according to the C language specification.
The only purpose of dllexport (which is set while building the library
that exports the symbols) is to have the linker automatically
export such symbols into a DLL without using a def file - it doesn't
affect the generated code.
For both MSVC and mingw builds, this isn't essential since we override
what symbols to export via an autogenerated def file instead.
Update a comment in configure to refer to the right concept.
With lld, this avoids warnings about duplicate export directives,
when some symbols are requested to be exported both via dllexport
attributes and via the autogenerated def file.
This also reduces the number of lines of code marginally.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is mostly straight-forward. The weird part is that it should
just work for mpeg1, but I see corruption in my test cases, so I'm
going to try and fix that separately.
I took the reference lookup code from the vp9 hwaccel where the
type is unsigned char, but for vc1, the type is signed int.
This is particularly important because the value used when there's
no reference is different (255 vs -1).
It didn't seem to break anything, but for mpeg1/2/4, this mistake
caused decode errors.
Add to libavcodec/tests/.gitignore an entry for test
program libavcodec/tests/mpeg12framerate . Other
similar test programs, e.g. jpeg2000dwt and dct, are
ignored in a similar way.
On initially checking out master, and doing "./configure"
and "make clean", "git status" reports no untracked
files. After running "make fate", "git status" reports
untracked file "libavcodec/tests/mpeg12framerate".
mpeg12framerate is a unit test program. It was apparently
introduced in commit
278c308cea, on
Tue Sep 12 22:11:56 2017 +0100. It added a new function
ff_mpeg12_find_best_frame_rate() to
libavcodec/mpeg12framerate.c , and the code in
libavcodec/tests/mpeg12framerate.c to exercise that
function. This commit also added the new program to
the FATE suite, but it omitted a .gitignore entry.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These tables are static so they should only be initialized once
instead of on every call to ff_mpadsp_init().
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: left shift of negative value -7862264
Fixes: 4074/clusterfuzz-testcase-minimized-4516104123711488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 4035/clusterfuzz-testcase-minimized-6479308925173760
Fixes: runtime error: signed integer overflow: 9 * 402653183 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Michael Niedermayer
James Almer
Martin Vignali
Dale Curtis
James Zern
Aman Gupta
Mark Thompson
Philip Langdale
Martin Storsjö
Jim DeLaHunt
Carl Eugen Hoyos
Timo Rothenpieler
Kieran Kunhya
Umair Khan