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
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.
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
Making it possible to create the nleobject right at the creation
of the element.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D738
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.
GstStructureForeachFunc has a gboolean return value,
and the foreach function will stop unless we return
TRUE here. This meant it was potluck whether all
properties in the structure got set or not.
Fixes setting of text overlay clip text property
in particular.
https://bugzilla.gnome.org/show_bug.cgi?id=743874
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
+ Make sure that the TitleClip properties are not serialized anymore as
they are serialized through children properties now.
+ Enhance debugging for not serialized properties in GESXmlFormatter.
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.
Most of the time the user should not create GESTrackElements
himself, instead he should add a GESAsset to a layer, that will
result in a clip creation and the proper TrackElements to be
created and added to the tracks.
The case of effects and overlays is a bit different as the user should
create the TrackElement and add them to a clip.
This way we can let the user determine what he want to come out of the
track.
API:
- ges_track_set_caps (The track caps are now construct only)
+ ges_track_set_restriction_caps
+ ges_track_get_restriction_caps
+ GESTrack.props.restriction_caps
We should make sure that the newly created trackelement are inside
a container when adding them to as this is needed for GESUriClip-s.
Also do not try to set a child property on the TrackElement itself.
https://bugzilla.gnome.org/show_bug.cgi?id=703152
+ Fix tests (we still need a round of modernisation, making use of
assets where it makes sense)
There is no reason to use those method outside of GES, so remove them,
cleaning the API and making it easier for users.
Removed APIs:
-----------
* ges_clip_create_track_element
* ges_clip_create_track_elements
