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>
There is a calculation error in xcbgrab_reposition() that breaks
vertical repositioning on follow_mouse. It made the bottom
reposition occur when moving the mouse lower than N pixels after
the capture bottom edge, instead of before.
This commit fixes the calculation to match the documentation.
follow_mouse: centered or number of pixels. The documentation says:
When it is specified with "centered", the grabbing region follows
the mouse pointer and keeps the pointer at the center of region;
otherwise, the region follows only when the mouse pointer reaches
within PIXELS (greater than zero) to the edge of region.
In Windows if using scaling other than 100% then the grabbed window was not captured fully (cropped)
Signed-off-by: Dilshod Mukhtarov <dilshodm@gmail.com>
Allows arrangement of multiple windows such as:
ffmpeg -re -f lavfi -i mandelbrot -f sdl -window_x 1 -window_y 1 mandelbrot -vf waveform,format=yuv420p -f sdl -window_x 641 -window_y 1 waveform -vf vectorscope,format=yuv420p -f sdl -window_x 1 -window_y 481 vectorscop
Some changes by Marton Balint:
- allow negative position (partially or fully out-of-screen positions seem to
be sanitized automatically by SDL (or my WM?), so no special handling is
needed)
- only show window after the position is set
- do not use resizable and borderless flags at the same time, that caused
issues in ffplay
- add docs
Signed-off-by: Marton Balint <cus@passwd.hu>
Make the function static, or else Clang complains with:
error: no previous prototype for function 'decklink_get_attr_string' [-Werror,-Wmissing-prototypes]
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This option is useful for maintaining input synchronization across N
different hardware devices deployed for 'N-way' redundancy.
The system time of different hardware devices should be synchronized
with protocols such as NTP or PTP, before using this option.
Signed-off-by: Marton Balint <cus@passwd.hu>
Also bump the API version requirement to 10.9.5, because on olders versions
there were some reports of crashes using the undocumented, yet available
BMDDeckLinkDeviceHandle.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes ticket #5654.
The linesize can be greater than the minimum required. This copies the
frame taking linesize into account.
Signed-off-by: Rick Kern <kernrj@gmail.com>
Hook in libklvanc and use it for output of EIA-708 captions over
SDI. The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.
Libklvanc can be found at: https://github.com/stoth68000/libklvanc
Updated to reflect feedback from Marton Balint <cus@passwd.hu>,
Carl Eugen Hoyos <ceffmpeg@gmail.com>, Aaron Levinson
<alevinsn_dev@levland.net>, and Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
If the user provides a valid timecode_format look for timecode of that
format in the capture and if found store it on the video avstream's
metadata.
Slightly modified by Marton Balint to capture per-frame timecode as well.
Signed-off-by: Marton Balint <cus@passwd.hu>
The default memory allocator is limited in the max number of frames available,
and therefore caused frame drops if the frames were not freed fast enough.
Signed-off-by: Marton Balint <cus@passwd.hu>
Formats ARGB32, XRGB32, ABGR32, and XBGR32 were added to V4L2 instead
of ill-defined deprecated RGB32/BGR32 pixel formats.
When pixel format is not specified explicitly FFmpeg tries formats in
order in which they are stored in the table. Therefore formats are
sorted as follows: BGR is preferred over RGB and XBGR is preferred
over ARGB, because it could give better performance by ignoring alpha
component.
Create a buffer from the data instead and use the buffer destructor to free the
DeckLink frame. This avoids a memcpy of the frame data.
Signed-off-by: Marton Balint <cus@passwd.hu>
Show a more useful error message which specifies the required driver version
for the build, and use the correct context in the error message for WIN32.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes the following warnings:
libavdevice/vfwcap.c:331:35: warning: passing argument 1 of 'av_parse_video_size' from incompatible pointer type
libavdevice/vfwcap.c:331:59: warning: passing argument 2 of 'av_parse_video_size' from incompatible pointer type
Reported-by: Reino Wijnsma
avdevice_register_all() is still required to register devices into
lavf (this is required due to lavd being somewhat of a hack).
Signed-off-by: Josh de Kock <josh@itanimul.li>
This reverts commit 0fd475704e.
Revert "lavd: fix iterating of input and output devices"
This reverts commit ce1d77a5e7.
Signed-off-by: Josh de Kock <josh@itanimul.li>
In the previous implementation the first input or output device
was skipped when device_next was called with prev = NULL
Signed-off-by: Felix Matouschek <felix@matouschek.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds an indev for Android devices on API level 24+ which
uses the Android NDK Camera2 API to capture video from builtin cameras
Signed-off-by: Felix Matouschek <felix@matouschek.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This changes how NTSC VANC is extracted from the buffer. In NTSC the vanc data
is interleaved between luma and chroma, and not just the luma as in high
definition resolutions.
In my testing this allows a decklink card encoding valid NTSC closed
captions to pass the caption data to the x264 encoder.
Updated with reviews from Devin Heitmueller and Marton Balint.
Signed-off-by: Ray Tiley <raytiley@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
avcodec bump missed in 7e8eba2d87
avformat bump missed in ff46124b0d and
0694d87024
avdevice bump missed in 0fd475704e
Signed-off-by: James Almer <jamrial@gmail.com>
Clang applies the missing-prototypes warning on C++ files, whereas
gcc only applies it to C. As a result, the decklink_common.cpp file
fails to build because of missing prototypes in DecklinkDispatch.cpp
(which is #included by decklink_common.cpp).
We don't want to change the actual Blackmagic SDK sources, so
suppress the warning just for that one #include.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
When building with Clang, the following warning is shown:
warning: struct 'IDeckLinkVideoFrame' was previously declared as a
class [-Wmismatched-tags]
The function incorrectly casts IDeckLinkVideoFrame as a struct
instead of a class pointer.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes the following warnings:
libavdevice/lavfi.c:136:16: warning: assignment discards 'const' qualifier from pointer target type
libavdevice/lavfi.c:137:17: warning: assignment discards 'const' qualifier from pointer target type
* commit '07a2b155949eb267cdfc7805f42c7b3375f9c7c5':
Bump major versions of all libraries
A few API deprecated ~2 years ago or more are also postponed here for
varying reasons.
FF_API_LOWRES:
Since this functionality depends on AVStream->codec, i figure the two can
be removed at the same time in the next bump or so.
FF_API_AVCTX_TIMEBASE:
Couldn't get this one to work. Not just libavcodec but apparently also
libavformat and ffmpeg.c expect AVCodecContext->time_base to be set for
decoding. Upon removal some tests report a different generic stream time
base (like 1/25), and others lose packet duration values. I guess it's
somehow tied to the AVStream->codec clusterfuck.
It can be dealt with alongside FF_API_LAVF_AVCTX in the next bump.
FF_API_OLD_FILTER_OPTS_ERROR:
This one is meant to remain after FF_API_OLD_FILTER_OPTS is removed.
Its purpose is displaying the corrected command line using the new syntax
as a suggestion as part of the error message.
Merged-by: James Almer <jamrial@gmail.com>
Can be tested via the following command:
./ffmpeg -i foo.ts -f decklink -vcodec v210 'DeckLink Duo (1)'
Note that the 8-bit support works as it did before, and setting
the pix_fmt isn't required for 10-bit mode. The code defaults to
operating in 8-bit mode when no vcodec is specified, for backward
compatibility.
Updated to reflect feedback from Marton Balint <cus@passwd.hu>
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
