Now when the buffered list is requested, the tolerance for merging two ranges
when there's a small gap between them is MAX(0.1sec, max frame duration * 2).
Previously it was hardcoded to 0.01sec. The specification suggests that it
could be something like the max frame duration * 2.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
The source buffer currently has a thread for each track that feeds the track
with all data in the track buffer until EOS is reached.
Each pass over the track buffer currently waits for the EOS to appear when it's
done iterating the track buffer which is too restrictive.
When the source buffer reaches the end of the track buffer, it should wait for
any new data to be processed -- not just an EOS -- then check for cancellation
if the deadline expires without new data.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Both operations now work on coded frame groups (GOPs). This simplifies queueing
of video data. There is rarely any point of dealing with individual video frames
when iterating in DTS order, it's most meaningful to decode or delete whole
coded frame groups at a time, so the sample map will now do that when iterating
by DTS. When iterating in PTS order, the existing behavior is preserved since
that is used for informational purposes, not media processing.
A new private boxed type for coded frame groups was added to provide each data
item to the source buffer. Another possible solution would be creation of a new
GstSample representing the whole group by merging all the samples in a group
into a single sample containing a GstBufferList.
Also, start time filtering was removed from the API since gst_iterator_filter()
can be used by callers to achieve the same result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
h265parser defers linking parameter sets until slice header is parsed.
Thus valid SPS/PPS parsed by h265parser can have no linked
parent parameter set. Apply this behavior to
gst_h265_parser_update_{sps,pps} too
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8673>
Fixes an issue where the webrtcbin would hangup when finalizing due
to the sctpenc hanging up when finalizing. This occurred when the
webrtcbin chose to use a sctp association ID already in use.
The sctpenc would fail to reach the paused state, but startup a task
anyways that was never stopped.
This commit modifies the behavior to not choose sctp association IDs
randomly, and instead only choose one that is free. It also prevents the
sctpenc from starting up that task if it fails to reach the paused state.
Fixes: #4188
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8607>
VT supports changing properties on the fly, and old code attempted to
support that. Perhaps 10 years ago that worked, but these days
VTSessionSetProperty will always wait for the output callback to finish
before proceeding. This means that it's very prone to deadlocking, as
property setters will take the object lock, the callback thread will
take the stream lock, and the main (streaming) thread attempts to take
both, resulting in a deadlock.
New version uses something similar to other encoders (e.g. x264enc) -
changing a property when a session is already created will just flag it
to be reconfigured upon the next encode call. This is done in similar
fashion to how restarting the session upon an error works.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8597>
According to the UVC 1.5 specification, section 4.1.2, the GET_INFO request
must return a bitmap indicating supported operations for the control.
Value 0x00 indicates that neither GET nor SET operations are supported.
This patch fixes control handling in the UVC gadget implementation to properly
respond to GET_INFO requests with the correct bitmap, allowing host systems
to properly detect supported control operations (none in this case).
The pipeline I'm using to test this is:
gst-launch-1.0 videotestsrc ! uvcsink v4l2sink::device=/dev/video0
This is the equivalent of [0] but the difference is that we are now returning
0x00 instead of 0x03.
Without this change the host in my case is unable to probe the UVC gadget at
all, automatically disconnecting the device after a few seconds.
Following is the log when the gadget is not working (without this fix):
usb 1-1.2: new high-speed USB device number 73 using xhci_hcd
usb 1-1.2: New USB device found, idVendor=0525, idProduct=a4a2, bcdDevice= 5.15
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: UVC Gadget
usb 1-1.2: Manufacturer: localhost.localdomain
usb 1-1.2: SerialNumber: 0123456789
usb 1-1.2: Found UVC 1.10 device UVC Gadget (0525:a4a2)
usb 1-1.2: Failed to query (GET_INFO) UVC control 2 on unit 1: -110 (exp. 1).
usb 1-1.2: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
uvcvideo 1-1.2:1.1: Failed to query (129) UVC probe control : -71 (exp. 34).
uvcvideo 1-1.2:1.1: Failed to initialize the device (-71).
cdc_subset 1-1.2:1.0: probe with driver cdc_subset failed with error -22
cdc_subset 1-1.2:1.1: probe with driver cdc_subset failed with error -22
usb 1-1.2: USB disconnect, device number 73
With the fix the USB device is correctly probed:
usb 1-1.2: new high-speed USB device number 88 using xhci_hcd
usb 1-1.2: New USB device found, idVendor=0525, idProduct=a4a2, bcdDevice= 5.15
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: UVC Gadget
usb 1-1.2: Manufacturer: localhost.localdomain
usb 1-1.2: SerialNumber: 0123456789
usb 1-1.2: Found UVC 1.10 device UVC Gadget (0525:a4a2)
[0] camera/uvc-gadget@0df9d3ad
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8572>
All decoders have the same design pattern in decide allocation
and forgot to release sink allocator before allocating a new one.
Fixing the memory leak by clearing sink allocator before creating
the new one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8583>
Extensions can have a minimum set of dependencies (e.g. API version) and may
also be promoted to core in a later version. Don't explicitly enable extensions
that fail to meet their requirements or that have been promoted to the core API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
The instance API version supported may not be of the same version supported by
the device. It is possible that the function that is returned may be non-0
but not functional due to the requested API version of the instance limiting the
availability of calling the returned function.
Can be reproduced by running a pipeline with GST_VULKAN_INSTANCE_API_VERSION=1.1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
Since Vulkan 1.1, the requested API version is the maximum API version that the
application is expecting to use. It is also possible for individual devices
(backed by potentially different drivers) may support a higher or lower API
version than the instance. Both cases (higher and lower) should be supported
and as such, it is not an error to request an API version that is larger than
the instance supported API version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
If the vulkan plugin was compiled against a newer version than the supported
vulkan runtime instance or device, then it was possible for format retrieval to
fail. Failure was due to unconditionally using newer extensions and features
without runtime checking them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
The API version exposed by a particular device can be completely different from
what is exported by the parent instance. Since Vulkan 1.1 it is also possible
to use newer device API than supported by the instance API version (with the
appropriate version checks).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8554>
Using #if instead of #ifdef was causing some issues when cross-compiling, like:
../ext/curl/gstcurlsmtpsink.c:54:5: error: "HAVE_SYS_SOCKET_H" is not
defined, evaluates to 0 [-Werror=undef]
54 | #if HAVE_SYS_SOCKET_H
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8589>
If a plugin gets disabled due to a `disabler()` dependency, the plugin
docs build itself will get disabled because `all_plugins_paths` will
become a disabler.
This was actually happening with opencv on systems that don't have
opencv available, and could happen with libsoup too if the build files
change in the future.
Let's avoid wasting hours of debugging for people. A not-found
dependency has the same effect.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8582>
