The documentation states that it returns a (transfer full) list
of GESClip but it was returning a (transfer container) list. Make
sure to actually make it (transfer full).
https://bugzilla.gnome.org/show_bug.cgi?id=793874
.. and tighten check for disabled gst debugging sytem.
add_global_arguments() can't be used in subprojects. It's
entirely possible that ges is a subproject but gstreamer
is picked up from an installed location, so we should
really use add_project_arguments() in both cases.
WARNING: Trying to compare values of different types (str, int).
The result of this is undefined and will become a hard error
in a future Meson release.
We have an optiominisation to avoid double seeks when a seek is passed
the end of the current stack. The problem, is that we no longer flush
the pipeline when this code is reached. This patch comments out this
optimization adding a FIXME. As mention, flushing the stack instead of
seeking would work, but does not seem trivial considering all the
mechanic inplace to forward or not the events.
https://bugzilla.gnome.org/show_bug.cgi?id=787405
The allocation query may block on the sink when in pause. As a side effect, we
may never get a buffer now that tee does forward the allocation query.
This would often lead in a pipeline stall.
https://bugzilla.gnome.org/show_bug.cgi?id=787405
When setting a new control binding on a track element, the old control
binding (if any) is going to be removed. Make sure the
"control-binding-removed" signal is emitted in this case.
Fixes https://phabricator.freedesktop.org/T7340#95666
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D1842
In playsink the default video queue max size is 3 buffers, which is
sometimes not enough for our use case.
Allow up to 2 seconds of buffered data, giving us more time to do
the transition between clips, and thus avoiding dropping frames in
the sink when bringing up new clip takes too much time.
Differential Revision: https://phabricator.freedesktop.org/D1854
We need to iterate over the previous element from trackelement_iter
to find the first element that is at the moving point. Several
elements can have the same start as the one initiating the move,
and we need to take all of them into account.
Fixes https://phabricator.freedesktop.org/T7819
