This is a fix for a data race leading to:
> GLib-CRITICAL: g_hash_table_foreach:
> assertion 'version == hash_table->version' failed
Identified sequence:
* `rtp_session_on_timeout` acquires the lock on `session` and proceeds with its
processing.
* `rtp_session_process_rtcp` is called (debug log : received RTCP packet) and
attempts to acquire the lock on `session`, which is still held by
`rtp_session_on_timeout`.
* as part of an hash table iterator, `rtp_session_on_timeout` transitively
invokes `source_caps` which releases the lock on `session` so as to call
`session->callbacks.caps`.
* Since `rtp_session_process_rtcp` was waiting for the lock to be released, it
succeeds in acquiring it and proceeds with `rtp_session_process_rr` which
transitively calls `g_hash_table_insert` via `add_source`.
* After `source_caps` re-acquires the lock and gives the control flow back to
`rtp_session_on_timeout`, the hash table iterator is changed, resulting in the
assertion failure.
This commits copies `sess->ssrcs[sess->mask_idx]` and iterates on the copy so
the iterator is not affected by a concurrent change due to the lock being
released in the `source_caps` callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4585>
On very quick start/stop, the mainloop may never be run. As a side
effect, our idle stop function is not really being ran, so we can't rely
on that to free the main loop. Simply unref the mainloop when the
thread have completely stop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4539>
If we don't do that, clients can rely on this signal to see the final pad
topology but it won't be the real one as some of them will disappear after
emitting that signal. This can happen after injecting a different init segment.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4557>
Since c2f890ab, element properties are gathered from the parse-launch
line and passed at object construction.
This caused the following issue to happen in videoflip:
* videoflip installed a CONSTRUCT property named method, now deprecated
* videoflip now also overrides that property with a video-direction
property
GObject construction causes method to be set first at construct time,
with the user-provided value, then video-direction with the default
value.
The user-provided value was thus overridden, causing a regression.
Fix by not installing the properties as CONSTRUCT, and explicitly
implementing constructed() instead in order to ensure that we do still
call gst_video_flip_set_method() at least once during construction.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2529
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4551>
A blocking pad probe is added on new sink pads, it's usually removed after the
caps have been negotiated or the signaling state switched to stable, but if that
never happens and the pad is released we kept the pad probe active, leaving the
pad blocked, preventing clean disposal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4533>
While testing the [implementation for insertable streams] in `webrtcsink` &
`webrtcsrc`, I encountered critical warnings, which turned out to result from
two race conditions in `rtpsession`. Both race conditions produce:
> GLib-CRITICAL: g_hash_table_foreach:
> assertion 'version == hash_table->version' failed
This commit fixes one of the race conditions observed.
In its simplest form, the test consists in 2 pipelines and a Signalling server:
* pipelines_sink: audiotestsrc ! webrtcsink
* pipelines_src: webrtcsrc ! appsrc
1. Set `pipelines_sink` to `Playing`.
2. The Signalling server delivers the `producer_id`.
3. Initialize `pipelines_src` to establish a session with `producer_id`.
4. Set `pipelines_src` to `Playing`.
5. Wait for a buffer to be received by the `appsrc`.
6. Set `pipelines_src` to `Null`.
7. Set `pipelines_sink` to `Null`.
The race condition happens in the following sequence:
* `webrtcsink` runs a task to periodically retrieve statistics from `webrtcbin`.
This transitively ends up executing `rtp_session_create_stats`.
* `pipelines_sink` is set to `Null`.
* In `Paused` to `Ready`, `gst_rtp_session_change_state()` calls
`rtp_session_reset()`.
* The assertion failure occurs when `rtp_session_reset` is called while
`rtp_session_create_stats` is executing.
This is because `rtp_session_create_stats` acquires the lock on `session` prior
to calling `g_hash_table_foreach`, but `rtp_session_reset` doesn't acquire the
lock before calling `g_hash_table_remove_all`.
Acquiring the lock in `rtp_session_reset` fixes the issue.
[implementing insertable streams support]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1176
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4532>
Unfortunately streamoff does not flush the events, and this can cause all
sort of issues. Flush events on capture queue. We also return
GST_V4L2_FLOW_RESOLUTION_CHANGE in case a resolution change was seen.
This allow skipping streamon(capture) on flush, which could lead to a
configuration miss-match, or failure if the buffers aren't of the right
size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
Let the driver detects the change and reconfigure the capture side
transparently from there. This avoid reallocation of the output buffers,
and eliminates the need to stop and restart the capture task. This is
only happening if the driver have support for this, otherwise the old
behaviour is maintained.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
Stop doing capture buffer allocation based on guesses
and wait for the source change event when available.
Unlike stateless decoder, the stateful decoder is not aware of
the coded resolution, and this may lead to the wrong result
even when using TRY_FMT.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
In previous implementation that job was split between handle_frame and
the processing loop and it wasn't clear if this mechanism was race
free. The capture setup would also be tried for every buffer, which was
not necessary.
This also simplify the handling of SRC_CH event, dropping the unneeded
atomic boolean.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4525>
This reverts commit f29c19be58. If this is
called for the reference context then we would run into an infinite
loop, which is not really better than an assertion.
By fixing up DTS to never be ahead of the PTS in the previous commit
this situation should be impossible to hit now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4515>
decodebin3 will do its best to figure out whether a parsebin is required to
process the incoming stream.
The problem is that for push-based stream it could happen that the stream would
not provide any caps, resulting in nothing being linked internally.
Furthermore, there is the possibility that a stream *with* caps would not be
using a TIME segment, which is required for multiqueue to properly work.
In order to fix those two issues, we force the usage of parsebin on push-based
streams:
* When the pad is linked, if upstream can't provide any caps
* When we get a non-TIME segment
Fixes#2521
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4499>
On MacOS with homebrew, the openssl library is not
properly detected with pkg-config.
So disable the test compilation if openssl
is not properly detected along with libcrypto.
libcrypto is detected but it uses the system one
which leads to the error:
your binary is not an allowed client of /usr/lib/libcrypto.dylib for
architecture x86_64
See more details from Apple:
https://developer.apple.com/forums/thread/124782
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4483>
The addresses we get from `resolve_host_finish()` (via
`resolve_host_async()`, `resolve_host_main_cb()`, `on_resolve_host()`,
`g_resolver_lookup_by_name_finish()`) must be freed. Otherwise we leak
memory.
Leak found and confirmed fixed with GCC AddressSanitizer.
Change-Id: If32d24452d626234f01b253b77a7d6d16eac1cee
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4482>
The decoder needs to force another enumeration of the format. For
this it was clearing the v4l2object insternal list, leaving a fmtdesc
pointer pointing to freed memory. This patch clears the fmtdesc pointer
that has just been free. It also makes sure the probe function does not
use the cached formats list. The probe function will restore the current
fmtdesc pointer based on the currently configured pixelformat.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4426>
As we don't have anything smart in the fixation process, we may endup with
a format that has a lower bitdepth, even if downstream can handle higher
depth. it is notably the case when negotiating with deinterlace, which places
is non-passthrough caps before its passthrough one. This makes the generic
fixation prefer the formats natively supported by deinterlace element over
the HW 10bit format. As some HW can downscale 10bit to 8bit, this can break
10bit decoding.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4426>
The original code was:
if (!gst_structure_get (s, "srtp-key", GST_TYPE_BUFFER, &buf, NULL) || !buf) {
goto error;
} else {
stream->key = buf;
}
So use "srtp-key" if it is set so a non NULL buffer. The condition was
incorrectly inverted in ad7ffe64a6 to:
if (gst_structure_get (s, "srtp-key", GST_TYPE_BUFFER, &buf, NULL) || !buf) {
stream->key = buf;
} ...
Fix the condition so it works as originally intended and avoid accessing
'buf' uninitialised.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4423>
One race condition is the fact that the window object
can be destroyed while running some routine in the UI
thread (such as resizing). To avoid that situation we make
UI thread hold a reference on the window object while it's
running.
Other probpematic case is when the window handle is reused:
if we stop and start the pipeline very fast,
so the sink creates a new window object that is going to use
the same window handle as the previous one.
And finally the case when the pipeline is stopped immediatelly
right after starting, this one is also handled in this commit.
NOTE: a unit test that reproduces this cases have been added
in the previous commit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4417>
g_string_free(.., FALSE) gives us ownership of the string
already, no need to duplicate that again with g_strdup(),
and doing so will leak the string returned by g_string_free()
here. Caught by compiler warnings in newer GLib versions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4380>
The previous code would only check if two packets in a row were duplicates. If
not (i.e. a packet is a duplicate of a packet received slightly before) the code
would generate completely bogus FCI because it assumes there were no duplicates
present in the array.
In order to be efficient, just store all received packets and remove the
duplicates just before the FCI is generated once the array of observations have
been sorted by seqnum.
Fixes TWCC usage with moderate to high packet duplication.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4378>
The proxy and queue are created in the gst_gl_window_wayland_egl_open()
function and will be recreated on open. This leaks both objects, the
wayland client documentation mentions that they should be destroyed
using the appropriate destroy functions.
Found during valgrind memory leak testing, these blocks were marked as
definitely lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4355>
Existing codes rely on modified argc value by g_option_context_parse()
but g_option_context_parse_strv() is used in case of Windows.
Count arguments after the option parsing manually.
Fixing command "gst-inspect-1.0.exe -b"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4322>
Moving from PLAYING to NULL will set the stop_streaming_threads to TRUE,
but when moving back upwards its not reset to FALSE (as only done in
uncalled init and resume callbacks).
Fix by reseting value in the prepare callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4321>
Running element_vkcolorconver test with Vulkan validation layer this error is
raised:
Code 0 : Validation Error: [ VUID-VkMappedMemoryRange-size-01390 ] Object 0:
handle = 0x100000000010, type = VK_OBJECT_TYPE_DEVICE_MEMORY;
| MessageID = 0xdd4e6d8b
| vkFlushMappedMemoryRanges: Size in pMemRanges[0] is 0x4, which is not a
multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize (0x40) and offset +
size (0x0 + 0x4 = 0x4) not equal to the memory size (0xb). The Vulkan spec
states: If size is not equal to VK_WHOLE_SIZE, size must either be a multiple of
VkPhysicalDeviceLimits::nonCoherentAtomSize, or offset plus size must equal the
size of memory
The reason of is that the image size used in the test doesn't comply hardware
restrictions. In order to avoid juggling with image size and hardware
restrictions, this patch proposes to use VK_WHOLE_SIZE macro.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4311>
Running tests with Vulkan Validation enabled show an error on vkimage tests:
Code 0 : Validation Error: [ VUID-VkImageViewCreateInfo-image-04441 ]
Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle
= 0x50000000005, type = VK_OBJECT_TYPE_IMAGE;
| MessageID = 0xb75da543
| Invalid usage flag for VkImage 0x50000000005[] used by vkCreateImageView(). In
this case, VkImage should have VK_IMAGE_USAGE_SAMPLED_BIT |
VK_IMAGE_USAGE_STORAGE_BIT | VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT |
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT |
VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT | VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT |
VK_IMAGE_USAGE_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR |
VK_IMAGE_USAGE_FRAGMENT_DENSITY_MAP_BIT_EXT |
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_ENCODE_SRC_BIT_KHR |
VK_IMAGE_USAGE_VIDEO_ENCODE_DPB_BIT_KHR | VK_IMAGE_USAGE_SAMPLE_WEIGHT_BIT_QCOM
| VK_IMAGE_USAGE_SAMPLE_BLOCK_MATCH_BIT_QCOM set during creation.
The Vulkan spec states: image must have been created with a usage value
containing at least one of the usages defined in the valid image usage list for
image views
This patch adds VK_IMAGE_USAGE_SAMPLED_BIT to the usage bits in test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4311>
While using the validation layer with this pipeline:
gst-launch-1.0 videotestsrc num-buffers=10 ! vulkanupload ! vulkancolorconvert ! vulkansink
The validation layer throws this message:
Code 0 : Validation Error: [ VUID-VkAttachmentDescription-format-06699 ]
Object 0: handle = 0x5555562e9610, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x52b3229e |
vkCreateRenderPass: pCreateInfo->pAttachments[0] format is
VK_FORMAT_B8G8R8A8_UNORM and loadOp is VK_ATTACHMENT_LOAD_OP_LOAD, but
initialLayout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If format includes a color or depth aspect and loadOp is
VK_ATTACHMENT_LOAD_OP_LOAD, then initialLayout must not be VK_IMAGE_LAYOUT_UNDEFINED
When creating the render pass the loadOp can be either
`VK_ATTACHMENT_LOAD_OP_CLEAR` or `VK_ATTACHMENT_LOAD_OP_LOAD` depending on
`enable_clear`. While `enable_clear` is FALSE by default (which means
`VK_ATTACHMENT_LOAD_OP_LOAD`). Nonetheless, its value is explicitly changed by
`vkoverlaycompositor` to FALSE too!
This behavior was introduced in merge request #2470 where
`VK_ATTACHMENT_LOAD_OP_CLEAR` was a fixed value for loadOp. Thus, the bug
consists in a missing initialization of `enable_clear` to TRUE from that merge
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4311>
