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)
To support ges_{init/deinit} multiple times in a process,
there should be a method for setting up internal object/table of
GESUriClipAssetClass. because *_class_init() will be called
only once in process lifecycle.
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
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 different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
With two exceptions:
* ges_clip_create_track_elements_func
* ges_uri_clip_set_uri
which were never declared in headers and should always have been static.
The following implementation details where exposed as public symbols:
- _ges_container_get_priority_offset
- _ges_container_set_height
- _ges_container_set_priority_offset
- _ges_uri_asset_cleanup
but it was not correct and that should never have been used outside
GES.
Moving those declarations to the internal header and marking as
internal.
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
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
