Always add GstTensorMeta to buffer instead of re-using existing GstTensorMeta
when it's already present. The reason for the change is when we have cascaded
inference elements overwriting (tflite) or leaking (ONNX) GstTensorMeta when we
have cascaded inferences. We didn't create and API to append to GstTensorMeta
and I think it's more convenient to have a new GstTensorMeta for each
inferences. It's also more clear that a group of tensor was produced by one
inference but doesn't limit tensordecoders from using tensors produced by
multiple inference. I don't see much value in having all tensors data always
inside one GstTensorMeta since appending would mean re-allocation of the tensors
array anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9564>
LCEVCdec supports different pixel aspect ratios other than 1/1. This change
forwards the pixel aspect ratio of the base picture to the LCEVC decoder,
and also updates the output pixel aspect ratio caps base on the one from the
enhanced frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9463>
The output resolution is not always twice as big as the input resultion divided
by the pixel aspect ratio. This is the case for LCEVC '0D' mode, where the
output resolution is the same as the input resolution, and the only enhancement
is the picture being clearer.
This patch uses LCEVC_PeekDecoder() after sending the LCEVC enhancement data to
know what the output resolution will be before allocating the output picture.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9463>
Even though the LCEVC decoder works fine without this, it is recommended to
set read access to base pictures that are sent to the decoder, and write access
to enhanced pictures that are received from the decoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9463>
.. in decoders.
Inline session parameters allows to not create session parameters handlers for
every new stream parameters (such as SPS and PPS for H.264, for example), but
instead to pass them as a chained structure in the decoding main structure. This
is completely align with GStreamer decoder base classes.
Even that the previous approach is kept, if the devices doesn't support video
maintenance2, it shows a lot of validation errors.
Also it was required to add another parameter when enabling extension to verify
if the extension is linked with a device feature and if it is enabled.
Bump Vulkan API (and driver version for both decoders and encoders) to 1.4.306
Also bumped the ABI_CHECK_TAG because the CI finally catches up with the vulkan
video symbols that are not exposed by a public header (tough they are binary
public).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9585>
Some extensions need to have enabled certain feature in the device. This patch
does that check by adding a new field in the extension list which is a function
that can be mapped to gst_vulkan_physical_device_has_feature_*() functions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9585>
See #2611
When transitioning to PLAYING we call IDeckLinkInput::StartStreams() (via GstDecklinkInput::start_streams). This can
fail for various reasons, including if the hardware device is already in use.
Previously, we logged StartStreams() failure as an element error but otherwise continued to successfully transition to
PLAYING. Now, if StartStreams() returns an error we fail the state change.
If StartStreams() fails then a subsequent call to StopStreams(), when transitioning PAUSED to READY, will also fail.
Previously, if StopStreams() failed then the state change also failed. Unfortunately this prevented the element from
later being disposed, which in turn meant the associated hardware resources was never freed. Consequently, if a
decklinkvideosrc failed to transition PAUSED to READY, then the associated hardware device could not subsequently be
used by any other decklinkvideosrc.
Now, we log an element error if StopStreams() fails but otherwise consider the state change to have succeeded. This
means that the element can be disposed and the associated hardware resource released.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9578>
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>
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>
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>
