These tests expose some of the new editing behaviour in timeline
tree. In particular, we test:
+ edits for clips within groups within a group
+ that an edit can succeed if a snap allows it to
+ that snapping occurs at a specific point, and that we alternate
between one call to snapping-started and one call to snapping-ended
with corresponding values
+ that an edit can fail if a snap causes it to
+ no snapping is released when an edit fails
+ We tests for the expected changes, and otherwise check that the
configuration of the timeline has remained unchanged
+ The timeline configuration remains the same when an edit fails
+ That each clip overlap has a corresponding auto-transition
+ That particular auto-transitions are created when a new overlap is
formed
+ That particular auto-transitions are destroyed when an overlap ends
+ That auto-transitions are not replaced when two clips move but
maintain their overlap
+ That the timeline does not contain any unaccounted for clips
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Only emit snapping-ended if we have a valid snap time. Moreover, we
should emit a new snapping-started even if we are snapping at the same
location. This is because a new snap will always correspond to a new edit,
possibly involving different snapping elements, which a user would want
to know about.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Editing has been simplified by breaking down each edit into a
combination of three basic single-element edits: MOVE, TRIM_START, and
TRIM_END.
Each edit follows these steps:
+ Determine which elements are to be edited and under which basic mode
+ Determine which track elements will move as a result
+ Snap the edit position to one of the edges of the main edited element,
(or the edge of one of its descendants, in the case of MOVE), avoiding
moving elements.
NOTE: in particular, we can *not* snap to the edge of a neighbouring
element in a roll edit. This was previously possible, even though the
neighbour was moving!
+ Determine the edit positions for clips (or track elements with no
parent) using the snapped value. In addition, we replace any edits of
a group with an edit of its descendant clips. If any value would be
out of bounds (e.g. negative start) we do not edit.
NOTE: this is now done *after* checking the snapping. This allows the
edit to succeed if snapping would cause it to go from being invalid to
valid!
+ Determine whether the collection of edits would result in a valid
timeline-configuration which does not break the rules for sources
overlapping.
+ If all this succeeds, we emit snapping-started on the timeline.
+ We then perform all the edits. At this point they should all succeed.
The simplification/unification should make it easier to make other
changes.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/97
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/98
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Previously, the code was not able to detect that an element overlaps on
its end, nor could it detect that an element overlaps two elements that
already overlap.
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.
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
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
