This causes no changes to the profile but keeps the existing settings.
The profile can also be changed from e.g. the card's configuration
application and in that case probably should be left alone.
The default is the new value as it keeps the profile setting as it is,
which is consistent with the previous behaviour in 1.18.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1721>
Updated Decklink SDK to version 11.2 in order to support newer cards like the Decklink 8K Pro.
This required to replace the duplex property by a profile property.
Profile values can be the following:
- bmdProfileOneSubDeviceFullDuplex
- bmdProfileOneSubDeviceHalfDuplex
- bmdProfileTwoSubDevicesFullDuplex
- bmdProfileTwoSubDevicesHalfDuplex
- bmdProfileFourSubDevicesHalfDuplex
Fixes#987
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1665>
False warning from MSVC, or it does not understand that
g_assert_not_reached() does not return.
...\gst-plugins-bad-1.0-1.17.0.1\sys\decklink\gstdecklink.cpp(1647) : warning C4715: 'gst_decklink_configure_duplex_mode': not all control paths return a value
Before this patch, if mode=auto and video-format!=auto, video-format would
always be ignored, and get set to 8bit-yuv, or if detected to be RGB444, then
it would be set to 8bit-argb. This change respects video-format if it is set
to 10bit-yuv (v210) or 8bit-bgra, even when mode=auto.
Closes#772
If the "output-cc" property is set to TRUE and there is CC present
in the VBI Ancillary Data, they will be extracted and set on the
outgoing buffer as GstVideoCaptionMeta.
Only CDP packets are supported.
https://bugzilla.gnome.org/show_bug.cgi?id=773863
There is no log of gst_decklink_com_thread () which initializes COM.
The initialization part is not valid with #ifdef MSC_VER.
Windows binaries are built with gcc.
As with other codes, it was avoidable by setting it to G_OS_WIN32
instead of MSC_VER.
https://bugzilla.gnome.org/show_bug.cgi?id=794652
There is no fixed limitation for the number of devices on the
decklink API side according to BlackMagic. Many PC motherboards
are able support 6 decklink cards each with up to 8 inputs so
a limit of 16 might well be too low.
https://bugzilla.gnome.org/show_bug.cgi?id=777239
The Decklink and GstAudioBaseSink APIs don't fit very well together,
which causes various problems due to inaccuracies in the clock
calculations and the actual ringbuffer and GStreamer's copy getting of
sync.
Problems are audio drop-outs and A/V sync getting wrong after
pausing/seeking.
https://bugzilla.gnome.org/show_bug.cgi?id=790114
The buffer itself is 128 bytes into the allocated memory area, to be
able to store the size and other metadata before it. Freeing the buffer
directly will make malloc moderately unhappy.
HRESULT is unsigned long on Windows, but the Decklink headers define
it to 'int' on Linux. Confusingly, the defines that talk about the
possible return values for it use long constants. The easy fix would
be to change the linux/LinuxCOM.h header, but that's copied from the
decklink SDK.
Change the logging to always upcast to unsigned long while printing
HRESULT for consistency across platforms.
The default memory allocator of the decklink library allocates
a fixed pool of buffers, and the number of buffers is unknown.
This makes it impossible do useful queuing downstream. The new
memory allocator can create an unlimited number of buffers,
giving all queuing features one would expect from a live source.
https://bugzilla.gnome.org/show_bug.cgi?id=782556
The audio packet times can be completely unrelated to the video stream
time, depending on the card. While this looks like a bug in the driver,
just always using the video stream time (which is correct) works as a
workaround for now.
This reverts commit 845832263b.
The commit broke cross-mingw CI:
https://ci.gstreamer.net/job/GStreamer-master/8659/console
It seems that cross-mingw on Autotools and native-mingw on Meson
disagree about the size of HRESULT. Revert for now till I can
investigate the Meson side of things some more.
