Since the sequence of IMMDeviceEnumerator::EnumAudioEndpoints()
followed by IMMDevice::Activate() is not atomic, Activate() may fail
if the enumerated device becomes invalidated before probing.
In such cases, retry device probing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9468>
For the features VkPhysicalDeviceSamplerYcbcrConversionFeaturesKHR,
VkPhysicalDeviceSynchronization2Features and
VkPhisicalDeviceTimelineSemaphoreFeatures
The Vulkan specification states:
If the `VkPhysicalDeviceXXXFeatures` structure is included in the `pNext`
chain of the `VkPhysicalDeviceFeatures2` structure passed to
`vkGetPhysicalDeviceFeatures2`, it is filled in to indicate whether each
corresponding feature is supported. If the application wishes to use a
`VkDevice` with any features described by `VkPhysicalDeviceXXXFeatures`,
it **must** add an instance of the structure, with the desired feature members
set to `VK_TRUE`, to the `pNext` chain of `VkDeviceCreateInfo` when creating
the `VkDevice`.
And that was missing in the code.
Strangely, that functionality doesn't have a Valid-Usage ID assigned, so it
isn't caught by the validation layer.
This patch adds the structures in the physical devices to get them and later set
them in the device creation.
In order to link these features, videomaintenance1, and others to come, without
knowing if Vulkan 1.3 features are chained in the device properties structure, a
static and inlined function was added in gstvkphysicaldevice-private.h. It was
added in a header file to avoid compiler warnings if it's not used because of
old Vulkan headers.
Also the value dump videomaintenance1 was moved to another function to pack
there all these queried features.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9483>
VA encoders, at reconfiguration, have to check if the rate-control was changed
by the user, but since user parameters setting are in another thread, the
comparison was racy.
This patch locks the object to compare the current rate-control with the one set
by the user.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9480>
Make it work a little more like RTP. Have the source interact with the
clock and set the capture time on each packet. Then the other elements
can use that to do adjustments. Since AVTP is always very low latency,
it can be assumed that the gPTP clock at the packet reception is very
close to the sending time, never more than 2 seconds off, so the
timestamps can be compared directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9412>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
When the base videodecoder class re-attempts a negotiation after flush, the
vabasedec `need_negotiation` flag isn't necessarily set to TRUE, because in that
situation the input state hasn't changed.
By always chaining up we are sure that buffer pool negotiation will always be
attempted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9457>
This is needed if the LCEVC enhancement data is part of the video stream as SEI
and the demuxer outputs 'lcevc=false' src caps because LCEVC enhancement data is
not stored as a separate stream in the container.
To clarify, 'lcevc=true' just means that the video buffers have LCEVC metadata
attached. Therefore, it is valid to have a stream with LCEVC enhancement data as
SEI with 'lcevc=false' as long as it is not attached as metadata.
This will be needed once we add support for the demuxer to attach LCEVC metadata
to video buffers if it is stored in a separate track.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9427>
