Install properties at the given offset as intended instead of at 0.
Currently there are no elements with any properties, so this has no
effect. This change is needed if any element adds properties in the
future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9179>
This is for cases where:
* We *do* want to refer to the PCR stream to figure out global positioning, gap
detection, wrapover correction.
* But we do not want to apply any skew correction to the output
This is useful for cases where:
* the input stream has already been clock-corrected (for example with
mpegtslivesrc)
* or where the output doesn't require synchronization against a clock (ex: for
storage)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9301>
Docker/oci and thus gitlab-runner, default to a root
user inside the namespace, even if its an unprivileged
one.
This can cause issues and let permission bugs sneak in,
as we are functionally root when running the build.
Switch the build jobs to run with our new "containeruser"
so we avoid much of it.
Our user is still in the wheel/sudo group but that's fine
as long we don't elevate the privileges unintentionally.
Noticeably for the time being, we will need to chown the
CI_PROJECT_DIR checkout as the gitlab runner might try
to reuse pre-existing and cached volumes of the project
checkout.
Additionally we need to change the ccache path, so we
will avoid the existing cache owned by "root".
Close https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2433
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8763>
We are currently running pip as root which will cause it
to install into /root/.local cause it wants to do a user install
Set the user-base in the gloabl config, /etc/pip.conf, so pip will
both install there and subsequently look there if we invoke it
from any other user.
This makes pip install ofc require elevated permissions, as it
will be writting into /usr/local from now on
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8763>
Create a file we can check at runtime, and identify if the
environment we run against is one of our CI build images.
Useful mostly for our internal scritps so we can match against
metadata rather than heuristics, ex. if /subprojects exists
Conceptually similar to /.flatpak-info
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8763>
- Add case where we have element in subset that are equal to element in
superset. In this case subset is still a subset if at least one element is a
subset of the corresponding element in superset.
- clarify gst_value_is_subset inline documentation
- Add helper VALUE_TYPE_SINGLETON (type) to identify GType that represent a
value that is not a collection.
- Fixed issue in gst_value_is_subset_array_array (<1, 2, 3>, <0, 1, 4, 2, 3>)
would have returned TRUE because because the alignment of the subset could be
done multiple times. Now once alignment of set as been done once, everything
else in the superset need to be a subset of corresponding element without
interuption. is_subset (<1, 2, 3>, <0, 1, 2, 3>) => TRUE, but is_subset (<1,
2, 3>, <0, 1, 4, 2, 3>) => FALSE.
- If both array are fixed value and we perform a is_subset on them, both value
can't be equal to be considered subset. (For consistency with other fixed
values)
- Define gst_value_subtract (singleton, array) and
gst_value_subtract (array, singleton), to allow a gst_value_is_subset
(singleton, array) and gst_value_is_subset (array, singleton). General
case of gst_value_is_subset (v1, v2) use gst_value_subtract (v1, v2) and
gst_value_subtract (v2, v1) to evaluate _is_subset(), therefore we need these
for is_subset() operation that involve singleton and array.
Note gst_value_subtract (array, array) is not implemented but this case is not
require by gst_value_is_subset () and as it has a direct handling. Warned if
the case is used.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9220>
When doing direct dmabuf upload, we rely on the GL stack for doing the color
transformation. The caps we transform from GL to DMABuf are always with a format
of RGBA. Instead of listing all GstVideoFormat and translating them back into
DRM formats, simply list all supported DRM format for the context.
This enable rendering DRM formats that don't have an shader based emulation
implemented such as NV15.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9306>
The transformation was fuzzy, adding random modifiers to the list. Use the newly
introduce helpers from 1.26 to precisely convert GStreamer formats to a DRM
fourcc and modifier pair and vice-versa.
This fixes support for formats that have a GstVideoFormat value and requires a
modifier.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9306>
It is not possible to do frame cropping when DMABuf caps feature is negotiated.
The VideoInfo size is zero, resulting in empty destination buffers, and video
convert library may not understand what the format actually is.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9305>
If the conformance window does not requires cropping the top or left of the
window, we can use GstVideoMeta to crop in a zero-copy fashion. If a copy
is needed, the frame copy can also handle it, and is a lot faster.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9305>
Similar to what qtdemux does in `gst_qtdemux_stream_update_segment()`,
in which case we want to resend tags according to our position.
By setting the changed flag for all stream tags we ensure they will all
be (re-)send as we progrees.
This notably ensures that rotation tags are not lost when video players
finish playback and jump back to the beginning of a video.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8429>
