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>
As of September 14 2012, v4l_enumstd() will return ENODATA
when a device's std field is set to 0. That is, the device
does not have a standard format. In order to properly
handle this case, v4l2_set_parameters should catch the
ENODATA code and break instead of failing.
Below is the v4l2-core commit describing this change.
>>commit a5338190efc7cfa8c99a6856342a77d21c9a05cf
>>Author: Hans Verkuil <hans.verkuil@cisco.com>
>>Date: Fri Sep 14 06:45:43 2012 -0300
>>
>> [media] v4l2-core: tvnorms may be 0 for a given input, handle that case
>>
>> Currently the core code looks at tvnorms to see whether ENUMSTD
>> or G_PARM should be enabled. This is not a good check for drivers
>> that support the STD API on one input and the DV Timings API on another.
>> In that case tvnorms may be 0.
>> Instead check whether s_std is present (for ENUMSTD) or whether g_std or
>> current_norm is present for g_parm.
>> Also, in the enumstd core function return ENODATA if tvnorms is 0,
>> because in that case the current input does not support the STD API
>> and ENUMSTD should return ENODATA for that.
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>> Reviewed-by: Sakari Ailus <sakari.ailus@iki.fi>
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Since v4l2 is compiled only on Linux where av_gettime_relative()
is monotonic, a small wrapper function av_gettime_monotonic() is used
(should be inlined the compiler) to put emphasis on that fact.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Setting the v4l2 device parameters may influence video properties
such as width, height and pixel format.
This patch moves v4l2_set_parameters to be executed before fetching
the video properties, avoiding errors such as (pal vs ntsc):
The v4l2 frame is 829440 bytes, but 691200 bytes are expected
Signed-off-by: Federico Simoncelli <fsimonce@redhat.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With some (buggy) drivers, the VIDIOC_G_STD ioctl returns a std_id that cannot
be matched with any of the enumerated v4l2_standard structures (for example
std_id = 0 or std_id = 0xffffff). Do not fail when we reach the end of the
enumeration without a valid match.
Fixes ticket #2370
Note: This commit message has been modified by Giorgio Vazzana, the original
commit message was:
"Fixed regression for mandatory VIDIOC_ENUMSTD support by v4l2"
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In particular, print the standard supported by the selected input.
Additionally, use PRIx64 everywhere when printing standards.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>