The GST_TRACER_POOL_BUFFER_(DE)QUEUED macros used when tracer hooks are
disabled took only one argument, causing compile errors when building
with tracer hooks disabled.
Change-Id: I0958c0b018f1fc4a6d84ab0bdd9e42895ae1fe77
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8638>
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>
v4l2object->ioctl can either be set to v4l2_ioctl() or ioctl().
v4l2_ioctl() always takes the request number as unsigned long int, but ioctl()
may take (at least) unsigned long int, int, or unsigned, depending on libc.
This means that there isn't one function pointer type that can be used for
v4l2object->ioctl that will always be able to accomodate being set to either of
v4l2_ioctl() and ioctl(). It's therefore necessary to wrap one of them so that
both options can have the same type. This fixes an assignment from incompatible
pointer type error when building for musl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8613>
It's not used by anything in the monorepo, only used when
rebuilding the gstreamer-rs image (used by gst-plugins-rs
where the gtk4 plugin lives).
Doesn't make sense to build all of gtk4 on every CI run that
touches the relevant files just to make sure it still works
for the image rebuild, and it's a problem for users with long
filenames (such as `gstreamer-backport-bot`) where the pipeline
will simply not pass because the gtk glib-mkenums command line
length exceeds 32767 characters.
Better to set up a scheduled pipeline for that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8636>
This reverts commit dcd11f0a104964f7fc02c38104ed57fd0aa794a2.
In dcd11f0a104964f7fc02c38104ed57fd0aa794a2 we started making use
of gitlab's changes:compare_to in hopes of addressing #3780
However compare_to seems to have different behavior based on:
* The type of the branch
* If the repo is a fork or not
* If the pipeline is a branch or MR pipeline
* If the commit is force pushed or not
* If the pipeline is associated with a "push" event,
* Manual and scheduled pipelines are not.
If we leave compare_to underfined and to its default value,
it causes issues with branch pipelines, as:
* If you push a new branch, it doesn't have anything to compare
against and changes: either will trigger or not, depending on the
gitlab version
* If you push to an existing branch, it only compares against the
previous commit.
* if you force push to a branch, it doesn't work at all it seems. [1]
Thankfully for merge request pipelines, it always seems to compare
against the Merge Request Target tree. But also if there is a Merge
Request open, and the value of compare_to isn't defined (say if it's a
force push or it's the first branch pipeline of the branch) it will
fallback to using the tree from the Merge Request Target, making it even
more confusing.
But if we try to overide it to fix the behavior for branches, we end up
breaking merge request. There seems to be a bug in gitlab (unclear if
its intended or not) where if you have access to the upstream
repository, gitlab will compaee_to against that in the MR pipeleine, but
otherwise it will try to compare against your fork's branch which will
certainly be outdated. Additionally it didn't seem to error out if the
branch specified doesn't exist only in one of the two places so its very
hard to reverse engineer the behavior.
[1] https://gitlab.com/gitlab-org/gitlab/-/issues/349694
Long story short, this is way more complicated than its worth, and has
caused a lot of issues since it was introduced. Revert the change and
try again another time.
Related https://gitlab.com/gitlab-org/gitlab/-/issues/389808Close#3965
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8563>
`parsebin` is potentially added by a `typefind` callback.
That `typefind` was activated by a `READY_TO_PAUSED` state change on `urisourcebin`
We want to ensure that it is the "setup_parsebin_for_slot" method that activates
the underlying `parsebin`, and not the external state-change.
Otherwise we would risk a potential deadlock where elements activating in
`parsebin`, and which would cause the upstream `typefind` to switch scheduling
mode, would not be able to acquire the STREAM_LOCK of the `typefind` task.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8511>
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>
