nvenc doesn't support P016, but we have two problems today:
1) We declare support for YUV444P16 which nvenc also doesn't support.
We do this because it's the only pix_fmt we have that can
approximate nvenc's internal format that is YUV444P10 with data in
MSBs instead of LSBs. Because the declared format is a 16bit one,
it will be preferrentially chosen when encoding >10bit content,
but that content will normally be YUV420P12 or P016 which should
get mapped to P010 and not YUV444P10.
2) Transcoding P016 content with nvenc should be possible in a pure
hardware pipeline, and that can't be done if nvenc doesn't say it
accepts P016. By mapping it to P010, we can use it, albeit with
truncation. I have established that swscale doesn't know how to
dither to 10bits so we'd get truncation anyway, even if we tried
to do this 'properly'.
Fixes: 6154/clusterfuzz-testcase-minimized-5762231061970944
Fixes: runtime error: shift exponent 63 is too large for 32-bit 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>
External headers are no longer welcome in the ffmpeg codebase because they
increase the maintenance burden. However, in the NVidia case the vanilla
headers need some modifications to be usable in ffmpeg therefore we still
provide them, but in a separate repository.
The external headers can be found at
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
Fate-source is updated because of the deleted files, and dynlink_loader.h
license headers were updated with the standard FFmpeg headers.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Fixes: Timeout
Fixes: 6266/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-5692431816196096
Its not known if nb_tiles is allowed so it is not treated as an error
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will result in poor quality audio for SSR streams, but they
will at least demux and decode without error; partially fixing
ticket #1693.
This pulls in the decode_gain_control() function from the
ffmpeg summer-of-code repo (original author Maxim Gavrilov) at
svn://svn.mplayerhq.hu/soc/aac/aac.c with some minor modifications
and adds AOT_AAC_SSR to decode_audio_specific_config_gb().
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Co-authored-by: Maxim Gavrilov <maxim.gavrilov@gmail.com>
This is needed by later hwaccel code to tell which encoding process was
used for a particular frame, because hardware decoders may only support a
subset of possible methods.
* commit '78fa0b9033':
h264_metadata: Always add the SEI user data to the first access unit
Mostly already present from a308872b04,
one cosmetic change applied.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '69062d0f9b':
h264_metadata: Use common SEI addition function
Minor changes because the following patch is already present.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '13ca5d34ba':
cbs_h264: Add hack for pic_timing with no active SPS
Partially fixes#6896 - the sample stream from that ticket now works, but
more obscure cases can still fail.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit 'c8e135ea92':
vaapi_encode: Allocate slice structures and parameter buffers dynamically
Already present as e4a6eb70f4, one minor
fix for libav merged.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '1d12a545ce':
cbs: Add an explicit type for coded bitstream unit types
Mostly already present from 6734eef6b8, two
minor message changes are merged.
Merged-by: Mark Thompson <sw@jkqxz.net>
