The avvideocompare element compares two incoming video buffers using
the specified comparison method (e.g. ssim or psnr). The first
video buffer is passthrough, unchanged.
The comparison is calculated by using libav's ssim or psnr filters.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3366>
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/4535>
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/4521>
By keeping async to TRUE, a deadlock is avoided where the appsink is
filled with data after a flushing seek but before its PAUSED->PLAYING
state change finishes. If that happens, the appsink is stuck, because
its internal condition variable waits for the appsink to have more room
for data. The basesink's preroll lock is held during this, and it also
tries to acquire that lock during the state change -> deadlock.
By keeping async to TRUE, this flood of data does not happen.
Also, setting the max-buffers property to 1 is unnecessary - the test
runner will anyway detect excess memory usage if it happens.
Other property adjustments turned out to just be redundant.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4200>
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/4529>
Proxy the force-live and min-upstream-latency propertyies to the internal
glvideomixerelement at construction time. force-live has to be set
during construction of the glvideomixerelement, so that has to be
deferred until the _constructed() call. Make sure that all other
existing proxied properties will still get set once the element
is created.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4494>
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/4528>
check_version(1.23.1) would return TRUE for a git development version
like 1.23.0.1, which is quite confusing and somewhat unexpected.
We fixed this up in the version check macros already in !2501, so this
updates the run-time check accordingly as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4513>
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/4437>
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/4437>
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/4437>
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/4437>
When seek flush, gst v4l2 buffer pool flush is not atomic which will
lead double enqueue buffer (qbuf) issue, and v4l2 buffer pool qbuf is
also not atomic which will lead no free buffer found in the pool.
1. add lock for calculate enqueue number in streamon function
2. add lock for v4l2 capture end streamoff in pool flush function
3. lock the whole funciton of v4l2 buffer pool qbuf, then the buffer
pool index and qbuf operation are atomic
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4465>
when regotiation happens, v4l2src will check if it can reuse current caps,
but we need check if current caps is subset of all query caps from downstream
instead of check it with query caps one by one.
Assuming that the current caps is not the subset of first caps from query caps,
it will go to try fmt. when try fmt success, v4l2src will make pending_set_fmt
to TRUE and going to reset.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4500>
Allowing better control over the way discovery happens and allowing
us to expose a proper API.
This also adds the potential of implementing more multi-threaded
discovery in a clean way in the future.
This allows us to cleanly expose the new
GstDiscoverer::load-serialize-info signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3911>
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/4498>
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/4492>
Current implementation can in some cases detect
that all data is sent but in reality it is not,
leading to a push to an unlinked pad.
This is a race between the probe used to track data sent and a
call to close.
This patch sends an EOS before starting the close procedure
and then waits for the EOS event to come through to the
src pad before commencing with tear down.
This ensures that any queued data before EOS is flushed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4462>
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/4481>
`webrtc->signaling_state` (from) and `new_signaling_state` (to) had the
same value when printed in a trace log. This commit adds a
`old_signaling_state` variable to hold the previous value, so that the
print statement works as intented.
Spotted by: Mustafa Asım REYHAN
Fixes#1802
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4362>
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/4469>
Fix the following use:
- upstream sends a video with a rotation tag, say 90°
- upstream switches to another video without rotation
- the second video was still rotated by videoflip
Fix this by resetting the orientation when receiving STREAM_START.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4377>
In order to provide build and provide the jack plugin with the prebuilt
binaries of gstreamer we distribute with releases, we can not depend
on an external dependency nor can we ship plugins linking to libraries
we don't provide.
We can also not provide jack ourselves, as it would likely cause a
mismatch with the jack daemon on the host.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4350>
The generated gir file marks the size parameter as "out" by default.
This is wrong in the context of a caller allocated buffer with a given size.
Explicitly marking the size parameter as (in) fixes the issue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4399>
Similar to cairooverlay element but this element emits "draw"
signal with Direct3D11 render target view, so that an application
can render/overlay/blend on the given render target view
without any copy operation
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4415>
We need to create the sink caps and src caps dynamically for different
platforms. By default, the vpp init function create static pad template
and the compatibility and flexibility of the platform are too poor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4177>
Enable dynamic capability support for msdkav1dec, msdkh264dec,
msdkh265dec, msdkmjpegdec, msdkmpeg2dec, msdkvc1dec, msdkvp8dec,
msdkvp9dec.
The gstmsdkdec elements can create the sink caps and src caps
dynamically for different platforms.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4177>
We need to create the sink caps and src caps dynamically for different
platforms. By default, the dec init function create static pad template
and the compatibility and flexibility of the platform are too poor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4177>
Enable dynamic capability support for msdkav1enc, msdkh264enc,
msdkh265enc, msdkmjpegenc, msdkvp9enc, msdkmpeg2enc.
The gstmsdkenc elements can create the sink caps and src caps
dynamically for different platforms.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4177>
We need to create the sink caps and src caps dynamically for different
platforms. By default, the enc init function create static pad template
and the compatibility and flexibility of the platform are too poor.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4177>
By default, msdk plugin will register all encoders and decoders
on any platform, even unsupported encoders and decoders will be
registered. Dynamically register encoders and decoders besed on
the supported codecs on different platforms.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4177>
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/4317>
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/4317>
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/4401>
We should behave similarly to video parsers so we can use:
- accept-template as we can also accept caps with missing fields.
- accept-intersect to do quick check with the pad template caps as it is
enough. Users should have figured the appropriate full caps on a
previous caps query
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4341>
The encoder is also initialised using interlace mode, colorimetry, chroma-site
and multiview mode, so let's make sure we only skip reinitialising the encoder
in set_format() if none of those have changed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4395>
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/4328>
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>
