ges_uri_clip_asset_get_duration does not tell us what the duration in
the timeline needs to be. Especially when we have time effects, or
effects with finite max-durations. So we should no longer expect the
duration to stay the same when replacing assets. Instead, we just check
that the new max-duration would be compatible with the current in-point
(which was not checked before), and the clip would not be totally
overlapped if its duration-limit changes.
This is based on the assumption that each source is replaced one-to-one
in its track. If a source is replaced with nothing in the same track,
this check may be a little too strong (but still mostly weaker than
before). However, problems could occur if track selection does
something unexpected, such as placing the new source in a track not
previously occupied.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/177>
When the asset of a uri clip is reset, its core children are removed and
replaced by the new core children. When replacing, the `set_asset`
method attempts to copy children properties from the previous children
to the new children. However, the children were matched by track-type
only. This would not function as intended when a URI contains multiple
audio or video streams. Instead, we now match children by the tracks
themselves. This should work better, provided the user's
select-tracks-for-object is well behaved.
Also, fix a memory problem in `set_mute` for when a child is not in a
track.
Before the max-duration could be set arbitrarily when the clip was empty,
to indicate what the max-duration would be once the core children were
created. Now, we can also do this whilst the clip only contains non-core
children.
gcc-10 defaults to -fno-common, which exposes a symbol conflict, so
use `static` correctly. Also we don't use `parent_extractable_iface`
in `ges-uri-clip.c`.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
GES_TESTING_ASSETS_DIRECTORY is prehistoric and since then
new mechanism for asset relocation have been added, it makes
no sense to keep that unused code path
The in-point of a clip is kept in sync with its core children, unless they
have no has-internal-source.
The max-duration is defined as the minimum max-duration amongst the
clip's core children. If it is set to a new value, this sets the
max-duration of its core children to the same value if they have
has-internal-source set as TRUE.
Non-core children (such as effects on a source clip) do not influence
these values.
As part of this, we no longer track in-point in GESContainer. Unlike start
and duration, the in-point of a timeline element does not refer to its
extent in the timeline. As such, it has little meaning for most
collections of timeline-elements, in particular GESGroups. As such, there
is no generic way to relate the in-point of a container to its children.
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.
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
Export GES library API in headers when we're building the
library itself, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
Fix up some missing config.h includes when building the lib which
is needed to get the export api define from config.h
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/42
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.
And reuse the same previously created element when adding the clip
back to a layer, avoiding losing all setting done on clip children
in that situation
This is a behaviour change but previous behaviour was actually totally
unexpected and people working around that weird behaviour will moste
probably not care about that change
Differential Revision: https://phabricator.freedesktop.org/D1094
To avoid compiler warning when using const string to create a new
GESUriClip as string is not modified and only passed to functions which
take a const string.
https://bugzilla.gnome.org/show_bug.cgi?id=766523
g-ir-scanner includes section docs as class/interface docs if the section name is equal to the lowercase type name.
Since all the documentation is in section blocks, rename them to match the type names.
https://bugzilla.gnome.org/show_bug.cgi?id=727776
