Now when the buffered list is requested, the tolerance for merging two ranges
when there's a small gap between them is MAX(0.1sec, max frame duration * 2).
Previously it was hardcoded to 0.01sec. The specification suggests that it
could be something like the max frame duration * 2.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Both operations now work on coded frame groups (GOPs). This simplifies queueing
of video data. There is rarely any point of dealing with individual video frames
when iterating in DTS order, it's most meaningful to decode or delete whole
coded frame groups at a time, so the sample map will now do that when iterating
by DTS. When iterating in PTS order, the existing behavior is preserved since
that is used for informational purposes, not media processing.
A new private boxed type for coded frame groups was added to provide each data
item to the source buffer. Another possible solution would be creation of a new
GstSample representing the whole group by merging all the samples in a group
into a single sample containing a GstBufferList.
Also, start time filtering was removed from the API since gst_iterator_filter()
can be used by callers to achieve the same result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
If the vulkan plugin was compiled against a newer version than the supported
vulkan runtime instance or device, then it was possible for format retrieval to
fail. Failure was due to unconditionally using newer extensions and features
without runtime checking them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
The API version exposed by a particular device can be completely different from
what is exported by the parent instance. Since Vulkan 1.1 it is also possible
to use newer device API than supported by the instance API version (with the
appropriate version checks).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
It creates a new structure for passing the codec quality structure at _start(),
where it will be filled. The quality level can be set or changed according
encoder limits.
Later the quality level will be set at _update_session_parameters() and at each
frame encoding. That's why it has to be set at _start().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
The algorithm for generating the current slot index is a simple round robin,
nonetheless it's not assured that the next slot index it's not still used by a
still living encode picture.
This new way holds an array with the still living encode pictures and the next
slot index looks for a released index in the array.
Its downside is deallocating a picture need to be removed from the array, so the
helper has to be passed to the uninit() function
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
In GStreamer that buffer information is decoupled, holding other structures to
describe the stream: GstCaps. So, to keep the GStreamer design this patch
removes these information from GstVulkanEncoderPicture and pass to
gst_vulkan_encoder_encode() a pointer to GstVideoInfo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
That's the number of references that gst_vulkan_encoder_encode() receives to
process, so it has to go as a parameter, because it's part of the reference
list, not of the picture.
This commit also modified unit tests accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
The structure already stored the generic video capabilities and the specific
codec capabilities both for encoding an decoding. The generic decoder
capabilities weren't stored because it was only used internally in the decoder
helper object. Nonetheless, for the encoder, the elements will need the generic
encoder capabilities to configure the encoding. That's why it's required to
expose it as part of GstVulkanVideoCapabilities. And the generic decoder is
included for the sake of symmetry.
While updating the API vkvideoencodeh265 test got some code-style fixes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8007>
fix playback fail, when some file with length_size_minus_one == 2
According to the spec 2 cannot be a valid value, so that stream has a
bad config record. but breaking the decoding because of that, perhaps is too much.
and ffmpeg seem not check this
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7213>
Instead of dragging the last destination pipeline stage as current barrier
source pipeline stage (which isn't a valid semantic) this patch adds a parameter
to gst_vulkan_operation_add_frame_barrier() to set the source pipeline stage to
define the barrier.
The previous logic brought problems particularly with queue transfers, when the
new queue doesn't support the stage set during a previous operation in a
different queue.
Now the operation API is closer to Vulkan semantics.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7165>
From the spec (chapter 34, v1.3.283):
````
UNORM: the components are unsigned normalized values in the range [0, 1]
SRGB: the R, G and B components are unsigned normalized value that represent
values using sRGB nonlinear encoding, while the A component (if one
exists) is a regular unsigned normalized value
```
The difference is the storage encoding, the first one is aimed for image
transfers, while the second is for shaders, mostly in the swapchain stage in the
pipeline, and it's done automatically if needed [1].
As far as I have checked, other frameworks (FFmpeg, GTK+), when import or export
images from/to Vulkan, use exclusively UNORM formats, while SRGB formats are
ignored.
My conclusion is that Vulkan formats are related on how bits are stored in
memory rather their transfer functions (colorimetry).
This patch does two interrelated changes:
1. It swaps certain color format maps to try first, in both
gst_vulkan_format_from_video_info() and gst_vulkan_format_from_video_info_2(),
the UNORM formats, when comparing its usage, and later check for SRGB.
2. It removes the code that check for colorimetry in
gst_vulkan_format_from_video_info_2(), since it not storage related.
1. https://community.khronos.org/t/noob-difference-between-unorm-and-srgb/106132/7
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6797>
This reverts commit 926d5366b99b3498632a45147cfa329dbbf2cc30.
AcquireSRWLockExclusive seems to be acquiring lock in exclusive mode
when the same lock is combined with write lock access.
Reverting the commit because of this is unexpected behavior
and unavoidable OS bug.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6904>
Since we don't want to expose video decoding API outside of GStreamer, the
header is removed from installation and both source files are renamed as
-private.
The header must remain in gst-libs because is referred by GstVulkanQueue,
which's the decoder factory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6723>
