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);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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>
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>
C99/C11 6.3.2.3 5: "Any pointer type may be converted to an integer
type. [...] If the result cannot be represented in the integer type,
the behavior is undefined." So stop casting pointers to int; use
uintptr_t instead.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to wrap them in #ifndef guards, they should only be
defined here and nowhere else. The define guards just add the
possibility to accidentally use the same FF_API name in different
libraries.
Fixes memleaks in case the trailer is never written.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_image_copy() expects an array of four pointers according to its
declaration; although it currently only touches pointers that
are actually in use (depending upon the pixel format) this might
change at any time (as has already happened for the linesizes
in d7bc52bf45).
This fixes ticket #9264 as well as a warning from GCC 11.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The problem here is that the lock ctx->frame_lock will become
an unreleased lock if the program returns at patched lines.
Bug tracker link: https://trac.ffmpeg.org/ticket/9386\#ticket
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
The problem here is that the lock ctx->frame_lock will
become an unreleased lock if the program returns at
line 697, line 735 and line744.
Bug tracker link: https://trac.ffmpeg.org/ticket/9385\#ticket
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
It only uses an AVIOContext and an AVBPrint.
When doing so, it turned out that several non-users of
ff_read_line_to_bprint_overwrite() and ff_bprint_to_codecpar_extradata()
relied on libavformat/internal.h to include bprint.h or avstring.h
for them. In order to avoid a repeat of this and in order to reduce
unnecessary dependencies, a forward declaration of struct AVBPrint is
used instead of including bprint.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in 40cf1bbacc.
(The currently disabled filter vf_mcdeint and vf_uspp were users of
this field; they have not been changed, so that whoever wants to fix
them can see the state of these filters when they were disabled.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These are auxiliary side-data functions, so they should have been
switched to size_t in d79e0fe65c,
but this has been forgotten.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
