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.
Export GES library API in headers when we're building the
library itself, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
Fix up some missing config.h includes when building the lib which
is needed to get the export api define from config.h
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/42
summary_:
This way the timeline can handle all priorities for the user
making the API simpler to use.
API:
+ ges_timeline_move_layer
reviewers_: Mathieu_Du
Differential Revision: https://phabricator.freedesktop.org/D232
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
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
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
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
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
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
This is formally an API break but I am sure no one ever used that and
we should make sure the method is removed as soon as possible because
it has no reason to be exposed.
In the GESTimeline, TrackElement addition to a clip might get cancelled
(and thus the element gets removed), we need to make sure users do not
get wrong signals.
Also document the fact that user should connect to container::child-added
with g_signal_connect_after.
We should never let 3 objects to overlap at a same position, for that
we introduce a "rollback" feature and whenever such an editing happens,
we rollback object position to whatever it was before the move.
In case of groups, we can have track elements that do not belong
directly to the moved_trackelements but will be moved as others. Never
create transition to all object that have a start > moving group start.
Summary:
+ [API] GESTrack::commited signal.
+ [API] ges_track_commit_sync
We were emitting commited when timeline_commit was called, which
wasn't very helpful. This commit makes it so we emit commited once
all the compositions have actually been commited.
We also add a synchronous commit method to spare the user
the need to connect to the signal and wait, and update the
documentation.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D83
I got some trouble with
arc land
and I wanted to push the 3 commit coming after this revert as 3
different commits but they ended up being all squash into one single
commit, which is clearly not cool for later bisecting and blaming.
Reverting that commit and re pushing those 3 commits as they were
supposed to be.
This reverts commit 9fe15ef435.
They were not serialized until now.
That implies several changes:
* Override GESTimelineElement [start, inpoint, duration] properties in
GESGroup to ensure that those properties are not serialized as they
should not be.
* Rename GESBaseXmlContainer->clips field to
GESBaseXmlContainer->containers as the hashtable now contains Groups
https://bugzilla.gnome.org/show_bug.cgi?id=709148
In case we are not in a PLAYING state and the project is loaded, the
only thing that should be done is to fill the gaps and this way when the
composition get to PLAYING, their initialization will be enough to get
everything on track.
When users (can be formatters) set timeline element names in the
default 'namespace' we need to update our counter to avoid setting
twice the same name on TimelineElements so afterward there is no
problem adding them in the GESTimeline
+ add a testcase to check that new code and fix leaks on the
existing testcases.
+ Sensibly enhance debugs
g-ir-scanner includes section docs as class/interface docs if the section name is equal to the lowercase type name.
Since all the documentation is in section blocks, rename them to match the type names.
https://bugzilla.gnome.org/show_bug.cgi?id=727776
Without that, if a UriClip contains several tracks of a same type (ie.
video or audio...), we would add all the TrackElements to each track
making everything failling as we end up with several GNL sources at
the same position with the same priority.
And fix all the tests as we need to wait for the project to be loaded
to check the reference count of the timeline (as we keep a ref on the
timeline in project to later emit "loaded" on idle).
