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.
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>
Before this commit an av_assert0 would fail if a v4l2 device did not
support a target format.
For example,
./ffmpeg -f v4l2 -codec:v h264 -i /dev/video0 -f mpegts -
would signal an abort if /dev/video0 did not support h264.
The new behaviour is to return an AVERROR(EINVAL) error code. An
av_assert0 has been added to verify this return.
Fixes#6629
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Behave like we do for V4L2_BUF_FLAG_ERROR, implemented in commit 28f20d2ff4 .
For some devices (probably also related to the V4L driver implementation)
it happens that when invoking the ioctl DQBUF, the returned buffer is not
of the expected size. Here are two examples for such occurrences:
[video4linux2,v4l2 @ 0x258b440] Dequeued v4l2 buffer contains 609596 bytes, but 614400 were expected. Flags: 0x00000001.
/dev/video1: Invalid data found when processing input
[video4linux2,v4l2 @ 0x225f440] Dequeued v4l2 buffer contains 609508 bytes, but 614400 were expected. Flags: 0x00000001.
/dev/video1: Invalid data found when processing input
For the ffmpeg CLI tool this means it will stop capturing and exit.
The described behaviour was observed at least with one OmniVision USB
web cam and with some stk1160 devices.
If you search the web for the error message, you will find quite a few
instances of this problem. Some of them experienced on other devices.
Probably fixes ticket #4795
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
In case we are short of queued buffers, at first v4l2_buffer was enqueued to kernel so it's not owned by
user-space anymore. After that it's timestamp field was read, but it might be overwritten by driver at
that moment. It resulted in invalid timestamp sometimes.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Not all v4l2 devices implement the VIDIOC_G_PARM ioctl. This patch allow
ffmpeg to open such device and treat it the same as devices that do
implement the ioctl but returns that it do not implement the
V4L2_CAP_TIMEPERFRAME capability.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Benoit Fouet <benoit.fouet@free.fr>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
We now use 'pixelformat' for V4L2_PIX_FMT_* (as they do in v4l2
documentation) and 'pix_fmt' for AVPixelFormat.
No functional change in the code.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
No need to keep the old symbols around until a major bump since lavd functions
with the avpriv_ prefix were never exposed.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Additionally, make sure a buffer gets enqueued again (even in error paths) after
it has been succesfully dequeued.
Tested-by: Dmitry Volyntsev <xeioexception@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Anton Khirnov
Andreas Rheinhardt
James Almer
Andriy Gelman
Stephan Hilb
Carl Eugen Hoyos
Marton Balint
Jaroslav Beran
Carl Eugen Hoyos
Vittorio Giovara
Niklas Söderlund
Diego Biurrun
Timothy Gu
Luca Barbato
Clément Bœsch
Michael Niedermayer
Giorgio Vazzana
Andreas Cadhalpun
Lukasz Marek
Martin Storsjö
Tristan Matthews
Andrey Utkin