Fixes#7312, segmentation fault on close of X11 server
xcb_query_pointer_reply() and xcb_get_geometry_reply() can return NULL
if e.g. the X server closes or the connection is lost. This needs to
be checked in order to cleanly exit, because the returned pointers are
dereferenced later.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
X2RGB10 tested on both Intel Gen9 and AMD Polaris 11. NV12 tested on
Intel Gen9 only - since it has multiple planes, this requires GetFB2.
Also add some comments to split the list up a bit.
The most useful feature here is the ability to automatically extract the
framebuffer format and modifiers. It also makes support for multi-plane
framebuffers possible, though none are added to the format table in this
patch.
This requires libdrm 2.4.101 (from April 2020) to build, so it includes a
configure check to allow compatibility with existing distributions. Even
with libdrm support, it still won't do anything at runtime if you are
running Linux < 5.7 (before June 2020).
Apparently the changes from 3c9185bf3a
aren't enough; even with that in place, I got errors like this
when trying to build for iOS:
src/libavdevice/avfoundation.m:135:5: error:
'AVCaptureDeviceTransportControlsPlaybackMode' is unavailable: not
available on iOS
AVCaptureDeviceTransportControlsPlaybackMode observed_mode;
^
The capture_started variable was never set, it is simpler to call the stop
functions unconditionally if the interface is available.
Signed-off-by: Marton Balint <cus@passwd.hu>
Also by wrapping the SHM buffer in an AVBufferRef we eliminate yet another
possible memcpy improving performance.
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
missed the category AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT lead to
ffmpeg -devices doesn't show gdigrab as a input device
FIx#7848
Found-by: dangibson
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Apparently in the new SDK one cannot query if VANC output is supported, so we
will fall back to non-VANC output if enabling the video output with VANC fails.
Fixes ticket #7867.
Signed-off-by: Marton Balint <cus@passwd.hu>
Moritz Barsnick
Mark Thompson
Limin Wang
Milos Zivkovic
Thilo Borgmann
Michael Niedermayer
David Manouchehri
Martin Storsjö
Marton Balint
Paul B Mahol
Nicolas George
Carl Eugen Hoyos
Kusanagi Kouichi
Zhao Zhili
Gyan Doshi
Andriy Gelman
Jun Zhao
Stephan Hilb