av_image_copy() expects an array of four pointers and linesizes
according to its declaration; it currently only pointers that are
actually in use (depending upon the pixel format), but this might
change at any time. It has already happened for the linesizes in
d7bc52bf45 and so increasing their
array fixes a stack-buffer overread.
This fixes a -Wstringop-overflow= and -Wstringop-overread warning
from GCC 11.2.
Reviewed-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reduces codesize because the offsets of commonly used elements
are now smaller and thus need less bytes to encode in ptr+offset
addressing modes (with GCC 11.2 on x64: 0x1b8b -> 0x1a7b).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, it also tests whether extended_data points to something
different than the AVFrame's data array and frees extended_data
if it is different. Yet this is only necessary for one of its three
callers, namely av_frame_unref(); meanwhile the other two callers
took measures to avoid this (or rather, to make it to an av_free(NULL)).
This commit moves this chunk to av_frame_unref() (so that
get_frame_defaults() now treats its input as uninitialized)
and removes the now superfluous code in the other two callers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only caller of do_video_out() doesn't need the frame afterwards,
ergo one can replace an av_frame_ref() by av_frame_move_ref().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently, adding a (separately allocated) element to a list of pointers
works by first reallocating the array of pointers and (on success)
incrementing its size and only then allocating the new element.
If the latter allocation fails, the size is inconsistent, i.e.
array[nb_array_elems - 1] is NULL. Our cleanup code crashes in such
scenarios.
Fix this by adding an auxiliary function that atomically allocates
and adds a new element to a list of pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The data stored in data[3] in VAAPI AVFrame is VASurfaceID while
the data stored in pair->first is the pointer of VASurfaceID, so
we need to do cast to make following commandline works:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi -i input.264 \
-vf "hwmap=derive_device=qsv,format=qsv" -c:v h264_qsv output.264
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The documentation states that here 0 should be used for read-only and
1 for a writable buffer. AVIO_FLAG_WRITE however is 2, while it works
due to the way the flag is handled internally, it is still wrong
according to the documentation.
Additionally it makes it seem as if the AVIO_FLAG_* values could be used
here, which is actually not true, as when AVIO_FLAG_READ would be used
here it would create a writable buffer as AVIO_FLAG_READ is defined as 1.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Old system is:
OSX version: 10.11.6
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
this allows getting rid of the hardcoded max size of SDP.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
These lists have size fields since
e48ded8551.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The length of this list is a compile-time constant, so there is
no need to calculate it again at runtime.
(This also avoids an implicit requirement of -1 == AV_SAMPLE_FMT_NONE.)
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An AVBPrint's internal string is always already zero-terminated;
writing another '\0' is unnecessary as long as one treats
the string only as a C-string.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
choose_pix_fmts() used the dynamic buffer API to write strings;
as is common among uses of this API, only opening the dynamic buffer
was checked, but not the end result, leading to crashes in case
of allocation failure.
Furthermore, some static strings were duplicated; the allocations
performed here were not properly checked: Allocation failure would
be treated as "could not determine pixel format".
The first issue is fixed by switching to the AVBPrint API which allows
to easily perform checks at the end. Furthermore, the internal buffer
avoids almost all allocations in case the AVBPrint is used.
The AVBPrint also allows to solve the second issue in an elegant way,
because it allows to return the static strings directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not really natural, it requires internal allocations
of its own and its error handling is horrible (i.e. the implicit
(re)allocations here are unchecked).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the h264_redundant_pps_bsf stored the initial value
of pic_init_qp_minus26 of the most recently encountered PPS;
it also modified the slices based upon to assumption that
the most recent PPS is the PPS the slice belongs to.
Yet this assumption is flawed, as there can be several PPS
with different IDs that are visible at any given time.
If these have different pic_init_qp_minus26 values,
the output can be invalid.
Fix this by directly using the pic_init_qp_minus26 value of
the input PPS.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
extradata_pic_init_qp is unset since
fa75e43875
(and resetting current_pic_init_qp to the value it had in extradata
never made much sense).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not documented that freeing the last (and only) entry of
an AVDictionary frees the dictionary.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SWR_CH_MAX is internal only and the arrays are therefore not required
to have that many elements (and they typically don't do it). So remove
this potentially confusing hint.
(Newer versions of GCC emit -Warray-parameter= warnings for this,
because the definition with explicit size differs from the declaration
(which leaves the size unspecified); this is IMO a false-positive,
because definition and declaration didn't conflict, but anyway it is
fixed by this commit.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The number of audio channels is stored after the magic number
identifying the audio format. Prior to this patch the code has been
reading it earlier, causing files with only one audio channel to be
handled incorrectly.
Reviewed-by: Peter Ross <pross@xvid.org>
Michael Niedermayer
Andreas Rheinhardt
Gyan Doshi
Anton Khirnov
nyanmisaka
Marvin Scholz
Limin Wang
Lynne
John-Paul Stewart