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>
Also disable it by default since it looks currently buggy. The
usefulness of such library is mostly limited to backward compatibility
with very old devices.