If mpegtsmux receives the same caps again, it wrongly claims the stream
type changed:
error: Stream type change from 06 to 8f not supported
This adds a unit test that demonstrate the issue in the very hacky way.
I have seen this happening with the below pipeline when upstream caps
changes. Since the caps filter fixates the caps received by opusenc and
mpegtsmux, the stream type cannot change.
...
! audioconvert
! audio/x-raw,format=S16LE,channels=2,rate=48000
! opusenc bitrate=128000
! mpegtsmux
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9430>
The TsMuxStream internal_stream_type field stores the original
'full' stream type (such as Opus), while the stream_type field
stores the value that will actually be written into the MPEG-TS
packets according to the codec mappings. When checking if
input caps are changing stream type, check the original type.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9430>
In order to link videomaintenance1, and others to come, without knowing if
Vulkan 1.4 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 the future features to query which aren't part of a Vulkan release
yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
This patch is the payment to my technical debt.
The symbol GST_VULKAN_HAVE_VIDEO_EXTENSIONS is defined at compilation-time if
the user requests for the usage of the Vulkan Video extensions. And we used this
symbol for anything related with Vulkan Video. But this is not the smartest
approach.
The rule should be:
- If the code allocates Vulkan Video resources, use
GST_VULKAN_HAVE_VIDEO_EXTENSIONS
- Otherwise, use the Vulkan's guard for the used API
In this way, API version bumps will be easier.
Also, this commit marks the end of GST_VULKAN_HAVE_VIDEO_EXTENSIONS guarded code
for readability.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
Both gst_vulkan_image_buffer_pool_set_config() and
gst_vulkan_image_buffer_pool_alloc() functions share the same code to create
Vulkan images for different purposes.
This patch refactor them in a new helper function that creates the images and
stores them in a buffer if it's passed as output parameters, such as the
offsets.
This patch also adds specifics guards for Vulkan's symbols for better grained
API usage, but also for prepare_buffer() the guard is set where the symbol is
used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
The Vulkan Video extensions can be available, according to the specification,
since Vulkan 1.1, but with other extensions dependencies. That's why this patch
adds a field in the extension structure, which represents the extension
dependency that the specified extension requires. And they are specified by
Vulkan Video extensions.
This allow to have a single function to check if the extension can be enabled
both by optional extensions and video extensions.
Regardless that video extension can be loaded since Vulkan 1.1, they are rather
loaded since Vulkan 1.3, when synchronization2 was promoted, so it isn't
checked as video_queue dependency.
Finally, this patch checks for each guard symbol.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
This is a continuation of !9483, but without back-porting.
Instead of checking the driver's API version to figure out if a physical device
feature is available and enabled, or even more, instead of checking for enabled
extensions in the driver, this patch adds private functions in the physical
driver to get the availability and enabling of features such as sampler ycbrc
conversion, synchronization2, timeline semaphore and video maintenance1.
And these new functions are used internally in the GstVulkanOperation object,
and the private object GstVulkanDecoder.
This approach is computationally cheaper, simpler and precise.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9492>
plugin_init() will not get called if element/feature registration
happens manually, such as when using linking only specific plugin
features with gstreamer-full. That is possible when plugins contain
static features.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9496>
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>
