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>
Fixes race when a live stream finishes playing all segments from a
dynamic manifest and waits for its update. If the manifest meanwhile
changes from dynamic to static and this update is received
asynchronously, periodic calls of gst_adaptive_demux_manifest_update_cb
will stop. As a result the blocked stream won't get notified about the
updated manifest and will remain stuck indefinitely.
Also removed the wake-up code from gst_adaptive_demux_manifest_update_cb
where it remained as a relic from previous implementation when manifest
updates were synchronous.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8587>
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>
The stream was keeping a reference to the sink, preventing
it to be removed properly by the pipleline bin.
Clean up and simplify the code to get the stream from the pad.
Add more mutex protection against add/remove requested pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7916>
This change ensures that the `GST_EVENT_EOS`,
`GST_EVENT_FLUSH_START` and `GST_EVENT_FLUSH_STOP`
events are forwarded to the sink downstream.
The logging message for `GST_EVENT_FLUSH_START`
has also been fixed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8576>
.. which caused the gstreamer_sharp_abi unit test to fail.
GstAudioRingBuffer has segdone and segbase as struct fields and
a get/set API with the same name but different types. The fields
have been deprecated and are no longer used now, and they need to
be hidden and we also need to rename them so that the generator
does not mix types (the setter/getters use guint64 but the fields
have gint types, which caused some type confusion in the generator).
Co-authored by: Andoni Morales Alastruey <ylatuya@gmail.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8541>
Otherwise if GStreamer is checked out inside a directory that
has a `Cargo.toml` file, building fails with:
```
error: current package believes it's in a workspace when it's not:
current rust-project/gstreamer/subprojects/gst-devtools/dots-viewer/Cargo.toml
workspace rust-project/Cargo.toml
This may be fixable by adding `gstreamer/subprojects/gst-devtools/dots-viewer`
to the `workspace.members` array of the manifest located at: rust-project/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude`
array, or add an empty `[workspace]` table to the package's manifest.
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8562>
