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
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
With two exceptions:
* ges_clip_create_track_elements_func
* ges_uri_clip_set_uri
which were never declared in headers and should always have been static.
They are handled specially when moving the context and having them
part of the context can lead to weird behaviours.
Fixes https://phabricator.freedesktop.org/T7693
The following implementation details where exposed as public symbols:
- _ges_container_get_priority_offset
- _ges_container_set_height
- _ges_container_set_priority_offset
- _ges_uri_asset_cleanup
but it was not correct and that should never have been used outside
GES.
Moving those declarations to the internal header and marking as
internal.
GstDiscoverer objects were leaked by tests making the leaks detector
unusable.
Introduce ges_deinit(), similiar to gst_deinit(), doing some cleanup
before exiting the process.
https://bugzilla.gnome.org/show_bug.cgi?id=776805
We were using the actual mixer pad to release the smart mixer
pad, which seemed to be on purpose, but was not properly handle,
moreover, it is now forbiden to pass a pad not inside a GstElement
when releasing it.
Also properly remove ghost pads from Smart mixer, we were planly
failling at it.
It was making no sense to loose the information about the pspec itself
to retrieve the child associated to it and was failling when we were
forcing the AssociateType::prop synthax
The underlying integer type for enums are implementation defined and may
not be the same size as gint/guint. So implicitly casting from pointers-
to-enum-types to pointers-to-int-types is unsafe. MSVC warns on these.
https://bugzilla.gnome.org/show_bug.cgi?id=774641
In some cases when rippling clip we could get the algo lost because
a transition existed between two clips (for example at the end of c1
and at the begining of c2) but while rippling it would have required
a transition at the end of c2 and beginning of c1, and we were properly
not destroying the old one (as the two clips were in the moving context)
but we were still creating the other transition in the end...
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1362
We set TrackElement track type very early when creating effects
so it now uses that information to find TrackElement in clips
by track type.
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1370
Computation was not taking into account the fact that the start of
the element being moved could be at the middle of a group and not
necessarily at the start!
Fixes T7544
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1282
We were only concidering that we should let the group handle moving
transitions when changing transitions but in fact as soon as a
transition is happenning between two clips that are in a same group
the group properly handles moving the transition, so let the
group do its job.
Fixes T7543
Differential Revision: https://phabricator.freedesktop.org/D1281
GESLayer is now responsible for setting clips priorites. Also
GESClip top effects priorities are now set by the
ges_clip_set_top_effect_index method, the user should never call
ges_timeline_element_set_priority as it will anyway be overriden
by GES itself.
Differential Revision: https://phabricator.freedesktop.org/D1280
All operations should have higher priorites and sources should be
on top of those. We now first set the operations priorities in
a first pass and then stack sources on top of those.
Differential Revision: https://phabricator.freedesktop.org/D1279
In case effects have been added priorites might become wrong,
but until the timeline is not commited, it does not matter.
Make sure all priorities are correct before commiting compositions
Differential Revision: https://phabricator.freedesktop.org/D1277
Fix all tests as we now have 1 priority inside the layer
dedicated to transitions (basically no source clip will
ever have a priority of 0 inside a layer).
Differential Revision: https://phabricator.freedesktop.org/D1276
And simplify the way we start computing children priority
making min_priority already relative to the clip itself.
Differential Revision: https://phabricator.freedesktop.org/D1275
Had to separate timeline_emit_group_added from timeline_add_group
to avoid emitting group-added when the project is being loaded.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D1302
