Add a pre-commit hook that automatically checks if GES children properties
documentation is up to date when GES source files are modified. The hook
runs the document-children-props.py script and warns if the generated
documentation files have changes that need to be committed.
This ensures that children properties documentation stays synchronized
with code changes and prevents outdated documentation from being merged.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5987>
The script was failing with newer pygobject versions because the
__enum_values__ attribute has been removed. Updated to use proper
introspection by:
- Getting enum type from property default value
- Using enum_class.values for the first enum value (index 0)
- Creating other enum values with enum_type(i) constructor
- Extracting name and nick from enum values properly
Also fixed ruff linting issues:
- Removed unused imports and variables
- Used specific exception types instead of bare except
- Added noqa comment for gi import ordering
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5987>
For the features VkPhysicalDeviceSamplerYcbcrConversionFeaturesKHR,
VkPhysicalDeviceSynchronization2Features and
VkPhisicalDeviceTimelineSemaphoreFeatures
The Vulkan specification states:
If the `VkPhysicalDeviceXXXFeatures` structure is included in the `pNext`
chain of the `VkPhysicalDeviceFeatures2` structure passed to
`vkGetPhysicalDeviceFeatures2`, it is filled in to indicate whether each
corresponding feature is supported. If the application wishes to use a
`VkDevice` with any features described by `VkPhysicalDeviceXXXFeatures`,
it **must** add an instance of the structure, with the desired feature members
set to `VK_TRUE`, to the `pNext` chain of `VkDeviceCreateInfo` when creating
the `VkDevice`.
And that was missing in the code.
Strangely, that functionality doesn't have a Valid-Usage ID assigned, so it
isn't caught by the validation layer.
This patch adds the structures in the physical devices to get them and later set
them in the device creation.
In order to link these features, videomaintenance1, and others to come, without
knowing if Vulkan 1.3 features are chained in the device properties structure, a
static and inlined function was added in gstvkphysicaldevice-private.h. It was
added in a header file to avoid compiler warnings if it's not used because of
old Vulkan headers.
Also the value dump videomaintenance1 was moved to another function to pack
there all these queried features.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9483>
If there is only unknown stream-type streams in the current collection
don't post an error straight away. This fixes a problem with RTSP
cameras and legacy upstream collection building, if the first
stream that rtspsrc outputs is the ONVIF metadata track. That
happens often on bandwidth-constrained camera inputs, as the
video and audio will naturally take longer to arrive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9433>
Launch-lines will be pasted into a shell, and `gst_value_serialize()`
yields strings that will likely be interpreted by the shell. For
example:
`gst-launch-1.0 ... ! osxaudiosink unique-id="AppleUSBAudioEngine:BEHRINGER:UMC202HD\ 192k:12345678:1\,2"`
The shell will remove the double-quotes `"` but keep the `\ ` which
means the output of `gst_value_deserialize()` will not be the original
string, and the launch line will not work.
So let's use `gst_value_serialize()` only if the string is non-ASCII,
and if it's ASCII and needs quoting, we do some shell quoting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9466>
VA encoders, at reconfiguration, have to check if the rate-control was changed
by the user, but since user parameters setting are in another thread, the
comparison was racy.
This patch locks the object to compare the current rate-control with the one set
by the user.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9480>
Make it work a little more like RTP. Have the source interact with the
clock and set the capture time on each packet. Then the other elements
can use that to do adjustments. Since AVTP is always very low latency,
it can be assumed that the gPTP clock at the packet reception is very
close to the sending time, never more than 2 seconds off, so the
timestamps can be compared directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9412>
Caps may change the framerate used and the frame counting approach for
timestamps, needs to account for this by taking a snapshot of the current frames
and running time to add to all subsequent produced frames. Code is mostly taken
from videotestsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9455>
