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.
* commit 'f890677d05bc4e8b494a73373ab4cc19791bf884':
Replace any remaining avpicture function with imgutils
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '01bcc2d5c23fa757d163530abb396fd02f1be7c8':
lavc: Drop deprecated destruct_packet related functions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
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>
* commit '619d5e7db88941cadb8136f805564e885c6c6434':
v4l2: Use the codec descriptor facility
Conflicts:
libavdevice/v4l2.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
