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>
Add support for enumerating the sources/sinks via the ffmpeg
command line options, as opposed to having to create a real pipeline
and use the "-list_devices" option which does exit() after dumping
out the options.
Note that this patch preserves the existing "-list_devices" option,
but now shares common code for the actual enumeration.
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>
The string is allocated with CFStringGetCString but was being
deallocated with free(), which would intermittently result in
a segmentation fault. Use the correct function for freeing the
allocated CFString.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
In preparation to make VANC decode modular, to support multiple other VANC data.
Signed-off-by: Karthick J <kjeyapal@akamai.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
The decklink input pixel format can now be specified with the 'raw_format'
option. The -bm_v210 option is now deprecated.
Signed-off-by: Marton Balint <cus@passwd.hu>
Support for this device has been removed in kernel since v2.6.37. dv1394 has been superseded by libiec61883 which is functionally equivalent.
Signed-off-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
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>
All DRM formats are defined in terms of little-endian words, so RGB formats
like XRGB actually have the elements in the opposite order order in memory
to the order they are in the name.
This does not affect YUYV and similar YUV 4:2:2 formats, which are in the
expected order.
DRM_FORMAT_R8 was added in libdrm 2.4.68.
DRM_FORMAT_R16 was added in libdrm 2.4.82.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
