Rename the private "owners" to "creators" to avoid confusing this with
the owner of the track element's memory.
Also made the ungroup method for GESClip symmetric by making all the
children of the resulting clips share their creators, which allows them
to be added to any of the other ungrouped clips. Once the clips are
grouped back together, the tracks loose these extra creators.
Refactoring GESVideoSource so that #GESUriVideoSource can handle
still image in a simple way
MultiFileSource has been replaced with the new `imagesequencesrc`
element, this was totally broken anyway as `multifilesrc` can not seek
properly.
We were implementing the logic for moving/trimming elements specific
to SourceClip but this was not correct ass the new timeline tree allows
us to handle that for all element types in a generic and nice way.
This make us need to have groups trimming properly implemented in the
timeline tree, leading to some fixes in the group tests.
This adds tests for the various cases known to not be handled properly
by the previous code.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/92
In the test_timeline.test_auto_transition, the corresponding xges only
has one layer, so we should only expect one layer when we extract the
timeline. This fixes a change that was missing from commit
d3e2cf55e3
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
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
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
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
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
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
And reuse the same previously created element when adding the clip
back to a layer, avoiding losing all setting done on clip children
in that situation
This is a behaviour change but previous behaviour was actually totally
unexpected and people working around that weird behaviour will moste
probably not care about that change
Differential Revision: https://phabricator.freedesktop.org/D1094
