This method is useful when implementing a formatter outside
GES that end up converting to xges and uses the default formatter
to finally load the timeline.
Adding a property to let the application know
Also make sure that the duration of nested timeline assets is reported
as CLOCK_TIME_NONE as those are extended as necessary.
And make a difference between asset duration and their max duration
As nested timelines can be extended 'infinitely' those max duration
is GST_CLOCK_TIME_NONE, but their duration is the real duration of
the timeline.
When we have nested timelines, we need to make sure the underlying
formatted file is reloaded when commiting the main composition to
take into account the new timeline.
In other to make the implementation as simple as possible we make
sure that whenever the toplevel composition is commited, the decodebin
holding the gesdemux is torn down so that a new demuxer is created
with the new content of the timeline.
To do that a we do a NleCompositionQueryNeedsTearDown query to which
gesdemux answers leading to a full nlecomposition stack
deactivation/activation cycle.
It was making no sense to consider it an empty timeline when the user
had passed the project URI when requesting the asset. Usually user
use `ges_project_new` with the URI but it is also valid to use
`ges_asset_request` with the uri as ID so let's handle that properly.
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
Making sure to have 1 GstDiscoverer per thread.
Use that new feature in gesdemux by loading the timeline directly from
the streaming thread. Modifying the timeline is not supported allowed
anyway.
In the case of nested timeline in the toplevel timeline we ended up
with CompositionUpdate for seeks sent by our own composition to
granchildren composition. This was not causing essential issues
if all tracks where containing nested timelines but in cases
where one of the tracks only had a nested timelines, then we
were waiting forever for a `CompositionUpdateDone`.
CompositionUpdate translated into ASYNC_START/ASYNC_DONE should
be kept inside the GESTimeline and not travel up (possibly to some
parent GESTimeline).
For smptealph element to work as expected the following compositing
element should mix with the default "over" operator, as described
in its documentation.
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.
ges_container_add removes the child being added if the call to
ges_timeline_element_set_parent fails. In this case, subclasses should
be given the chance to revert the effects of the add_child vmethod which
has just been called.
These are showing up in performance profile of 1000+ clips looped addition.
All this is done at commit time as well, so let that do only one update and
sorting.
Discoverer maintain a referernce on the discoverer object while
the async timeout callback is alive to prevent a potential crash
if the object is freed while the callback is pending.
But if g_main_context is released before calling the timeout callback,
the discoverer pointer which was weak referenced from GESUriClipAssetClass
will not be disposed because the discoverer object is not finalized.
And handle the fact that adding to a layer can fail.
Also plug some leaks in the dispose method (and use the dispose
vmethod instead of finalize as appropriate).
Basically if we do not emit a "duration" change of the clip being
splitted first when executing the 'reverse' operations would lead
to fully overallaping clips.
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
