Aiming at fixing a rare race condition where we get:
../subprojects/gstreamer/libs/gst/check/gstcheck.c:1258:F:nlecomposition:test_seek_on_nested:0: nested_src0_0x1a1a310 is not destroyed, 1 refcounts left!
The idea is that there might have a remaining GstMessage
with the nested_src as `message.src` on the bus that has
yet to be processed in some conditions leading to a reference
still existing when unrefing the pipeline.
Subprojects simply consist of adding the GESProject
to the main project asset list. Then those are recursively
serialized in the main project in the <asset> not, when deserializing,
temporary files are created and those will be used in clips
as necessary
Otherwise if we shutdown a composition whith an nested composition
(inside a source in the test) and leak it, we end up with the nested
composition task still running (in READY) which is bad.
Add a test for that which leaks the pipeline on purpose.
This is implemented on top of a Tree that represents the whole timeline.
SourceClips can not fully overlap anymore and the tests have been
updated to take that into account. Some new tests were added to verify
that behaviour in greater details
Each timeline element is in a layer (potentially spanning
over several), it is very often useful to retrieve an element
layer priority (from an app perspective more than the element
priority itself as that is a bit of an implementation detail
in the end).
Port tests to it
Auto transition when having 3 overlapping clips in a same point in the
timeline is not supported as we can't handle it in a nice way. Before we
to avoid creating 2 overlapping transitions (which is plain broken in
NLE) were completely disabling `auto-transition` and removing all
auto-transitions in the timeline but this is pretty weird for the end
user. This commit changes and now makes sure 2 transitions are not
created in the same place.
Also cleanup previous test case.
And start handling relocated assets.
Also expose the discoverer callback as a vmethod so that we can
overridde the discoverer when necessary (to handle discovering of
timeline through gesdemux for example)
When removing an effect from a clip, first the notify::priority signals
were being emitted for the remaining effects which changed priority, and only
at the end the child-removed signal. Now the child-removed signal is emitted
first.
Marking them as children properties and properly allow serializing
clips children properties.
This doesn't handle several TrackElement of a same type with
different property values but this require more worked already
marked as fixme to allow specifying full path of elements in the
children properties API.
See https://gitlab.gnome.org/GNOME/pitivi/issues/1687
Implementing it in the overrides as PyGObject won't be able to properly
convert python values to GValues in some cases. Using
g_object_set_property works as some logic is implemented inside
PyGObject for that particular case. This is a "regression" due
to https://bugzilla.gnome.org/review?bug=769789&attachment=348766 were
we end up with an OverflowError while setting G_TYPE_UINT children
properties.
In the (now tested) scenario where we have a transition on the right
side of a clip we are splitting, auto transitions can't be created
because we resize the clip after adding the new one, meaning that
there are 3 elements in the "transition zone", we need to force
auto transition creation after the splitting.
Fixes https://gitlab.gnome.org/GNOME/pitivi/issues/2142
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
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
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
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
