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>
When the driver prefered format is not picked by downstream, the
decoders needs to select another format from the list. The selection
was currently unsorted, resulting in 10bit data often being stripped
to 8bit.
To solve this, reorder the formats in an HW preference order. This order
deviates slightly from the preferred order in libgstvideo. This is to
prefer bandwidth saving over better CPU alignment. As an example NV15 is
prefered over P010. We also prefer tiled over linear.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8522>
Add new property to support application allocated GstCudaMemory.
CUDA memory alloc/free is a global device synchronization point
as if launching CUDA kernel on default CUDA stream. To avoid the global
synchronization, we added stream-ordered allocation support
which allocates CUDA memory asynchronously.
However, NVENC does not allow registering the stream-ordered
allocated memory. Thus encoder was allocating normal CUDA
memory in case that input CUDA memory is stream-ordered type.
In this commit, newly introduced property will allow application
to provide encoder with GstCudaBufferPool. Application can
preallocate sufficient amount of CUDA memory in advance
to avoid global device synchronization while pipeline is running.
For now, this pool is used only if input CUDA memory is allocated
via stream-ordered-allocation
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8516>
As per the C++ standard, any usage of a std::set::iterator after it has
been erased from the collection results in undefined behaviour. This has
resulted in application crashes due to CUDA illegal address errors.
This commit fixes the issue by copying and incrementing the iterator
within any for-loops that also invoke std::set::erase.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8472>
When the stream resolution change it is needed to negotiate
a new pools and to update the caps.
Resolution change could occurs on a new sequence or a new
picture so move resolution change detection code in a common
function.
Only call streamoff if the resolution occur while decoding a key frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8064>
