Note that Screen-Extended Main 4:4:4 and 4:4:4 10 supports
chroma_format_idc from 0, 1 or 3, hence both 420 and 444 are
supported.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Screen Content Coding allows non-intra slice in an IRAP frame which can
reference the frame itself, and would mark the current decoded picture
as "used for long-term reference", no matter TwoVersionsOfCurrDecPicFlag(8.1.3),
hence some previous restricts are not suitable any more.
Constructe RefPicListTemp and RefPicList according to 8-8/9/10. Disable
slice decoding for SCC profile to avoid unexpected error in hevc native
decoder and patch welcome.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
According to 7.3.6.1, use_integer_mv_flag should be parsed if
motion_vector_resolution_control_idc equals to 2. If not present, it
equals to motion_vector_resolution_control_idc.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
1. Add extension syntax according to 7.3.2.2.3/7.3.2.3.3 in T-REC-H.265-201911.
2. Keep using parsed PPS when bitstream overread for compatibility. For
example, the clip PS_A_VIDYO_3.bit in FATE test has incomplete extension
syntax which will be overread and un-decodable if without this change.
3. Format brace in pps_range_extensions().
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Described in HEVC spec A.3.7. Bump minor version and add APIchanges
entry for new added profile.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Fixes: out of array access
Fixes: 48567/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINK_fuzzer-6657932926517248
Alterantivly to this it is possibly to allocate a bigger array
Note: oss-fuzz assigned this issue to a unrelated theora bug so the bug number matches that
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 read on 32bit
Fixes: 54857/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5840588224462848
The chroma MC code reads over the currently allocated frame.
Alternative fixes would be allocating a few bytes more at the end instead of a whole
line extra or to adjust the threshold where the edge emu code is activated
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: 48567/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PNG_fuzzer-6716193709096960
Alternatively it should be possible to limit this to 3 plane RGB 8 /16bit to ensure the size is what it should be
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Such filters will not advance and be stuck in the current implementation
Fixes: Infinite loop
Fixes: 56052/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-5236218750435328
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -3201
Fixes: integer overflow: -76470276 * -25608 cannot be represented in type 'int'
Fixes: 56052/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-5236218750435328
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Remove CONFIG_VAAPI for VUYX, YUYV422, Y210, XV30, Y212, XV36.
Make 8-bit, 10-bit, 12-bit YUV 4:2:2 video sources as well as YUV 4:4:4
video sources supported by d3d11va and dxva2 just like what VAAPI does.
Sign-off-by: Tong Wu <tong1.wu@intel.com>
When encode RGB frame, Intel driver convert RGB to YUV, so we cannot
set RGB colorspace to VPL/MSDK.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
CC libavcodec/libx265.o
libavcodec/libx265.c: In function ‘libx265_encode_frame’:
libavcodec/libx265.c:781:5: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
libavcodec/libx265.c:782:1: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘else’
FF_DISABLE_DEPRECATION_WARNINGS
^~~
Signed-off-by: Marton Balint <cus@passwd.hu>
Their usefulness is questionable, very few decoders set them, and their type
should have been int64_t. A replacement field can be added later if a valid use
case is found.
Signed-off-by: Marton Balint <cus@passwd.hu>
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we use 64 bit
values for them.
Also deprecate the old 32 bit frame_number attribute.
Signed-off-by: Marton Balint <cus@passwd.hu>
libavutil/color_utils contains some avpriv_ symbols that map
enum AVTransferCharacteristic values to gamma-curve approximations and
to the actual transfer functions to invert them (i.e. -> linear).
There's two issues with this:
(1) avpriv is evil and should be avoided whenever possible
(2) libavutil/csp.h exposes a public API for handling color that
already handles primaries and matricies
I don't see any reason this API has to be private, so this commit takes
the functionality from avutil/color_utils and merges it into avutil/csp
with an exposed av_ API rather than the previous avpriv_ API.
Every reference to the previous API has been updated to point to the
new one. color_utils.h has been deleted as well. This should not break
any applications as it only contained avpriv_ symbols in the first
place, so nothing in that header could be referenced by other
applications.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Linjie Fu