Only allow elements that were created by ges_clip_create_track_elements
(or copied from such an element) to be added to a clip. This prevents
users from adding arbitrary elements to a clip.
As an exception, a user can add GESBaseEffects to clips whose class
supports it, i.e. to a GESSourceClip and a GESBaseEffectClip.
This change also introduces a distinction between the core elements of a
clip (created by ges_clip_create_track_elements) and non-core elements
(currently, only GESBaseEffects, for some classes). In particular,
GESBaseEffectClip will now distinguish between its core elements and
effects added by the user. This means that the core elements will always
have the lowest priority, and will not be listed as top effects. This is
desirable because it brings the behaviour of GESBaseEffectClip in line
with other clip types.
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
We used to always call the `->set_child_property` virtual method
of the object that `ges_timeline_element_set_child_property` was called
from, but that means that, in the case of referencing GESContainer
children properties from its children, the children wouldn't know
what child property have been set, and the children override wouldn't
be takent into account, in turns, it means that the behaviour could be
different in the setter depending on parent the method was called,
which is totally unexpected.
We now make sure that the vmethod from the element that introduced the
child property is called whatever parent method is called, making the
behaviour more uniform.
Fix the python override to make sure that new behaviour is respected.
In general, brought the behaviour of the `start`, `duration` and
`inpoint` setters in line with each other. In particular:
1. fixed return value the GESSourceClip `duration` setter
2. changed the GESClip `start` setter
3. fixed the inpoint callback for GESContainer
4. changed the type of `res` in GESTimelineElement to be gint to
emphasise that the GES library is using the hack that a return of -1
from klass->set_duration means no notify signal should be sent out.
Also added a new test for clips to ensure that the setters work for
clips within and outside of timelines, and that the `start`, `inpoint`
and `duration` of a clip will match its children.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
Setters return values should return %FALSE **only** when the value
could not be set, not when unchanged or when the subclass handled
it itself!
This patches makes it so the return value is meaningul by allowing
subclasses return anything different than `TRUE` or `FALSE` (convention
is -1) to let the subclass now that it took care of everything and
no signal should be emited.
Now that the notion of layer has been moved down to #GESTimelineElement
(through the new #ges_timeline_element_get_layer_priority method), this
method make much more sense directly in the base class.
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
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
Otherwise the changes won't be reflected in the NLE backend.
This makes speed changes working inside ges-launch-1.0
ges-launch-1.0 +clip /path/to/file i=10 d=5 +effect videorate set-rate 5.0
https://bugzilla.gnome.org/show_bug.cgi?id=794699
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
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
Before this patch, NLE and GES did not support NleOperations (respectively
GESEffects) that changed the speed/tempo/rate at which the source plays. For
example, the 'pitch' element can make audio play faster or slower. In GES 1.5.90
and before, an NleOperation containing the pitch element to change the rate (or
tempo) would cause a pipeline state change to PAUSED after that stack; that has
been fixed in 1.5.91 (see #755012 [0]). But even then, in 1.5.91 and later,
NleComposition would send segment events to its NleSources assuming that one
source second is equal to one pipeline second. The resulting early EOS event
(in the case of a source rate higher than 1.0) would cause it to switch stacks
too early, causing confusion in the timeline and spectacularly messed up
output.
This patch fixes that by searching for rate-changing elements in
GESTrackElements such as GESEffects. If such rate-changing elements are found,
their final effect on the playing rate is stored in the corresponding NleObject
as the 'media duration factor', named like this because the 'media duration',
or source duration, of an NleObject can be computed by multiplying the duration
with the media duration factor of that object and its parents (this is called
the 'recursive media duration factor'). For example, a 4-second NleSource with
an NleOperation with a media duration factor of 2.0 will have an 8-second media
duration, which means that for playing 4 seconds in the pipeline, the seek
event sent to it must span 8 seconds of media. (So, the 'duration' of an
NleObject or GES object always refers to its duration in the timeline, not the
media duration.)
To summarize:
* Rate-changing elements are registered in the GESEffectClass (pitch::tempo and
pitch::rate are registered by default);
* GESTimelineElement is responsible for detecting rate-changing elements and
computing the media_duration_factor;
* GESTrackElement is responsible for storing the media_duration_factor in
NleObject;
* NleComposition is responsible for the recursive_media_duration_factor;
* The latter property finally fixes media time computations in NleObject.
NLE and GES tests are included.
[0] https://bugzilla.gnome.org/show_bug.cgi?id=755012
Differential Revision: https://phabricator.freedesktop.org/D276
Allowing pasting groups paste exactly what had been copied
And not the new version of the contained objects
This technically breaks the C API but this is a new API and I believe
and hope nobody is using it right now.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D616
This commit was causing issue where we were reporting the toplevel
element as an element but that element was actually in another
not serialized group. That is very tricky to handle for end users
as they are not guaranteed the toplevel clips were actually not
contained in another element.
This reverts commit ceb82ba302.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D627
