Use of VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT instead of
specific VK_PIPELINE_STAGE_2_VIDEO_DECODE_BIT_KHR
Fix for VUID-vkCmdPipelineBarrier2-srcStageMask-03849
pDependencyInfo->pImageMemoryBarriers[0].srcStageMask
(VK_PIPELINE_STAGE_2_VIDEO_DECODE_BIT_KHR) is not compatible with
the queue family properties
(VK_QUEUE_GRAPHICS_BIT|VK_QUEUE_COMPUTE_BIT|VK_QUEUE_TRANSFER_BIT|
VK_QUEUE_SPARSE_BINDING_BIT|VK_QUEUE_PROTECTED_BIT) of this
command buffer. The Vulkan spec states: The srcStageMask member
of any element of the pMemoryBarriers, pBufferMemoryBarriers, or
pImageMemoryBarriers members of pDependencyInfo must only
include pipeline stages valid for the queue family that was
used to create the command pool that commandBuffer was allocated
from (
https://www.khronos.org/registry/vulkan/specs/1.3-extensions/
html/vkspec.html#VUID-vkCmdPipelineBarrier2-srcStageMask-03849)
The frame barrier should use a compatible srcStageMask for all
the queues.
Remove reset_pipeline_stage_mask as it is redundant
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6780>
Add pitch tests with different forward and backward playback rates.
Those tests depend on the libSoundTouch version to validate the buffers
checksums. The actual version uses libSoundTouch 2.3.2, use the
`--force-fallback-for=soundtouch` meson option to build using the same
version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6247>
- fully protect accesses to the libsoundtouch API that is not
thread-safe.
- fully protect accesses to GstPitch members that could be read by a
downstream query thread while written by an upstream streaming thread
or a user thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6247>
- use the `GST_PITCH_GET_PRIVATE` accessor when needed
- rename `out_seg_rate` to `output_rate` to use the same name as the parameter
- rename `seg_arate` to `segment_applied_rate` to improve readability
- apply gst-indent to gstpitch.hh/cc
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6247>
When changing playing rate, the output segment was not correctly
calculated because the stream time ratio was computed using the previous
input segment rate instead of using the actual rate. This was producing
wrong results for the output segment start and end values.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6247>
The h26xdecoder 'stop' method was not called
as the vulkan h26x class rewires the video decoder
'stop' base method to its own one.
It was causing some memory leaks such as dangling parser
and dpb in h26xdecoder base class.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6782>
Modifying the `avoid-reencoding` property of `encodebin` could potentially cause
it to reconfigure itself, in which case the source pad will be removed and then
re-added.
Therefore set that property *before* attempting to link to that pad.
Fixes smart-render
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6757>
when pipline is
glvideomixerelement->glcolorconvertelement->gldownloadelement and
glcolorconvertelement is not passthrough, the gl bufferpool between
glvideomixerelement and glcolorconvertelement will not add gl sync meta
during allocating buffer. This will cause that glcolorconvert's inbuf
has no sync meta to wait for.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6756>
1. The PTS of all frames should not be changed.
2. Just update the DTS based on the PTS. For the frame which is not
reordered, the DTS is equal to PTS. For frame which is reordered,
the DTS is equal to previous DTS. For example:
Input: F0[D0, P0] -- F1[D1, P1] -- F2[D2, P2] -- F3[D3, P3]
Output: F0[I, D0, P0] -- F3[P, D0, P3] -- F1[B, D1, P1] -- F2[B, D2, P2]
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6703>
1. The PTS of all frames should not be changed.
2. Just update the DTS based on the PTS. For the frame which is not
reordered, the DTS is equal to PTS. For frame which is reordered,
the DTS is equal to previous DTS. For example:
Input: F0[D0, P0] -- F1[D1, P1] -- F2[D2, P2] -- F3[D3, P3]
Output: F0[I, D0, P0] -- F3[P, D0, P3] -- F1[B, D1, P1] -- F2[B, D2, P2]
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6703>
Fixing deadlock in below case
* GC lock is taken by background thread, and the background thread calls
gst_d3d12_ipc_client_release_imported_data() which takes ipc lock
* ipc lock is already taken in ipc thread and trying to pushing GC data
via gst_d3d12_command_queue_set_notify()
* gst_d3d12_command_queue_set_notify() is trying to take GC lock
but it's already taken by background thread
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6749>
Ideally, GPU waiting should be scheduled just before executing command list.
But handling the case outside of converter is a bit complicated.
Under an assumption that constructed command list will be executed
immediately, schedules GPU-side waiting inside of conversion method
to simplify the flow.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6749>
Neither LIBDIR nor LIBPL are set with the native windows Python
(unlike MSYS2), so we need to use `prefix` which takes us to the
rootdir of the Python installation.
The name is also different: it's python312.dll, not python3.12.dll.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6734>
`python.get_variable('FOO', [])` becomes `python.get_variable('FOO')`
due to how Meson treats empty arrays in arguments, which breaks the
fallback feature of get_variable().
So we need to actually check whether the variable exists before trying
to fetch it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6734>
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>
First it derived mapping was disabled for P010 formats, but also there's an
issue with interlaced frames.
It would be possible to disable derived mapping only for interlaced (H.264
decoder and vadeinterlace) but it would spread the hacks along the code. It's
simpler and contained to disable derived completely for Mesa <23.3
Fixes: #3450
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6729>
Instead of duplicating the GStreamer format to DRM fourcc mapping, this patch
uses the GstVideo library helpers. This duplicates the big O of looking for,
since the two lists are traversed, but it's less error prone.
Partially reverts commit 547f3e8622.
Fixes: #3354
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6731>
The assertion that was present before is a bit too harsh, since there is now
a (understandable) use-case where this could happen.
In gapless use-case, with two files containing the same type (ex:audio). The
first one *does* expose a collection with an audio stream, but decoding
fails (for whatever reason).
That would cause us to have configured a audio combiner, which was never
used (i.e. not active).
Then the second file plays and we (wrongly) assume it should be activated
... whereas the combiner was indeed present.
Demote the assertion to a warning and properly handle it
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6737>
If waylandsink received buffer rate is high which causes frame
drop, the cached staged buffer will be replaced when next buffer
needs to be rendered and be freed after redraw. But there is
chance to get memory leak if ended without redraw. So need to
free staged buffer when do gst_wl_window_finalize().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6670>
`rsvg_handle_get_dimensions()` and `rsvg_handle_render_cairo()` are
deprecated, and the replacement librsvg functions as specified in the
migration guide are `rsvg_handle_get_intrinsic_size_in_pixels()` and
`rsvg_handle_render_document()`.
However, those are not drop-in replacements, and actually have
breaking semantics for our use-case:
1. `intrinsic_size_in_pixels()` requires SVGs to have width+height or
the viewBox attribute, but `get_dimensions()` does not. It will
calculate the geometry based on element extents recursively.
2. `render_cairo()` simply renders the SVG at its intrinsic size on
the specified surface starting at the top-left, maintaining
whatever transformations have been applied to the cairo surface,
including distorted aspect ratio.
However, `render_document()` does not do that, it is specifically
for rendering at the specified aspect ratio inside the specified
viewport, and if you specify a viewPort that does not match the
aspect ratio of the SVG, librsvg will center it.
Matching the old behaviour with the new APIs is a lot of work for no
benefit. We'd be duplicating code that is already there in librsvg in
one case and undoing work that librsvg is doing in the other case.
The aspect ratio handling in this element is also kinda atrocious.
There is no option to scale the SVG while maintaining the aspect
ratio. Overall, element needs a rewrite.
Let's just disable deprecations. The API is not going anywhere.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6726>
There was an issue with this equality check, which was to figure out what to do
with PCR pids (whether they were part of the streams present or not) and whether
we ignore PCR or not.
Turns out ... we already took care of that further up in the function.
The length check can be simplified by just checking whether the length of
the *original* PMT and the new PMT are identical. Since we don't store "magic"
PCR streams in those, we can just use them as-is.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6713>
Set as much information as possible on the slot (including the associated
track) *before* the associated source pad is added to the element.
We need this so that incoming event/queries can be replied to if they are
received when adding the pad
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6690>
An application that triggers a state transition from PLAYING to PAUSED
needs to acquire the LIVE_LOCK. Consequently the LIVE_LOCK must not be
taken while pushing anything on the pads because this operation might
get blocked by something that cannot be unblocked without the
application being able to proceed with the state transitions for other
elements in the pipeline. This commit extends the previous behaviour
where the live lock was released before pushing buffers (indirectly
through the unlock before subclass->create) to now also include
unlocking before pushing events.
The issue was discovered in a case for WebRTC where the application
tried to shut down a pipeline but an event originating from a video
source element (based on basesrc) was in the process of being pushed
down the pipeline when it got stuck on the STREAM_LOCK for the pad after
the rtpgccbwe element. This lock in turn was held by the rtcpgccbwe
element as it was in the process of pushing data down the pipeline but
was stuck on the blocking probes installed on dtlssrtpenc to prevent
data from flowing before dtls keys had been negotiated. What should have
happened here is that the blocking probes should be removed, but that
can only happen if the application may continue driving the state
transitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6671>
A DPB buffer held by codec picture object may not be writable
at the moment, then gst_buffer_make_writable() will unref passed buffer.
Specifically, the use after free or double free can happen if:
* Crop meta of buffer copy is required because of non-zero
top-left crop position
* zero-copy is possible with crop meta
* A picture was duplicated, interlaced h264 stream for example
Interlaced h264 stream with non-zero top-left crop position
is not very common but it's possible configuration in theory.
Thus gst_buffer_make_writable() should be called with
GstVideoCodecFrame.output_buffer directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6706>