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.
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.
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)
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.
GstDiscoverer objects were leaked by tests making the leaks detector
unusable.
Introduce ges_deinit(), similiar to gst_deinit(), doing some cleanup
before exiting the process.
https://bugzilla.gnome.org/show_bug.cgi?id=776805
This way we let the possibility to the user to actually do it, but we avoid him to do it
without knowing it is absolutely not recommanded to.
API:
+ ges_uri_clip_asset_request_sync
