The concatf protocol returns an opaque error on open if
concatf list file contains trailing newlines.
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
Reviewed-by: James Almer <jamrial@gmail.com>
If the input stream framerate is known, it will be configured on the
relevant filtergraph input and get propagated to the output stream in
the above line. That makes these assignments redundant.
Instead of storing the protocol pointer in the opaque iteration state,
store just the index of the next protocol, similarly to how
ff_urlcontext_child_class_iterate() works.
Silences e.g. the following warning in gcc 10:
src/libavformat/ftp.c: In function ‘ftp_move’:
src/libavformat/ftp.c:1122:46: warning: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4091 [-Wformat-truncation=]
1122 | snprintf(command, sizeof(command), "RNTO %s\r\n", path);
| ^~ ~~~~
src/libavformat/ftp.c:1122:5: note: ‘snprintf’ output between 8 and 4103 bytes into a destination of size 4096
1122 | snprintf(command, sizeof(command), "RNTO %s\r\n", path);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Silences the following warning with gcc 10:
src/libavdevice/v4l2.c: In function ‘v4l2_get_device_list’:
src/libavdevice/v4l2.c:1042:64: warning: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 251 [-Wformat-truncation=]
1042 | ret = snprintf(device_name, sizeof(device_name), "/dev/%s", entry->d_name);
| ^~
src/libavdevice/v4l2.c:1042:15: note: ‘snprintf’ output between 6 and 261 bytes into a destination of size 256
1042 | ret = snprintf(device_name, sizeof(device_name), "/dev/%s", entry->d_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Previous patches intending to silence it have proposed increasing the
buffer size, but doing that correctly seems to be tricky. Failing on
truncation is simpler and just as effective (as excessively long device
names are unlikely).
device and cap are local to the loop iteration, there is no need for
them to retain their values. Especially for device it may be dangerous,
since it points to av_malloc'ed data.
The FD opened here is local to the loop iteration, there is no reason to
store it in the context. Since read_header() may have already been
called, this may ovewrite an existing valid FD.
Maximum output size with a 32-bit int is 17 bytes, or 26 with a 64-bit
int.
Silences the following gcc 10 warning:
src/libavdevice/jack.c: In function ‘audio_read_header’:
src/libavdevice/jack.c:171:45: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
171 | snprintf(str, sizeof(str), "input_%d", i + 1);
| ^
src/libavdevice/jack.c:171:9: note: ‘snprintf’ output between 8 and 17 bytes into a destination of size 16
171 | snprintf(str, sizeof(str), "input_%d", i + 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do this by switching from the dynamic buffer API to the AVBPrint API;
the former has no defined way to check for errors.
This also avoids allocating an AVIOContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by switching from the dynamic buffer API to the AVBPrint API;
the former has no defined way to check for errors.
This also avoids allocating an AVIOContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
