With video_maintenance1 extension is possible to create images independent of a
the video profile list, under that image will be processed.
With that extension is possible to share the same image for dynamic transcoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9550>
Change the logic to skip only devices which have "Input" as their IOID. The ALSA
Input/Output identifier (IOID) it may be either "Input", "Output", or NULL; with
the latter meaning that the device supports both input and output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9534>
This was broken in b29262e662b86cd76225894f7504ee505125fa49.
The `gst_util_uint64_scale` emitted a critical warning and returned
`GST_CLOCK_TIME_NONE`, so beyond removing the warning this fix does not
change behavior.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9415>
The validation complained with
VUID-VkImageCreateInfo-usage-requiredbitmask]:
vkCreateImage(): pCreateInfo->usage is zero.
This patch force to use the internal defaults in vkimagebufferpool if no usage
is defined.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9544>
With merge request !9438 the validation layer started to complain with
VUID-VkDeviceCreateInfo-pNext-02829
This patch fixes this ill-usage of Vulkan API, by removing the feature enabling
of sampler ycbcr conversion, since it was promoted since Vulkan 1.1, and in
GStreamer is only used in Vulkan Video operations, which are only enabled in
Vulkan 1.3+.
Also, these features detection and enabling were moved to a function called when
filling the physical device data, in order to check the API version of the
device driver before adding the enabling of the feature.
Finally, the getters were adapted to use the version feature structure if the
device driver version matches.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9544>
Pushing the buffer via gst_pad_push () in transform_ip () function
causes downstream elements to process the buffer with a reference
count > 1. This leads to performance issue if there are downstream
elements which modify the buffer memory.
However, in drop-only mode this reference is not required.
So, let GstBaseTransform push the buffer in drop-only mode.
Fixes#4258
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9532>
Don't reuse the same offset and size variables when reading
the byterange out of a MAP directive, as it can overwrite
values from a pending BYTERANGE directive for the next
fragment URI.
Fixes problems where the EXT-X-MAP directive has been written
into the playlist between an EXT-X-BYTERANGE and the fragment
URI it applies to.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9533>
Don't reuse the same offset and size variables when reading
the byterange out of a MAP directive, as it can overwrite
values from a pending BYTERANGE directive for the next
fragment URI.
Fixes problems where the EXT-X-MAP directive has been written
into the playlist between an EXT-X-BYTERANGE and the fragment
URI it applies to.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9533>
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>
