Supplying a hardware input frame which is not in the input hardware frames
context is not allowed by the API, so additional code to handle it is not
necessary. Further, handling it automatically results in very low
performance - it is more appropriate to fail immediately so that the user
can fix their incorrect setup.
If the user supplies a device or frames context then it is an error
not to use it; this is consistent with other hardware components.
Also factorise out the D3D11 initialisation and improve error
messages.
If a frame starts very close to a packet boundary, the start code may
already have been added to the parsing buffer, indicated by a small
negative value of "i", while the header is still being tracked in the
"state" variable.
Reduce the remaining size accordingly, otherwise trying to find the next
frame could skip over the frame header and lump two frames together as
one.
Fixes: out of array access
Fixes: poc_0411
Found-by: GwanYeong Kim <gy741.kim@gmail.com>
Tested-by: GwanYeong Kim <gy741.kim@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2147483646 - -2816 cannot be represented in type 'int'
Fixes: crbug 823145
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Limited to widths multiple of 8 (RGB) due to lack of test files for such corner case
This partially fixes ticket #5639
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Before adding uvlinesize check, I was seeing failures decoding
some video with ffmpeg compiled with --enable-gray and using AV_CODEC_FLAG_GRAY.
[mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed: linesize=1280/1280 uvlinesize=0/640)
[mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed: linesize=1280/1280 uvlinesize=0/640)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If there is a decoder initialization failure detected in avcodec_open2
after .init is called, allow graceful decoder .close to prevent leaking
libopus decoder allocations.
BUG=828526
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes the XP compatibility code, and switches entirely to SRW
locks, which are available starting at Windows Vista.
This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.
Windows XP is hereby not a supported build target anymore.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Limits based on 3GPP TS 26.245 V14.0.0
Fixes: Timeout
Fixes: 6377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOVTEXT_fuzzer-5175929115508736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Set the flag MFX_BITSTREAM_COMPLETE_FRAME when it is a progressive picture.
This can fix vc1 decoding segment fault issues because can't set the start
code correctly.
See: ./avconv -hwaccel qsv -c:v vc1_qsv -i /fate-suite/vc1/SA00040.vc1
-vf "hwdownload, format=nv12" -f rawvideo /dev/null
v2: fix some h264 interlaced clips regression
a. field_order of some h264 interlaced video (e.g: cama3_vtc_b.avc) is marked as AV_FIELD_UNKNOWN
in h264_parser.c. This is not a completed frames.
So only set the MFX_BITSTREAM_COMPLETE_FRAME when it is progressive.
b. some clips have both progressive and interlaced frames (e.g.CAPAMA3_Sand_F.264),
the parsed field_order maybe changed druing the decoding progress.
This patch has been verified for other codecs(mpeg2/hevc/vp8).
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
Currently pict_type and key_frame are unset.
Add an extra param to fetch the picture type from qsv decoder
The judgement “key frame is equal to IDR frame” only suitable for H264.
For HEVC, all IRAP frames are key frames, and other codecs have no IDR
frame.
Signed-off-by: ChaoX A Liu <chaox.a.liu@intel.com>
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
Fixes: runtime error: signed integer overflow: 2052929346 + 204817098 cannot be represented in type 'int'
This was missed in b1bef755f6
Fixes: 5275/clusterfuzz-testcase-minimized-5367635958038528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The pseudo palette allocation is optional now. But if it's still
allocated (like the internal get_buffer2 implementation does, for
compatibility), it shouldn't print a warning.
PSEUDOPAL pixel formats are not paletted, but carried a palette with the
intention of allowing code to treat unpaletted formats as paletted. The
palette simply mapped the byte values to the resulting RGB values,
making it some sort of LUT for RGB conversion.
It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
formats. The last one, GRAY8, is more common, but its treatment is
grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
from typical Y video planes was not mapped to the correct RGB values.
This cannot be fixed, because AVFrame.color_range can be freely changed
at runtime, and there is nothing to ensure the pseudo palette is
updated.
Also, nothing actually used the PSEUDOPAL palette data, except xwdenc
(trivially changed in the previous commit). All other code had to treat
it as a special case, just to ignore or to propagate palette data.
In conclusion, this was just a very strange old mechnaism that has no
real justification to exist anymore (although it may have been nice and
useful in the past). Now it's an artifact that makes the API harder to
use: API users who allocate their own pixel data have to be aware that
they need to allocate the palette, or FFmpeg will crash on them in
_some_ situations. On top of this, there was no API to allocate the
pseuo palette outside of av_frame_get_buffer().
This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
the pseudo palette optional. Nothing accesses it anymore, though if it's
set, it's propagated. It's still allocated and initialized for
compatibility with API users that rely on this feature. But new API
users do not need to allocate it. This was an explicit goal of this
patch.
Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
functions manually changed to not allocating a palette.
This is the only code I found within FFmpeg that still inherently
requires AV_PIX_FMT_FLAG_PSEUDOPAL. It's easily changed not to require
it.
Preparation for the next patch.
Mark Thompson
Timo Rothenpieler
Hendrik Leppkes
Paul B Mahol
Michael Niedermayer
Jérôme Martinez
Aman Gupta
Matt Wolenetz
Alexander Kravchenko
Rodger Combs
Diego Biurrun
wm4
Vittorio Giovara
Meng Wang
Zhong Li
Maxym Dmytrychenko
Carl Eugen Hoyos
Martin Vignali
Valery Kot
James Almer
Gagandeep Singh