This works on Linux, Android, Windows, macOS, FreeBSD, NetBSD, OpenBSD,
DragonFlyBSD, Solaris and Illumos.
Newly supported compared to the C version is Windows.
Compared to the C version various error paths are handled more correctly
and a couple of memory leaks are fixed. Otherwise it should work identically.
The minimum required Rust version for compiling this is 1.48, i.e. the
version currently in Debian stable. On Windows, Rust 1.54 is needed at
least.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1259
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3889>
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/4354>
The framerate should only be replaced (and corrected for alternating field)
when it is parsed from the bitstream. Otherwise, the upstream framerate
from caps should be trusted and assumed correct.
Related to gst-plugins-bad!2020
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4259>
The first serialized events that can be send on a src pad are a CAPS and then a
SEGMENT event.
When handling events from user in appsrc, we used to send a segment
automatically if the SEGMENT has not been sent yet.
This breaks if the CAPS event was not send either as we were now sending
a SEGMENT before the CAPS.
Fix this by delaying such events until the CAPS has been configured.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4297>
gst_base_src_new_segment() does not send the segment right away, which
may break events ordering if subclass sends other events after
calling it.
Introducing a variant pushing the segment right away to preserve
ordering in such cases.
Will be used by appsrc which has its own internal queue where we need to
preserve events order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4297>
Short-circuit parsing and recreating the playlist URI if
no HLS directives are going to be applied to it.
Fixes problems playing some streams (YouTube) that have
unneeded escaped characters in the URI and then complain
when GStreamer removes the escaping
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4335>
We don't need to obtain the mutex to ensure that `sq` is non-NULL. `sq`
is assigned immediately after the pads are created and not destroyed
until the pads are finalized.
Use the pad direction to determine which internal peer we need.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/888>
When a pipeline is pre-rolling, it waits for all sink elements to report
they have received a buffer before completing the transition to paused.
This async wait is done using a state condition variable. The way this
waits are currently implemented do not protect against spurious conditional
wake ups, which may happen due to external factors in the kernel.
This change implements the wait within a loop that iterates over the protected
variable to reinitiates the wait if the wakeup was spurious. More details in
the [GCond docs](https://docs.gtk.org/glib/struct.Cond.html).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4086>
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/4260>
It's quite confusing to print a function callback signature for
action signals when people need to do a g_signal_by_name() invocation
in order to use this feature. Requires too much background knowledge
about how GObject works under the hood to make sense of that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4299>
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/4313>
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/4309>
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/4296>
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/4296>
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/4296>
Adding propose_allocation is to meet the requirement of Application to
request buffers. Application sometimes need to create buffer pool
and request buffers to maintain buffer management itself, and Gstreamer plugin
import Application's buffers to use. So, add propose_allocation in
appsink like waylandsink and kmssink etc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4185>
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/4273>
Fix compiler warnings about not using the return value when
freeing the GString segment with g_string_free(.., FALSE):
ignoring return value of ‘g_string_free_and_steal’ declared with attribute ‘warn_unused_result’
which we get with newer GLib versions. These were all harmless.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4273>
Specification says:
"""
engineVersion is an unsigned integer variable containing the developer-supplied
version number of the engine used to create the application.
"""
Assuming the engine is GStreamer, it would be expected to set its version as
engine version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4243>
This is a follow-up of the previous commit that enabled support for redirection.
The problem is that the urisourcebin that emitted the error redirection never
produced any pads, and therefore was never linked to decodebin3. This resulted
in the code waiting for that (output) item to finally switch over ... which will
never happen.
The fix is done by removing it early if it was never connected to decodebin3.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4252>
With GST_SEEK_FLAG_SNAP_AFTER present, the previous version would
adjust seek time based on the keyframe farthest away from desired_time.
This was incorrect, because we always want the *earliest* suitable keyframe
to seek to, not the last one.
With this fix, in case of the SNAP_AFTER, we now look for the closest keyframe
that can be found after desired_time. Behaviour for SNAP_BEFORE should remain
unchanged.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4183>
Trying to run the `janus` Rust `gst-example`, `tungstenite` reports:
> Missing, duplicated or incorrect header sec-websocket-key
Indeed, all mandatory headers from the following list are missing
(code from `tungstenite:🤝:client::generate_request`):
```rust
const WEBSOCKET_HEADERS: [&str; 5] =
["Host", "Connection", "Upgrade", "Sec-WebSocket-Version", KEY_HEADERNAME];
```
These headers are mandatory for the websocket handshake. This feature is
selected by async-tungstenite.
Prior to this commit, the HTTP request was created with the header
"Sec-WebSocket-Protocol" only. Delegating the request creation to tungstenite
adds the missing headers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4240>
Assuming that V4L2 CAPTURE devices always use one buffer per JPEG image, we can
always mark JPEGs provided by a V4L2 element as parsed.
The V4L2 elements require that JPEG images sent to V4L2 OUTPUT devices must
always be parsed.
This is necessary to link a V4L2 CAPTURE device with a V4L2 OUTPUT device
without explicitly marking the stream as parsed or adding a jpegparse into the
pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4229>
The goal of parsebin is to figure out which elements to link together in order
to provide elementary streams given any random input.
The problem is that deciding whether a given stream should still have more
elements plugged in or not was dependent on ... the presence of compatible
decoders (sic).
Instead of that, if we can't plug anymore elements on a given stream *and* it is
detected as being an elementary stream, expose it.
Fixes#2118
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4231>
In the same spirit of libva-win32 elements this patch shows the driver of each
element in gst-inspect, giving more information to the user. This driver
description is parsed from vaQueryVendorString from mesa and intel drivers,
while copied as is for others. Also appends the render node for multi gpu
systems.
Fixes#2349
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4204>
There's no guarantee it will *actually* be the URI which refered to what we are
downloading. It could be a stream URI or anything else.
Instead of putting something wrong, put no (specific) referer as a better choice
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3972>
Otherwise application would not be able to know matching element
for wanted device. Typical use case of the read-only device path
(DXGI Adapter LUID, CUDA device index, etc) property is that
application enumerates physical devices and then selects matching
GStreamer element (in null state) via device path property.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4220>
If sticky events are present on parsebin source pads, we propagate them to the
multiqueue source pads. Those will be propagated on the new urisourcebin source
pads like in the other code paths.
This ensures that STREAM_START event are present on new source pads. If CAPS
event are also present (not guaranteed), they will also be available.
Fixes#2384
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4203>
H.265 NAL always have 2 bytes of headers. Unlike the H.264 parser, this parser
will simply return that there is NO_NAL if some of these bytes are missing.
This is then properly special cased by parsers and decoders. Add a test to
ensure we don't break this in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
The appropriate return value for incomplete NAL header should be
GST_H264_PARSER_NO_NAL_END. This tells the parser element to
gather more data. Previously, it would assume the NAL is corrupted
and would drop the data, potentially causing stream corruption.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3234>
The flowcombiner and active_streams shouldn't be cleared in the
mse-bytestream variant, only in the mss-fragmented one. Otherwise the
soft reset leaves qtdemux in a state where it still believes that it has
streams, but they've been cleared. In that case, a null pointer
dereference happens and the app crashes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4199>
Previously, reassigning loop index l in nicestream.c
could cause a segfault if l->data was null, as it could
reassign l to a null variable, triggering the loop
postassignment l->next, which then segfaults due to
l now being null. It is instead moved into the loop.
_delete_transport already performs the reassignment
inline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4192>
In gst_video_info_dma_drm_to_caps() the caps are newly created, so there's no
need for make it writable. In gst_video_info_dma_drm_from_caps() a copy of the
caps is done, which implies a gst_caps_make_writable().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4195>
In webrtc_data_channel_send functions, both data and string,
an early return on a non-open datachannel caused it to leak
the buffer used for pushing to appsrc, meaning any buffer
sent after leaving the open state was leaked in full.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4191>
When using such a launch line:
fakesrc ! "audio/x-opus, channel-mapping=(int)<0, 1>" ! fakesink
the caps string, with spaces escaped but no quotes gets passed to
gst_caps_from_string(), which then fails to parse the array because it
contains spaces.
When using an explicit capsfilter instead:
fakesrc ! capsfilter caps="audio/x-opus, channel-mapping=(int)<0, 1>" ! fakesink
the caps string, with spaces escaped and quotes gets passed through
gst_value_deserialize, which first calls gst_str_unwrap() on it and only
then gst_caps_from_string() on the result.
This fixes the inconsistency by using a custom version of str_unwrap()
in the parser, which doesn't expect a quoted string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4181>
When copying a buffer, for example with gst_buffer_make_writable(), the
new buffer might reference the same GstMemory as the src buffer,
making those memories not writable. If the src buffer gets disposed
first it should return to its buffer pool, but since some of its
memories are not writable it gets discarded and new buffer/memory gets
allocated.
Solves this by making the new buffer keep a reference to the src buffer,
that ensures that by the time the src buffer gets disposed no other
buffer are referencing its memories and it can thus return safely to its
pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4176>
