Add a missing dependency to wl_client_dep for the wayland build. Some distros
have the wayland-client headers not installed in /usr/include (which is perfectly
valid, the pkg-config .pc file gives the right feedback).
Instead of synchronising at the ICE transport, do clock sync for the
RTP stream at the DTLS transport via the dtlssrtpenc rtp-sync
property. This avoids delaying RTCP while waiting until it is time
to output an RTP packet when rtcp-mux is enabled.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1212
Posting any message to parent seems to be pointless. That might break
parent window.
Regardless of the posting, parent window can catch mouse event
and also any keyboard events will be handled by parent window by default.
It's currently the only sane way we can use MoltenVK functions to
integrate with Metal API.
It also removes the need to specify the VK_ICD_FILENAMES environment
variable pointing to MoltenVK_icd.json.
Includes a new GstVulkanHandlePool base class for pooling different
resources togther. The descriptor cache object is ported to
GstVulkanHandlePool with the exact same functionality.
A new GstVulkanFenceCache is also implemented for caching fences
which is used internally by GstVulkanDevice for creating or reusing
fences.
The existing GstVulkanTrashFenceList object now caches trash objects.
Part 1 is a base class (vkvideofilter) that handles instance, device,
queue retrieval and holding that has been moved to the library
Part 2 is a fullscreenrenderquad that is still in the plugin that
performs all of the previous vulkan-specific functionality.
Weak refs don't quite work here correctly as there is always a race with
taking the lock between find_view() and remove_view(). If find_view()
returns a view that is going to removed by remove_view() then we have an
interesting situation.
In theory, the number and type of views for an image are relatively
constant and should not change one they've been set up which means that
it is actually practical to perform pool-like reference counting here
where the image holds a pool of different views that it can give out
as necessary.
It broke after removal of usage of GTimeVal that was deprecated,
it requires seconds in this unix-based creation instead of microseconds.
The downside here is that it will create an extra object just to be
discarded in order to add the microsecond part to it.
It would end up segfaulting as it would return a NULL value
Exposure mode property, extra colour tone values (aqua, emboss, sketch, neon), extra scene modes (backlight, flowers, AR, HDR).
Missing vmethods for exposure mode, analog gain, lens focus, colour temperature, min & max exposure time
Contribs by Mohammed Sameer <msameer@foolab.org>, Adam Pigg <adam@piggz.co.uk>
The symbol visibility=hidden flag was only being applied to C
compilation, so plugins implemented in C++ would leak extra symbols
than the 2 _get_desc() and _register().
That also showed that the gst-libs opencv C++ lib was not marking
symbols for export correctly because the BUILDING_GST_OPENCV define
wasn't in the C++ args, so fix that too.
The major functionality gain this provides is proper reference counting
for a descriptor set. Overall this allows us to create descriptor sets
when they are needed (or reused from a cache) without violating any of
vulkan's object synchronisation requirements.
As there are a fixed number of sets available in a pool, the number of
descriptors in elements is currently hardcoded to 32. This can be extended
in a future change to create pools on the fly if that limit is ever overrun.
Allows a cleaner control flow when there is no fence available for use
with the trash list. An always signalled fence type will always return
TRUE for gst_vulkan_fence_is_signalled.
Serve two purposes:
1. refcounting of vulkan handles with associated destruction. When
combined with the trash list, the user can ensure destruction at
the correct time according to the vulkan rules.
2. avoids polluting our API with 32-bit vs 64-bit integer/pointers
differences as exposed through the vulkan API. on 32-bit, vulkan
non-dispatchable handles are 64-bit integers and on 64-bit, they
are pointers.
