GitLab

And add a "loading-error" signal in GESProject so we can report
issue when loading async elements for the timeline.

And fix the project file which couldn't be load now that we
properly check clips coherency

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.

This way we can modify nested timelines.

The action type was thought to allow that but it wasn't implemented.

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

It was not talking into account the fact that you can have
several assets with a same ID but different exactractable types.

And avoid infinite recursion

And error out when it is the case.

And let the GESPipeline logic handle that

So that project files are found when using nested timelines

Config files should have the-scenario-name.scenario.config to be picked automatically

Make sure that an event resulting from the seek happens before removing
the pad probe, dropping anything while it is not the case.

This guarantees that the seek happens before `nlesource` outputs
anything. This was not necessary as with decodebin or usual source
flushing seeks lead to synchronous flush_start/flush_stop and we could
safely assume that once the seek is sent, it was happenning.
With nested `nlecomposition` this assumption is simply not true as
in the composition seeks are basically cached and happen later in
the composition updating thread.

This fixes races where we ended up removing the blocking probe before
the seek actually started to be executed in the nlecomposition
nested inside an nlesource which leaded to data from *before* the seek
to be outputed which means we could display wrong frames,
and it was leading to interesting deadlocks.

Add a simple test for that.

It was almost the case already so make it happen fully

Seeks that lead to a stack change lead to deactivating the current
stack. At that point we explicitely flush downstream as a reaction to
the flushing seek. Until now those flushes had a random seqnum, this
fails if we are a nested compostion as the parent composition will end
up dropping that flush which in turns might lead to deadlocks. For
example, the flush goes through a `compositor` which wants to flush
downstream to stop its srcpad task, but that flush wouldn't have
"released" its srcpad thread if the composition srcpad drops it, meaning
it won't be able to stop the task ever.

Otherwise if we shutdown a composition whith an nested composition
(inside a source in the test) and leak it, we end up with the nested
composition task still running (in READY) which is bad.

Add a test for that which leaks the pipeline on purpose.

This allows accessing the nlecomposition in gdb when a task is
'dangling' making debugging easier.

When we have nested timelines, we do not want those messages to pop
to the parent timelines as we handle the sequence ourself in the
timeline.

First marshilling it to the main thread is dangerous as it is a blocking
operation and it should never happen there.

The asset cache is MT safe now so it is possible to load the timeline
from that thread directly

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).

The field was already expected in the launcher