Zane van Iperen [Sun, 8 Mar 2020 12:09:02 +0000 (12:09 +0000)]
avcodec: add decoder for High Voltage Software's ALP ADPCM
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
dump_extradata: Insert extradata even for small packets
3469cfab added a check for whether the extradata coincided with the
beginning of the packet's data in order not to add extradata to packets
that already have it. But the check used was buggy for packets whose
size is smaller than the extradata's size. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Left shifts of signed values are undefined as soon as the result is
no longer representable in the target type. Therefore make nal_size
an uint32_t and drop the check for whether it is < 0.
2. The two checks for overreads (whether the length field is contained
in the packet and whether the actual unit is contained in the packet)
can be combined into one because the packet is padded, i.e. a potential
overread caused by reading the length field without checking whether
said length field is actually part of the packet's buffer is allowed
as one always stays within the padding. But one has to be aware of
a pitfall: The comparison must be performed in (at least) int64_t as
otherwise buf_end - buf might be promoted to uint32_t in which case
an already occured overread would appear as a very large number.
A comment explaining this has been added, too.
3. Units of size zero are now silently dropped; the earlier code would
instead read the first byte of the next length field (or the first byte
of padding) to infer the type of the current unit.
4. Futhermore, the earlier code returned the wrong error code. This has
been fixed, too.
Fixes #8290.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
h264_mp4toannexb: Stop reallocating the output buffer
Up until now, h264_mp4toannexb would grow the output packet's buffer by
the desired amount every time another NAL unit of the input packet has
been read; this commit changes this: The input buffer is now essentially
parsed twice, once to determine the final size of the output packet and
once to write the output packet's data.
Fixes: Timeout Fixes: 19322/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-5688407821123584 Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
h264_mp4toannexb: Consistently use pointer comparisons
h264_mp4toannexb_filter currently uses both indices/offsets as well as
direct pointers comparisons for the checks whether one has reached or
even surpassed the end. This commit removes the offsets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If processing an input NAL unit triggers the insertion of data from
extradata in front of said NAL unit, the output packet is grown (i.e.
reallocated) once to accomodate both the new extradata as well as the
input NAL unit itself; this has been changed: In such a situation, the
packet is now grown twice. While this is bad for performance, it allows
to simplify the code and ultimately to stop reallocating the packet
altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
h264_mp4toannexb: Try to avoid four byte startcodes
According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not automatically be written with a four byte startcode, but only
when they already were at the beginning of their input packets. But it
made four byte startcodes be used too often as every unit that is written
together with a parameter set that is inserted from extradata received a
four byte startcode although a three byte start code would suffice
unless the unit itself were a parameter set.
FATE has been updated to reflect the changes. Although the patch leaves
the extradata unchanged, the size of the extradata according to the FATE
reports changes. This is due to a quirk in ff_h2645_packet_split which
is used by extract_extradata: If the input is Annex B, the first zero of
a four byte startcode is considered a part of the last unit (if any).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, h264_mp4toannexb stored the offset of the first SPS and
the first PPS in the (output) extradata in its context and used these
two numbers together with the size of the extradata and the pointer to
the extradata to determine what to insert when inserting extradata. This
led to some very long lines like "s->pps_offset != -1 ? s->pps_offset :
ctx->par_out->extradata_size - s->sps_offset". Therefore now pointers to
SPS and PPS are stored along with their respective sizes, so that e.g.
the above line can be changed to "s->sps_size".
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The format of an AVCDecoderConfigurationRecord, the out-of-band
extradata of H.264 in mp4, is as follows: First four bytes containing
version, profile and level, one byte for the length size and one byte
each for the number of SPS, followed by the SPS (each with its own size
field), followed by a byte containing the number of PPS followed by the
PPS with their size fields. While the number of SPS/PPS may be zero, the
bytes containing these numbers are mandatory. Yet the byte containing
the number of PPS has been ignored in two places:
1. In the initial check for whether the extradata can contain an
AVCDecoderConfigurationRecord. The minimum size is 7, not 6.
2. No check is made for whether the extradata ended right after the last
byte of the last SPS of the SPS array. Instead the first byte of the
padding is read as if it were part of the extradata and contained the
number of PPS (namely zero, given that the padding is zeroed). No error
or warning was ever raised.
This has been changed. Such truncated extradata is now considered
invalid; the check for 2. has been incorporated into the general size
check.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
h264_mp4toannexb: Add a comment about possible overread
Before reading a 16bit size field during parsing of extradata, no check
is performed to make sure that said length field is actually contained
in the extradata. Given that this overread is not dangerous (the extradata
is supposed to be padded), only a comment for it has been added; the error
itself will be detected as part of the normal check for overreads.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently during parsing the extradata, h264_mp4toannexb checks for
overreads by adding the size of the current unit to the current position
pointer and comparing this to the end position of the extradata. But
pointer comparisons and pointer arithmetic are only defined if it does not
exceed the object it is used on (one past the last element of an array
is allowed, too). In practice, this might lead to overflows. Therefore
the check has been changed to use bytestream2_get_bytes_left() which
means that the pointers get subtracted and the result gets compared to
the available size.
Furthermore, the error code has been fixed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
h264_mp4toannexb: Switch to GetByteContext to read extradata
This is done in order to improve readability. No functional change is
intended with this commit at all; in particular, the unsafe read
functions are used throughout as h264_extradata_to_annexb already
performs its own checks. (These checks will nevertheless be improved
in further commits.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
bytestream: Make get_bytes_left compatible with overread
bytestream2_get_bytes_left returns an unsigned int; as a result,
it returns big positive numbers if an overread already happened,
making it unsuitable for scenarios where one wants to allow this
in a controlled way (because the buffer is actually padded so that
no segfaults can happen). So change it to return an ordinary int.
Also, bytestream2_get_bytes_left_p has been modified in the same way.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Multiple out of array accesses Fixes: 20817/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SIREN_fuzzer-5754041227542528.fuzz 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: 20828/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_IMA_APM_fuzzer-5712770106654720 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>
Marton Balint [Sat, 29 Feb 2020 00:25:56 +0000 (01:25 +0100)]
avformat/mxfenc: use a zero based continuity counter
The standard does not seem to require the counter to be zero based, but some
checker tools (MyriadBits MXFInspect, Interra Baton) have validations against 0
start...
The second ; in a double ;; is actually a null statement. It triggers
the typical declaration-after-statement compiler-warnings if it occurs
in the middle of several declarations (like here).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fftools/ffmpeg_opt: Fix leak of options when parsing options fails
Fixes #8094.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The second ; in a double ;; is actually a null statement. It triggers
the typical declaration-after-statement compiler-warnings if it occurs
in the middle of several declarations (like here).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/ivfenc: Don't use size_t for size of file
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/magicyuv: Check that there are enough lines for interlacing to be possible
Fixes: out of array access Fixes: 20763/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5759562508664832 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>
Mark Thompson [Sun, 16 Feb 2020 20:59:54 +0000 (20:59 +0000)]
hwcontext_vaapi: Only accept a render node when deriving from DRM device
If we are given a non-render node, try to find the matching render node and
fail if that isn't possible.
libva will not accept a non-render device which is not DRM master, because
it requires legacy DRM authentication to succeed in that case:
<https://github.com/intel/libva/blob/master/va/drm/va_drm.c#L68-L75>. This
is annoying for kmsgrab because in most recording situations DRM master is
already held by something else (such as a windowing system), leading to
device derivation not working and forcing the user to create the target
VAAPI device separately.
Linjie Fu [Wed, 15 Jan 2020 07:00:12 +0000 (15:00 +0800)]
lavu/hwcontext_vaapi: add vaapi_format_map support for Y210
VA_RT_FORMAT describes the desired sampling format for surface.
When creating surface, VA_RT_FORMAT will be used firstly to choose
the expected fourcc/media_format for the surface. And the fourcc
will be revised by the value of VASurfaceAttribPixelFormat.
Add vaapi_format_map support for new pixel_format Y210.
This is fundamental for both VA-API and QSV.
Linjie Fu [Wed, 15 Jan 2020 06:59:34 +0000 (14:59 +0800)]
swscale: Add swscale input support for Y210LE
Add swscale input support for Y210LE, output support and fate
test could be added later if there is requirement for software
CSC to this packed format.
projects / ffmpeg / log