`gst/analytics/analytics.h` includes `gst/analytics/gstanalyticssegmentationmtd.h`,
which in turn `gst/video/video-info.h` but `gst-video-1.0` was only listed
in `Requires.private` field of `gst-analytics-1.0.pc`.
This would cause projects linking against `gst-analytics-1.0.pc` to fail to find
the headers when using alternative interpretation of pkg-config specification
that only considers private dependencies for include path during static builds,
such as the case e.g. on Nix.
https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/28
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8661>
The position is no longer duplicated across each pad and pad's segment. The
position is now only updated if it changes in the direction of playback so that
quickly repeated forward seeks do not cause the stream to seek from 0.
Reverse playback is expressly disallowed and an unnecessary extra flush of track
when seeking was removed.
A background task was added to periodically check on the current position and
the media source's buffering levels to keep the ready state up-to-date. The
source buffer no longer needs to trigger this update, it will happen whenever
the element state is READY or higher.
Finally, added proper error reporting when failing to push a buffer and improved
debug logging.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Since the sample map/track buffer now iterates samples in batches corresponding
to each coded frame group, the logic to feed the tracks is simpler. For media
without delta frames, it's a special case where the coded frame groups are all
size 1.
Now, all it does is skip data until the keyframe group containing the seek point
is found, then feed the track queue with the current sample and all future
samples until EOS or cancellation.
Resync of the iterator when the underlying track is modified is not necessary
because the outer loop attempts to resume feeding track data from where it was
interrupted in case of modification.
Also, the track feed task struct now holds a weak ref to its parent source
buffer to allow the task to cancel itself in any situation where the source
buffer is destroyed before the task is shut down.
Media parsing activity in the append pipeline no longer triggers ready state
recalculation on the msesrc since the msesrc now has a background task that
updates the ready state periodically when it's active which is more efficient in
cases where there is a high volume of samples being processed by the media
parser.
Finally, updated to adapt to track buffer API changes. Some functions previously
passed in a lower bound for sample timestamps. Now the source buffer is
responsible for clipping samples within a desired range of time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Now when the buffered list is requested, the tolerance for merging two ranges
when there's a small gap between them is MAX(0.1sec, max frame duration * 2).
Previously it was hardcoded to 0.01sec. The specification suggests that it
could be something like the max frame duration * 2.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
The source buffer currently has a thread for each track that feeds the track
with all data in the track buffer until EOS is reached.
Each pass over the track buffer currently waits for the EOS to appear when it's
done iterating the track buffer which is too restrictive.
When the source buffer reaches the end of the track buffer, it should wait for
any new data to be processed -- not just an EOS -- then check for cancellation
if the deadline expires without new data.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
Both operations now work on coded frame groups (GOPs). This simplifies queueing
of video data. There is rarely any point of dealing with individual video frames
when iterating in DTS order, it's most meaningful to decode or delete whole
coded frame groups at a time, so the sample map will now do that when iterating
by DTS. When iterating in PTS order, the existing behavior is preserved since
that is used for informational purposes, not media processing.
A new private boxed type for coded frame groups was added to provide each data
item to the source buffer. Another possible solution would be creation of a new
GstSample representing the whole group by merging all the samples in a group
into a single sample containing a GstBufferList.
Also, start time filtering was removed from the API since gst_iterator_filter()
can be used by callers to achieve the same result.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8512>
h265parser defers linking parameter sets until slice header is parsed.
Thus valid SPS/PPS parsed by h265parser can have no linked
parent parameter set. Apply this behavior to
gst_h265_parser_update_{sps,pps} too
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8673>
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>
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>
This patch refactors gst_wl_display_callback_destroy() to use the
recently introduced gst_wl_display_object_destroy() helper. Previously,
the function manually handled wl_callback destruction with explicit
lock/unlock calls and direct invocation of wl_callback_destroy().
Switching to gst_wl_display_object_destroy() unifies the destruction
process across similar objects, reducing code duplication and potential
errors.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8242>
when received xdg config event fron wayland server,
gst_wl_display_thread_run will call handle_xdg_surface_configure
which protected by priv->sync_mutex.
and in handle_xdg_surface_configure, configure_mutex also is locked
but if waylandsink set state from paused to ready, that will dispose
wlwindow, which will try to clear configure_mutex, and try to destroy
xdg_surface,
that do not proteced by anything.
so, problem is:
1) if clear configure_mutex(with locked state), clear lock will abort
2) after xdg_surface destroy, handle_xdg_surface_config may still call
ack_configure, that will lead wayland server go wrong
so, this patch updates gst_wl_window_finalize to use the new
destruction function for xdg_toplevel and xdg_surface, ensuring all
destruction operations are properly synchronized.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8242>
The parent class will allow the handle to be reused at the end of the function.
If we are still modifying the released fence, then another thread can acquire
the fence while we are still clearing some of its data and produce a data race
or a leaked fence depending on which thread wins.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8491>
