On Windows and macOS always use the proper monotonic clock, including
for gst_util_get_timestamp(), and initialize its state only once.
Also on macOS use clock_gettime() for the realtime clock, if available
instead of always falling back to GLib.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4658>
Add d3d11 conversion path to make gst_video_convert_sample() work
for GstD3D11Memory.
Note that just adding "d3d11download" to the exisitng code is
suboptimal from GstD3D11 point of view because:
* d3d11convert element can support crop/colorspace-conversion/scale
all at once while existing software pipeline needs intermediate steps
for the conversion
* "Process everything on GPU then download it to CPU memory" would be likely
faster than "download GPU memory to CPU then processing it on CPU"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2715>
adjust log level from GST_ERROR to GST_WARNING when h264 caps have
codec_data but no avc format or have no codec data or stream-format.
Because theses are not real errors, it is easy to mislead if print error
logs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4675>
Drivers may signal end of sequence using an empty buffer and LAST buffer
set, or just an empty buffer on certain legacy implementation. When this
occured, we'd send GST_V4L2_FLOW_LAST_BUFFER were the code expected
GST_FLOW_EOS. Stop abusing GST_FLOW_EOS and port all the code to the new
GST_V4L2_FLOW_LAST_BUFFER.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4669>
ptpd is defaulting to the hybrid mode, and was sending invalid multicast
PTP messages in that configuration until ce96c742a88792a8d92deebaf03927e1b367f4a9.
While this commit was made in 2015 there was no release in the meantime.
Work around this by detecting this case and defaulting to the default
values for the given intervals as given by the PTP standard.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4654>
Previously it was possible that a shared media was just in the process
of being unprepared because the last client disappeared, while another
client retrieved it from the cache and then tried to use it. Unless the
media was reusable this would've then failed unnecessarily.
To avoid this it is necessary to lock the media directly in
gst_rtsp_media_factory_construct() and return a locked media. After
locking the cached media it is necessary to check if the media was ever
unprepared or is actually reusable and based on that either reuse it or
create a new media.
This minimally changes the gst_rtsp_media_factory_construct() API to
always return a locked media, and adds a new
gst_rtsp_media_can_be_shared() function to check if a media can actually
be shared in practice.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4606>
The resolution of VP9 video can be changed without keyframe.
The change detected by MSDK/VPL should be negotiated with downstream.
Only the situation can be fixed here if the changed resolution is less than or equal to the initial surface resolution.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4450>
New vulkan formats don't match the number of planes with the number of memories
attached to the buffer. This patch changes the pattern of using planes for
traverse the memories with the number of attached memories.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
It's a generalization of the original gst_vulkan_get_or_create_image_view().
The reason for passing the whole VkImageViewCreateInfo structure rather than
just the missing fields, is because VkImageSubresourceRange and
VkComponentMapping can be different and those are most of VkImageViewCreateInfo.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
This is going to be used when the pool is used by a video decoder for
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR, since the frame allocation needs the
VkVideoProfileInfoKHR, and for that here GstCaps is used to wire it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
The specification says:
VUID-vkAllocateMemory-pAllocateInfo-01713
must pAllocateInfo->allocationSize be less than or equal to
VkPhysicalDeviceMemoryProperties::memoryHeaps[memindex].size where memindex =
VkPhysicalDeviceMemoryProperties::memoryTypes[pAllocateInfo->memoryTypeIndex].heapIndex
as returned by vkGetPhysicalDeviceMemoryProperties for the VkPhysicalDevice that
device was created from.
Though this can be catch by the validation layer, the requested frame size
depends on the use case so it's better to check this restriction by our code.
This patch also makes use of this new function to find memory type index,
and removes the unused function to find memory type index, which, as GstVulkan is
considered unstable, we can do it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
The purpose of this function is to get more info about the mapped Vulkan format
from the GStreamer format, since they can be multiple Vulkan formats for one
GStreamer format.
Also a Vulkan format may have certain usage and aspects that must be verified.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
Originally the opened device only created one queue of one family queue, to say
graphics one. This approach felt short when other queue family is required not
shared with the graphics queue family, for example video decoding.
This new approach proposes to create those queues with supported families. For
now, only video decoding and encoder are created, if they are available.
In order to hold multiple queues opened, an array of VkDeviceQueueCreateInfo is
held along the live the device object, because it's used to traverse or get the
opened queues.
The algorithm to choose which queues create (or open) is to look for the queue
with more family bits, which also supports the one we are requesting, thus
minimizing the number of global queues of a certain family to create.
Nonetheless, the number of queues to open per family is set to be all of them,
widening the possibility of parallelism.
Also, this commit do a cosmetic refactor the assigning the physical device
nearer where it's used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
Also adds a meson option to enable them.
The symbol GST_VULKAN_HAVE_VIDEO_EXTENSIONS is an alias of
defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 238
if the option is allowed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
Subclasses may want to override the pad template with different formats
or with a different pad subclass.
The original beahviour is still available by calling
gst_gl_mixer_class_add_rgba_pad_templates() in _class_init() of the
subclass.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4608>
max-qp and min-qp will set the same quantizer scale for I/P/B frames,
while max-qp-i/p/b and min-qp-i/p/b enable the max/min quantizer for I,P,B
frame separately. When max/min-qp and max/min-qp-i/p/b are given
simultaneously, the later set one will overide the previous one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4589>
when play rtsp stream with playbin3 enabled, there are some critical logs:
g_object_get_is_valid_property: object class 'GstPlayBin3' has no property named 'n-video'
g_object_get_is_valid_property: object class 'GstPlayBin3' has no property named 'n-audio'
g_object_get_is_valid_property: object class 'GstPlayBin3' has no property named 'n-text'
self->collection could be NULL when READY->PAUSED if the pipeline
is live, then it will fallback to query playbin2's property,
we can call gst_play_streams_info_create_from_collection
directly, it will check self->collection internal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4460>
In cases that encoder needs to reset format, there is race while draining.
v4l2videoenc finish() sends CMD_STOP command to driver, and desire to return
GST_FLOW_OK. But at this time, encoder CAPTURE may have dequeued the last
buffer and got eos. finish() return value changes to be GST_FLOW_EOS which
causes set format fail. So there is no need to check return value for finish()
when set format.
Also need to flush encoder after draining to make sure flush is finished.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4495>
When reconfigure_output_stream entry missing decoder path,
requested_selection should been update with what is really
active/selected immdiately with SELECTION_LOCK hold. So
use an optional message return from reconfigure_output_stream
and post it after release SELECTION_LOCK. This can make sure
other thread call to check_slot_reconfiguration will got
a correct requested_selection.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4599>
The index is already incremented by 3 every iteration so multiplying it
by 3 additionally on each array access is doing it twice and does not
work.
This caused invalid files to be created if there's more than one CEA608
triplet in a buffer, and out of bounds memory reads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4634>
The devices list returned by g_udev_client_query_by_subsystem() may
contain udev devices in disorder path name. For example, on some
platform it may contain renderD129 before renderD128 device. This
will cause we register wrong va plugin name. In this case, the
renderD129 will be registered as default plugins such as vah265dec,
while the renderD128 will be registered as varenderD128h265dec.
This conflicts with the non-udev version of gst_va_device_find_devices().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4643>
Make splitmuxsrc deal better with stream reordering by
making the largest observed PTS contiguous in the
next fragment. Previously, it selected DTS, but then
aligned that with the segment start of the next fragment,
which holds PTS values - leading to glitches in
streams that don't have PTS = DTS at the start.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4637>
When transitioning from state PAUSED to READY, the sctpenc element
could previously be stuck in an endless loop trying to resend data
in case the underlying sctp stream was in the process of
resetting. usrsctp_sendv() would repeatedly return EAGAIN with the
result that 0 bytes were sent and then sctpenc would retry forever.
To bring sctpenc out of the resend loop we just need to inform the
sink pad that it is flushing, which is already done for the associated
data queue, but we also need to set the bools associated with the
sinkpads that are used as the loop criterion.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4601>
Assigning TRUE (1) to a signed 1 bit integer will cause truncation
from 1 to -1 because the only non-zero value that can be stored is -1
due to how two's-complement works.
As this is a proper GObject let's not bother with all this and simply
use a normal gboolean instead.
../subprojects/gst-plugins-good/ext/pulse/pulsesink.c:1490:19: warning: implicit truncation from 'int' to a one-bit
wide bit-field changes value from 1 to -1 [-Wsingle-bit-bitfield-constant-conversion]
pbuf->in_commit = TRUE;
^ ~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4617>
It could indeed be used uninitialized, but only if one of the
g_return_val_if_fail() caused an early return.
../subprojects/gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c: In function ‘rtp_jitter_buffer_append_query’:
../subprojects/gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c🔢10: warning: ‘head’ may be used uninitialized
[-Wmaybe-uninitialized]
1234 | return head;
| ^~~~
../subprojects/gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c:1232:12: note: ‘head’ was declared here
1232 | gboolean head;
| ^~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4616>
If gst_buffer_pool_set_config() fails then the pool will use its old
config. This may include different width or height when
pic_width/pic_height != frame_width/frame_height.
As a result, the assertions in theora_handle_image() will fail.
So check the result of gst_buffer_pool_set_config() and only use the pool
if it succeeds. Otherwise let the parrent decide_allocation() create a new
pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4600>
If the buffer has no video meta then the meta is created from the local
data. In this case, the other asserts don't actually check anything. So add
another one to ensure that the buffer is actually large enough.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4600>
Upon creating a window, glimagesink and osxvideosink now set the policy to
NSApplicationActivationPolicyRegular, which lets us show an icon in the Dock
for convenience and appear in the top menu bar like other apps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4573>
Setting the policy to NSApplicationActivationPolicyAccessory by default makes
sure that we can activate windows programmatically or by clicking on them.
Without that, windows would disappear if you clicked outside them and there
would be no way to bring them to front again. This change also allows osxvideosink
to receive navigation events correctly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4573>
This is no longer needed since the introduction of `gst_macos_main()` in 1.22.
Before that existed, we had a patch for GLib in Cerbero, which did work but made it
impossible to update GLib at all. The code being removed was a fail-safe in case of
running without said patch being applied. It's no longer needed, since for macOS
we just wrap our GStreamer with an NSApplication using `gst_macos_main()`.
Warnings will be displayed if no NSApp/NSRunLoop is found wherever needed,
pointing the user towards using the new API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4366>
Invoking gst_osx_video_sink_osxwindow_destroy() can currently cause a deadlock
because showFrame() keeps trying to get the same lock as well. Moving the lock
closer to where it's actually needed seems to be enough to fix the issue for now.
Reported-by: Alexande B <abobrikovich@gmail.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4559>
Depending on the exact output format, 0x00 may be a better default for
padding than 0x80. 0x00 is the recommended padding value when used in
CDP (and cc_data) but is not when used in s334-1a. See CTA-708-E 4.3.5
amd SMPTE 334-1-2007 5.3.2.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4578>
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/4555>
The qt5 and qt6 plugins will now correctly error out if you enable the
option, and you can also now explicitly ensure that wayland, x11,
eglfs support is actually functional by enabling the options. It was
too easy to build non-functional support for these.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4537>
jackaudiosink and jackaudiosrc have a rank and might be plugged
as part of auto-plugging inside playbin and playsink or the
autoaudiosink/autoaudiosrc elements, so we don't really want to
spew ERROR log messages in that case, which is consistent with
what alsasink and pulseaudiosink do.
This is less noticable on Linux because pulseaudiosink has a
higher and alsasink which has the same rank comes before jack
in the alphabet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4545>
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/4536>
Atomically set and get the picture_id. This changeset only atomically gets
the picture-id when such property is queried on the element, on every other
place where it is accessed internally it is accessed directly.
This is because there is no MT scenario where we would be modifying this value
and reading it internally in parallel.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4530>
In recent versions of Chrome (M106) a change on their jitter buffer means that
they are very susceptible to PictureID discontinuities.
Then avoid at all cost resetting the PictureID. Moreover, according to
the RFCs for VP8 and VP9 payloads; the PictureID can start off at any
random value. So there is no logical problem of incrementing it here
rather than resetting it, as long as it is a different PictureID.
WebRTC's recent corruption issue:
https://bugs.chromium.org/p/webrtc/issues/detail?id=15101
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4530>
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>
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>
gst_buffer_add_parent_buffer_meta() is used when a GstBuffer uses
GstMemory from another buffer that was allocated from a pool. In that
case we want to make sure the buffer returns to the pool when the memory
is writable again, otherwise a copy of the memory is created. That means
the child buffer must drop its ref to the memory first, then drop the
ref to parent buffer so it can return to the pool when it is the only
owner of the memory.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4176>
This is already done for every other calls to send_packet. The deadlock occures
since FFMPeg 6.0. The decoder tries to get a buffer from a thread during
the draining process, and blocks trying to get the video decoder stream lock
already heald by the drain function.
Fixes#2383
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4171>
If the input is not a DMABuf, attempt to copy into a DRM Dumb
buffer and import it has a DMABuf. This will offload the
compositor from actually doing this copy (needed to handle SHM)
and may allow the software decoded stream to be rendered to
an HW layer, or even reach through some better accelerated
GL import path.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
This allow simplifying the GstVideoInfo handling in the sinks. Instead
of having to update a video info for the import, the sink can simply pass the
video info associated with the caps and rely on the VideoMeta in the GstBuffer
to obtain the appropriate offset and stride.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
As we don't render into the widget directly, there is no "initial" draw
happening. As a side effect, the internal aspect ratio adapted display
width/height is never initialize leading to assertions when handling navigation
events.
gst_video_center_rect: assertion 'src->h != 0' failed
Simply queue a redraw after setting the widget format in order to fix the issue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
This allow allocating memory from any DRM driver that supports this
method. It additionally allow exporting DMABuf. This allocator depends
on libdrm and will be stubbed if the dependency is missing. This is derived
from kmssink dumb allocator.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3801>
GStreamer 1.18 changed the serialization of enums.
This patch updates gsttr-stats.py to handle the new format.
In absence of that, the script was failing like this:
```
Traceback (most recent call last):
File "/home/ntrrgc/Apps/gstreamer/./subprojects/gst-devtools/tracer/gsttr-stats.py", line 224, in <module>
runner.run()
File "/home/ntrrgc/Apps/gstreamer/subprojects/gst-devtools/tracer/tracer/analysis_runner.py", line 42, in run
self.handle_tracer_entry(event)
File "/home/ntrrgc/Apps/gstreamer/subprojects/gst-devtools/tracer/tracer/analysis_runner.py", line 27,
in handle_tracer_entry
analyzer.handle_tracer_entry(event)
File "/home/ntrrgc/Apps/gstreamer/./subprojects/gst-devtools/tracer/gsttr-stats.py", line 114, in handle_tracer_entry
key = (_SCOPE_RELATED_TO[sv.values['related-to']] + ":" + str(s.values[sk]))
KeyError: 'thread'
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4155>
gstcudaloader.cpp defines GST_DEBUG_CATEGORY (gst_cudaloader_debug);
but it wasn't initializing it anywhere.
This caused the following error to be logged by gst-plugin-scanner when
libcuda.so.1/nvcuda.dll couldn't be loaded, e.g. in systems without
CUDA:
(gst-plugin-scanner:39618): GStreamer-CRITICAL **: 14:40:22.346:
gst_debug_log_full_valist: assertion 'category != NULL' failed
This patch fixes the bug by initializing the category in
gst_cuda_load_library_once_func() before any logging occurs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4154>
This patch adds documentation to the 'log' tracer and amends the design
document of Tracers to replace a misleading example of the 'log' tracer
with a different example that uses tracer arguments with tracers that do
actually handle said arguments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4153>
These days you're can use minFrameDuration and maxFrameDuration which
are CMTime with fractional values. That way we don't need to convert
between double and fractions in a really weird way.
This fixes really odd fractional values exposed in caps, like:
2000000/76923, 1000000/37037, 5000000/178571, 10000000/344827, 10000000/333333
Which are actually just 26/1, 27/1, 28/1, 29/1, 30/1
We can also delete a lot of outdated code for iOS versions older than
7.0 by using newer APIs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4134>
This fixes simplification of caps with GstFractionRange structures,
for example, this caps:
video/x-raw, framerate=(fraction)5/1; video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
can now be simplified to:
video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
instead of:
video/x-raw, framerate=(fraction){ 5/1, [ 5/1, 30/1 ] }
And this:
video/x-raw, framerate=(fraction)[ 2/1, 5/1 ]; video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
can be simplified to:
video/x-raw, framerate=(fraction)[ 2/1, 30/1 ]
instead of
video/x-raw, framerate=(fraction){ [ 2/1, 5/1 ], [ 5/1, 30/1 ] }
This fixes overly-complicated GL caps set by avfvideosrc on macOS and
iOS when capturing from a webcam.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4132>
Removing a meta from a buffer means one doesn't have access to it
anymore. Instead use the already reffed composition directly.
Fixes a use-after-free in the following pipeline:
... ! vulkanupload ! timeoverlay ! vulkanoverlaycompositor ! ...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4143>
As specified in EIA/CEA-608-B section 8.4:
When closed captioning is used on line 21, field 2, it shall conform
to all of the applicable specifications and recommended practices as
defined for field 1 services with the following differences:
a) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 14h, 20h to 14h, 2Fh in field 1, shall be replaced
with 15h, 20h to 15h, 2Fh when used in field 2.
b) The non-printing character of the miscellaneous control-character pairs
that fall in the range of 1Ch, 20h to 1Ch, 2Fh in field 1, shall be replaced
with 1Dh, 20h to 1Dh, 2Fh when used in field 2.
This means simply switching the "field" field in the caps isn't enough for
converting raw 608 from one field to another, some control codes also
need to be amended.
+ Adds simple test
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4126>
GstBufferPool implementation was referenced for this GstD3D11PoolAllocator,
for example GstAtomicQueue, various atomic operations, and GstPoll ones.
However, such combination seems to be almost pointless
since gst_poll_{read,write}_control() takes mutex and also
GstPoll uses Win32 event handle internally.
Use simple SRWLOCK and CONDITION_VARIABLE instead, and don't make things
complicated/inefficient.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2887>
When we run Cheese 41.1 on our imx platform, Cheese preview freeze
at first frame.
During pipeline state changing from NULL to PLAYING, if there are
both elements that state change asynchronously and state change
with no preroll in the bin, the element inside may send ASYNC_DONE
message to it, while the bin's pending state is VOID_PENDING.
In this case, the bin will not post ASYNC_DONE message to parent
bin, which makes parent bin thinks that there are still elements
in it that haven't completed state changing, causing the pipeline
freeze in an intermediate state.
This commit modifies the bin_handle_async_done() function. When the
bin, whose pending state is VOIDING_PENDING, receives the ASYNC_DONE
message, it will also post this message to its parent bin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3490>
A flush is resetting or not depending on the reset_time argument in the
FLUSH_STOP event is set.
Resetting flushes reset the running time to zero and clear any existing
segment. These are the kind of flushes used by flushing seeks, and by far the
most common. Non-resetting flushes are much more niche, used for instance for
quality changes in adaptivedemux2 and MediaSource Extensions in WebKit.
A key difference between the seek use case and the quality change use case is
that the latter is much more removed from the player. Seeks generally occur
because an user request it, whereas quality changes can be automatic.
Currently, there are three notable cases where position queries fail:
(a) before pre-roll, as there is no segment yet. This is one is understandable,
as for at least some time before pre-roll, we cannot know if a media stream
would start at 0 or any other position, or the duration of the stream for that
matter.
(b) after a resetting flush caused by a seek. This kind of flush resets the
segment, so it's not surprising position queries fail. This is inconvenient for
applications, as it means they always need to handle position reporting (e.g.
in UI) separately every time they request a seek, e.g. by caching the seek
target and using it when the position query fail. I'm not fond of this
behavior, as it's unintuitive and makes GStreamer harder to use, but at this
point could be difficult to change and it's not within the scope of this
proposal.
(c) after a non-resetting flush, e.g. caused by a quality change. The segment
is not reset in this case. Position queries work until a FLUSH_STOP is sent.
Querying position after a FLUSH_START but before a FLUSH_STOP works, and
returns the position the sink was at the moment the FLUSH_START was received.
**This in fact the only reliable way (short of adding probes to the sink
element) to get this position**, as FLUSH_START receival is asynchronous with
playback.
In the case (c), as of currently, position queries fail once the FLUSH_STOP is
received. But unlike in (b), the application has no position to fall back to,
as the FLUSH_START was initiated by elements inside the pipeline that are in a
lower layer of abstraction. Specific applications that have control of both the
player and the internal element doing the flushing -- such as WebKit -- can
still work around this problem through layer violations (lucky!), but this
still puts in question this behavior in GStreamer.
This patch fixes this case by amending the position query handler of basesink,
which was previously erroneously returning early with "wrong state", even
though the flush occurs in PAUSED or PLAYING.
A unit test checking this behavior has also been added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3471>
The code wants to prepend one byte to every byte pair. It correctly did
so by working backwards pair-wise, but then didn't work backwards
instead of each individual pair / future triplet, overwriting
information before attempting to read it.
The code also failed to update the len pointer after prepending.
This fixes both issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4100>
The abort() method of SourceBuffer in Media Source Extensions is
expected to flush the demuxer and discard the current fragment,
if any. The configuration of tracks, if any, should be preserved.
qtdemux has different behavior for flush events depending on the
context.
This patch activates the intended behaviour only for streams of the
VARIANT_MSE_BYTESTREAM type, conformant to the ISO BMFF Bytestream
specification[1]. This flush behaviour is the same as the one
already in use for adaptivedemux sources.
[1] https://www.w3.org/TR/mse-byte-stream-format-isobmff/https://bugzilla.gnome.org/show_bug.cgi?id=795424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4101>
Removing sockets from the epoll for cancellation is unreliable and might
not be thread-safe. Rather, have SRT watch a FD from the cancellable if
available. Keep the cancellable cancelled while we're not open.
Use the regular single-socket `sock` and `poll_id` fields for the
listening thread instead of duplicating them.
Before polling we need to check the socket state. SRT closes broken
sockets by itself and when the epoll contains our cancellation FD it can
no longer be empty, which was an error before.
Treat more failures in the read and write operations as an opportunity
to try a reconnect.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4087>
Seems that SRT can remove the socket from the poll by itself when the
connection gets closed. Consider this an error condition and ensure we
only "abort successfully" when we're actually trying to unlock.
Needs more investigation but this is enough to prevent the element from
getting stuck not reporting an error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4087>
In tests in the rust bindings we end up with 2 thread initializing
concurrently, and it should not be a problem, -validate should be MT
safe.
Using a recursive mutex as we might recursively init for some reason
and we are not on the hot path here in any case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4089>
Recursively invoking the NSMainLoop can cause crashes in
applications that don't expect it. Instead of waiting for
permission to be granted, move the wait later - until we
actually need device permissions when starting the capture
session. That moves the wait into the streaming thread
instead of the application thread that's setting the pipeline
state to READY.
Instead of a manual state change implementation to open
and close the device, use the basesrc start/stop methods that
are intended for the purpose.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4083>
There may be garbage or some bits before a SOI comes in some problematic
mjpeg streams. For example, some network error may cause the EOI marker
of the previous frame lost, and when the new frame's SOI comes, we still
use the state of the last frame, which will generate errors.
For this kind of frames without EOI, if that frame already has some data
(the SOS segment is detected), we still push it as a frame with CORRUPTED
flag set. But if not, we just discard all the data before the new SOI.
Co-Authored-By: Víctor Jáquez <vjaquez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4039>
The previous implementation was a bit primitive, assuming the subclass
had registered a template name starting with sink_ . Instead make
the effort of parsing the actual template name, and use that to generate
the final pad name.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4032>
This patch prevents a possible race condition from taking place between the EOS event handling and rtcp send
function/thread.
The condition starts by getting the GST_EVENT_EOS event on the send_rtp_sink pad, which causes two core things
to happen -- the event gets pushed down to the send_rtp_src pad and all sessions get marked "bye" prior to
completion of the event handler. In another thread the rtp_session_on_timeout function gets called after an
expiration of gst_clock_id_wait in the rtcp_thread function. This results in a call to the
ess->callbacks.send_rtcp(), which is configured as a function pointer to gst_rtp_session_send_rtcp via the
RTPSessionCallbacks structure passed to rtp_session_set_callbacks in the gst_rtp_session_init function.
In the race condition, the call to gst_rtp_session_send_rtcp can have the all_sources_bye boolean set to true
while GST_PAD_IS_EOS(rtpsession->send_rtp_sink) evaluates to false. This is the result of gst_rtp_session_send_rtcp
running before the send_rtp_sink's GST_EVENT_EOS handler completes. The exact point at which this condition occurs
is if there's a context switch to the rtcp_thread right after the call to rtp_session_mark_all_bye in the
GET_EVENT_EOS handler, but before the handler returns.
Normally, this would not be an issue because the rtcp_thread continues to run and indirectly call
gst_rtp_session_send_rtcp. However, the call to rtp_source_reset sets the sent_bye boolean to false, which ends up
causing rtp_session_are_all_sources_bye to return false. This gets passed to gst_rtp_session_send_rtcp and the EOS
event never gets sent.
The race condition results in the EOS event never getting passed to the rtcp_src pad, which prevents the bin and
pipeline from ever completing with EOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3798>
These checks were introduced to prevent exposing ARGB64/RGBA64 in the caps
when running on M1 Pro/Max with macOS <13 because of a bug in VideoToolbox.
Unfortunately, the initial buffer size of 15 is too short when running
in a VM - the CPU brand string there looks like "Apple M1 Pro (Virtual)",
which due to its length causes sysctlbyname to return -1, resulting in
broken formats still showing up in the caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4080>
We did several things to enable the new memory logic in msdkdec:
(1) We always use video memory for decoder in linux path;
(2) We give negotiated pool to alloc_pool stored in GstMsdkContext which
will be used in callback mfxFrameAllocator:Alloc to alloc surfaces as
MediaSDK needs, and this pool is also available for decoder itself;
(3) We modify decide_allocation process, that is we make pool negotiaion
before gst_msdk_init_decoder to ensure the pool is decided and ready for
use in mfxFrameAllocator:Alloc callback; then we will consider the case
when we need to do the gpu to cpu copy.
(4) In gst_msdkdec_finish_task, we modify the way for copy following the
logic in (3).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3439>
Add a pool creation function name as 2 for later use which will create
va pool for video memory in linux and keep system pool for windows.
This gst_msdkdec_create_buffer_pool2 will replace gst_msdkdec_create_buffer_pool
when all the memory allocation modifications are ready in the commits after.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3439>
Rewrite gst_msdk_frame_alloc and name it as xxx_2 before applying it.
It uses negotiated bufferpool stored in GstMsdkContext to allocate buffers
in the callback MfxFrameAllocator:Alloc, then extract VASurface from buffer,
wrap it as mfxMemIDs and pass these IDs to MediaSDK/oneVPL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3439>
The `add_candidate` vfunc of the GstWebRTCICE interface gained a GstPromise
argument, which is an ABI break. We're not aware of any external user of this
interface yet so we think it's OK.
This change is useful in cases where the application needs to bubble up errors
from the underlying ICE agent, for instance when the agent was given an invalid
ICE candidate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3960>
The signal triggers an asynchronous task on the PC thread but in some cases it
can be useful for apps to be notified when the task completed. This method of
the PeerConnection spec also returns a Promise so the interface is now more
coherent with the spec.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3960>
Read and flush console buffer from the console thread immediately,
instead of main thread. Otherwise (if main thread is busy)
the console thread will keep adding idle source and then main thread
will be unresponsive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4067>
The av1decoder class does not implement the ->parse() virtual function,
and we always need to add the av1parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The vp9decoder class does not implement the ->parse() virtual function,
and we always need to add the vp9parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The vp8decoder class does not implement the ->parse() virtual function,
it can only accepts frame aligned data. If some element such as filesrc
feed it with unaligned data, the behaviour is undecided. So we should
set_needs_format of the decoder to TRUE, then it can fail with a
"not-negotiated" error early, rather than go on and generate unexpected
error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The mpeg2decoder class does not implement the ->parse() virtual function,
and we always need to add the mpegvideoparse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The h264decoder class does not implement the ->parse() virtual function,
and we always need to add the h264parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
The h265decoder class does not implement the ->parse() virtual function,
and we always need to add the h265parse element before it. So we should
set_needs_format of the decoder to TRUE, then if no parse before it, it
can fail with a "not-negotiated" error early, rather than go on and
generate unexpected error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4064>
Raw 608 caps can now contain a "field" field. On the input side it
signifies that the input raw 608 is attached to either field 0 or 1,
on the output side it allows selecting whether to extract the raw 608
data for field 0 or 1 for field-aware formats.
In addition, it is also allowed to use ccconverter to "convert" 608
field 0 to 608 field 1 (and conversely), this is passthrough as the
change only needs to happen in the caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4031>
These parameters are not actually `out` parameters but must
be allocated and zero-initialized by the calling function.
Marking them as `out caller-allocates` will cause memory
corruptions when calling these APIs from e.g., Python code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4051>
The dimension of the overlay texture directly corresponds to the size of the overlay **buffer** which is given by its video meta.
The dimension at which the overlay should be displayed directly correspond to the overlay `render_width`and `render_height`.
This match the behavior of glimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4046>
It's only malformed data in APP when its length is less than 6 chars,
because it should have at least an id string. Otherwise, if the id string
is not handled, no warning is raised, only a debug message noticing it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3943>
Fixes the following valgrind error:
==616== Conditional jump or move depends on uninitialised value(s)
==616== at 0x4900E34: gst_debug_print_object (gstinfo.c:1143)
==616== by 0x49010B6: gst_info_printf_pointer_extension_func (gstinfo.c:1215)
==616== by 0x4959FDB: __gst_printf_pointer_extension_serialize (printf-extension.c:47)
==616== by 0x495A487: printf_postprocess_args (vasnprintf.c:258)
==616== by 0x495A52C: __gst_vasnprintf (vasnprintf.c:290)
==616== by 0x4959F8F: __gst_vasprintf (printf.c:154)
==616== by 0x4901C1F: gst_debug_message_get (gstinfo.c:791)
==616== by 0x4901C75: _gst_debug_log_preamble (gstinfo.c:1431)
==616== by 0x4903208: gst_debug_log_default (gstinfo.c:1575)
==616== by 0x49020BA: gst_debug_log_full_valist (gstinfo.c:624)
==616== by 0x490211D: gst_debug_log_valist (gstinfo.c:656)
==616== by 0x49021AD: gst_debug_log (gstinfo.c:533)
==616== by 0x48DDC11: gst_buffer_copy_into (gstbuffer.c:693)
==616== by 0x48DF5F1: gst_buffer_copy_with_flags (gstbuffer.c:727)
==616== by 0x48DF640: gst_buffer_copy_deep (gstbuffer.c:756)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4034>
When the QoS stats are reset (e.g. changing the source) the counters for
dropped + rendered frames are reset to zero which result in negative values
for their difference. This results in max-fps getting pegged at an extremely
high value.
```
fpsdisplaysink.c:373:display_current_fps:<fpsdisplaysink0> Updated max-fps to 36840705952231460864.000000
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3989>
Makes "start-bitrate" work without setting "connection-speed" property. Having
another property set as a requirement for this one to work is unexpected.
This commit allows to request some initial bitrate for first segment, then
go into adaptive streaming for the rest of media playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3895>
When constructing an output profile using --profile-from, it is useful
to be able to override the top level container profile.
Expose a --container-profile option that applies as an override after
other methods for constructing an output profile have run. If no other
method was used, this will result in an empty top level container.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3977>
Instead of creating new decoder instance per new sequence,
re-use configured decoder instance via cuvidReconfigureDecoder()
API. It will make output surface reusable without re-allocation.
Also, in order for application to be able to reserve higher resolution
output surface, "init-max-width" and "init-max-height" properties are
added to each decoder.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3884>
Call input resource map functions (i.e., nvEncRegisterResource,
nvEncUnregisterResource, nvEncMapInputResource, and
nvEncUnmapInputResource) only once and reuse the mapped resources,
instead of per input frame map/unmap
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3884>
Wrap mapped decoder output surface using GstCudaMemory and
output without any copy operation. Also, for application to be able to
control the number of zero-copyable output surfaces,
"num-output-surfaces" property is added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3884>
A data offset with an offset smaller than the moof length is wrong
in smooth streaming streams. The samples will not be located and
eventually playback will error out. So compensate assuming data
is in mdat following moof.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3840>
A data offset with an offset smaller than the moof length is wrong
in smooth streaming streams.
The samples will not be located and eventually playback will
error out. So compensate assuming data is in mdat following moof.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3840>
When uridecodebin exposes pads for its streams, we immediately ghost
the relevant (selected) one and let composition send a seek as soon as a
buffer is probed.
This means that sometimes uridecodebin is still linking elements
internally (for non-selected streams) and sees flush events travel down
the elements it is still busy trying to link / forward sticky events to.
This causes all sorts of nasty issues, which can be avoided by simply
blocking all data flow from the source until no-more-pads has been
emitted by uridecodebin (or whatever sub_element is wrapped).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3971>
This most likely never caused any issues as we don't connect to
no-more-pads in the first place, and the element isn't directly exposed
to the user, but emitting it makes no sense, and we are actually going
to connect to no-more-pads in a subsequent commit.
The call was added in 86b893e54c, a patch
by me in 2013, I have no idea why but I probably didn't have a firm
grasp on what I was doing then.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3971>
this is an issue seen with musl based linux distros e.g. alpine [1]
musl is not going to change this since it breaks ABI/API interfaces
Newer compilers are stringent ( e.g. clang16 ) which can now detect
signature mismatches in function pointers too, existing code warned but
did not error with older clang
Fixes
gstv4l2object.c:544:23: error: incompatible function pointer types assigning to 'gint (*)(gint, ioctl_req_t, ...)' (aka 'int (*)(int, unsigned long, ...)') from 'int (int, int, ...)' [-Wincompatible-function-pointer-types]
v4l2object->ioctl = ioctl;
^ ~~~~~
[1] https://gitlab.alpinelinux.org/alpine/aports/-/issues/7580
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3950>
This fixes a compile error with recent upstream FFmpeg.
The AV_CODEC_CAP_AUTO_THREADS was deprecated and renamed to
AV_CODEC_CAP_OTHER_THREADS in FFmpeg upstream commit
7d09579190de (lavc 58.132.100).
The AV_CODEC_CAP_AUTO_THREADS was finally removed in FFmpeg upstream
commit 10c9a0874cb3 (lavc 59.63.100).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3951>
The encoder does not support reconfiguration, and only deinitializing it
and then initializing it again causes deadlocks.
Also only reconfigure and drain the encoder if the video info has
actually changed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3957>
Fixes#1358.
Passing ARGB64/RGBA64 to vtenc caused the encoding to fail
when running on M1 Pro/Max variants with macOS 12.x, so let's
remove these formats from caps when such scenario is detected.
This issue appears to have been fixed OS-side in macOS 13.0.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3912>
This crept in several years ago sadly :(
The usage of accurate seeking should be reserved to use-cases where it is
essential that we seek to that position. This should not be the default.
There is a new option `--acurate-seeks/-a` to be able to force that.
Furthermore, if accurate seeks aren't required, a player should be using the
GST_SEEK_FLAG_KEY_UNIT flag to seek to the closest keyframe and provide the most
reactive experience.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3926>
This was causing incorrect output when seeking, especially
when used with a multithreaded source like `videotestsrc n-threads=2`.
It should now correctly wait for frames still being processed by VT
while vtdec is flushing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3922>
We are using std::isspace() with one parameter. That function is defined
in the cctype header.
```
win32ipcutils.cpp(34): error C2672: 'std::isspace': no matching overloaded function found
win32ipcutils.cpp(34): error C2780: 'bool std::isspace(_Elem,const std::locale &)': expects 2 arguments - 1 provided
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3933>
When the task already exists, we forgot to free the passed `user_data`.
This wasn't an issue for most C code, which doesn't pass a
`GDestroyNotify`, but bindings such as gstreamer-rs do!
That said, allocating a trampoline in gstreamer-rs just for it to get
thrown away again is awkward. Maybe we need a `gst_pad_resume_task`?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3920>
The av1C box is optional so dropping parsing does not break anything
fundamentally, and there seems to be no historical record how version 0
even looks like while the comments and the parsing disagreed with each
other.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3882>
Since b76d336549
pads are deactivated when going to READY but in `uridecodebin(3)`, the
sources source pads are activated while in NULL state (when PULL mode is
supported), meaning that we are ending up deactivating those pads in
NULL_TO_READY, breaking the pipeline.
The intent of the commit mentioned above is to ensure that the pads are
deactivated either in PAUSED_TO_READY or READY_TO_READY, so it should
be safe to avoid deactivating in NULL_TO_READY.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3849>
Generating the source element is done when uridecodebin is doing the
READY to PAUSED state change, so it is reasonable to set the new source
element to that state.
This also allows detecting early failures with backing libraries or
hardware (checks done in NULL->READY).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3857>
Do not store cached EGL images in GstMemory QData. Instead, use a
per-DmabufUpload GHashTable to store cache entries with a weak
reference to the GstMemory.
This allows two glupload elements on separate tee branches to have
their own EGL image cache. For this pipeline:
gst-launch-1.0 v4l2src ! tee name=t \
t. ! queue ! glupload ! fakesink
t. ! queue ! glupload ! fakesink
this gets rid of the occasional critical error message:
GStreamer-CRITICAL **: 08:26:33.194: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3880>
When using qtdemux in a pipeline that should only work as a pure demuxer (not
for actual playback), qtdemux shouldn't emit new GstSegments to correct
the start time (jump to the future) to ensure that the user experiences no
playback delay. By doing so, it's generating the wrong segments when an append
of data from the past happens. When that happens, downstream elements such as
parsers (eg: aacparse) may clip those buffers laying before the GstSegment and
create problems on the GStreamer client app (eg: WebKit).
Getting buffers clipped out because of the wrong GstSegments started becoming
a problen when this commit was introduced:
ab6e49e9cc audioparsers: add back segment clipping to parsers that have lost it
This clipping makes test DASH shaka 35 from MVT tests[1] to fail in
WebKitGTK/WPE (at least) and can potentially cause a number of other problems
in the WebKit Media Source Extensions (MSE) code.
Note that this new behaviour of not emitting new GstSegments only makes sense
when qtdemux is being used as a pure demuxer and not as part of a regular
pipeline. This is why the variant field has been added. When equal to
VARIANT_MSE_BYTESTREAM, it will make qtdemux behave differently in push mode,
taking decisions that meet the expectations for an MSE-like processing mode.
This kind of tweaks have been done in the past for MSS streams, for instance.
That code has been refactored to use VARIANT_MSS_FRAGMENTED now, instead of
its own dedicated boolean flag.
Co-authored by: Alicia Boya García <ntrrgc@gmail.com>
...who suggested to use "variant: mse-bytestream" in the caps to identify that
mode, as proposed in her unmerged patch:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/467
[1] https://github.com/rdkcentral/mvt
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3867>
The live playlists should be updated at a defined interval. The problem is that
this interval was used *after* the playlist was finally received and processed,
which resulted in a gradual shift happening in playlist updates.
Instead store and use the time at which playlists were requested to determine
when the next one should be downloaded.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
The scanning is done in a reverse order, the proper full checks to do are
therefore:
* If the position is beyond half a "segment duration", it's in the following
segment
* If the position is within the first half of a segment, it's in that one
* If the segment is the first one and the position is within half a duration
backwards, we consider the position as being within that first segment
Also handle the case where a "partial only" segment doesn't have a reliable
duration, and therefore use the playlist target duration instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
The implementation wouldn't work with regular HLS streams (i.e. the final
fallback).
Now that the implementation uses time to search for the starting
segment (instead of just the n-th from the end), we can specify the correct
hold_back fallback value from the RFC
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Avoid a deadlock if a downstream seeking query happens while the scheduler
thread is holding the manifest lock (for example during a seek back to live).
Instead, do a more elaborate fix where the external calls that need access to a
'manifest' access a copy that's updated during a manually triggered manifest
update callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Rename track_dequeue_data_locked() to
gst_adaptive_demux_track_dequeue_data_locked(), since it's non-static.
Make find_stream_for_track_locked() static since it's only used in the main
gstadaptivedemux.c file.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
gst_adaptive_demux2_stream_finish_download() will already schedule another
fragment download if it can so don't fall through to the retry code that will
also try and schedule a download (triggering an assert).
Fix the logic in general to retry advancing into the live seek range once.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When calculating the seek range for a live stream, use the same hold-back logic
as when choosing a starting segment, including low-latency segments if
enabled. Permits seeking closer to the live edge when re-synching or catching
up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing at the live edge of a live playlist, and a download fails, we don't
expect there to be a next fragment. That case is handled lower down anyway, so
don't retry infinitely on spurious http errors at the live edge.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
gst_hls_demux_stream_has_next_fragment() can be called with a NULL
current_segment if we're past the end of the current playlist. In that case,
just return FALSE instead of hitting a critical in the playlist code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing LL-HLS playlists in LL-HLS mode, update the playlist more often (on
the partial segment interval) or else we end up downloading them in bursts and
playing further from the live edge than intended.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing a live stream, make the recommended buffering threshold at most the
hold-back distance from live. If we start 3 seconds from the live edge, there's
no point trying to buffer more - we'll just hit the live edge and have to wait
for more data to be available anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a field to the DownloadRequest that reports the most recent time at which
data arrived. Update it in the DownloadHelper.
Add a method to retrieve the GST_BUFFER_OFFSET() for the DownloadRequest's data
buffer (if any).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
After cancelling a DownloadRequest, the download helper may not do so
immediately, so we can't assert on the in_use flag. Also, since there's no
refcount on the preload hint struct in the download request callback data, make
sure no callbacks will be dispatched when we're going to free the preload hint
struct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Implement fulfilment of HTTP requests from the active preload downloads by
finding any preload request that can provide the requested data and feeding
bytes from the internal DownloadRequest to the caller provided target
DownloadRequest.
Doesn't yet calculate timestamps to make the target request have a sensible
apparent bitrate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add download_request_take_buffer_range() and
download_request_get_bytes_available() methods.
download_request_take_buffer_range() takes bytes from the front of the request
that satisfy the requested start/end byterange, and puts any remaining bytes
back into the DownloadRequest
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a helper that submits and handles blocking preload requests for future
PART/MAP data from live playlists. Add handling in the hlsdemux stream to submit
preload requests when hitting the end of the available segments in a live
playlist.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a flag to hlsdemux to enable or disable LL-HLS handling.
When LL-HLS is enabled and an LL-HLS playlist is loaded, use the part-hold-back
threshold to choose a starting segment.
For live streams that aren't LL-HLS, use the provided hold-back attribute, or
fall back to landing 3 segments from the end.
Make the gst_hls_media_playlist_seek() method able to choose a partial segment
within 2 target durations of the end of the playlist when requested.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Fix an off-by-one in gst_hls_media_playlist_sync_to_playlist() that would ignore
the first fragment in the reference playlist. The error was harmless, since we
expect the reference playlist to be older than the playlist we're
synchronising (so the first/oldest segment in the reference playlist will likely
not exist in the new playlist), so this is just for correctness.
Also fix a segment leak in gst_hls_media_playlist_advance_fragment() when
ignoring the partial_only segment.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a function for synchronising current position with the contents of a
playlist that is specifically for that and can handle synchronising to a partial
segment.
gst_hls_media_playlist_seek() will be used only when performing external seek
requests, to find the best segment or partial segment at which to resume
playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Fixes for stream_time recalculation and handling in partial segments.
Disallow bitrate switching when in the middle of partial segments - only at a
full segment (or right before the first partial segment of a segment).
It's possible but more difficult to switch bitrates in the middle of a partial
segment group, since they are less likely to have aligned keyframes. In any
case, the seek code can't do that right now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
