Only copy the properties that can be both read and written, and are not
construct only. Similarly for child properties when a track-element is
deep copied.
Technically, an element can still be floating on the return from
`->paste` (e.g. a clip not in a layer). Since the return of the `_paste`
methods are (return full) a non-floating object is probably expected in
all cases.
By-pass the select-tracks-for-object signal for auto-transitions since
their track element must land in the same track as the elements it is
the auto-transition for.
The way a clip's track elements are added to tracks was re-handled. This
doesn't affect the normal usage of a simple audio-video timeline, where
the tracks are added before any clips, but usage for multi-track
timelines has improved. The main changes are:
+ We can now handle a track being selected for more than one track,
including a full copy of their children properties and bindings.
(Previously broken.)
+ When a clip is split, we copy the new elements directly into the same
track, avoiding select-tracks-for-object.
+ When a clip is grouped or ungrouped, we avoid moving the elements to
or from tracks.
+ Added API to allow users to copy the core elements of a clip directly
into a track, complementing select-tracks-for-object.
+ Enforced the rule that a clip can only contain one core child in a
track, and all the non-core children must be added to tracks that
already contains a core child. This extends the previous condition
that two sources from the same clip should not be added to the same
track.
+ Made ges_track_add_element check that the newly added track element
does not break the configuration rules of the timeline.
+ When adding a track to a timeline, we only use
select-tracks-for-object to check whether track elements should be
added to the new track, not existing ones.
+ When removing a track from a timeline, we empty it of all the track
elements that are controlled by a clip. Thus, we ensure that a clip
only contains elements that are in the tracks of the same timeline, or
no track. Similarly, when removing a clip from a timeline.
+ We can now avoid unsupported timeline configurations when a layer is
added to a timeline, and already contains clips.
+ We can now avoid unsupported timeline configurations when a track is
added to a timeline, and the timeline already contains clips.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/84
This was used to connect to the track element's notify::start signal in
order to update the duration of the timeline (it is not clear why the
notify::duration signal was not also connected to for the same reason).
However, this is already covered by the timeline_tree_move method, which
is always called to update the start of a track element, even if it is not
part of a clip (and similarly for timeline_tree_trim, which is called
when the duration is set).
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.
Rename the private "owners" to "creators" to avoid confusing this with
the owner of the track element's memory.
Also made the ungroup method for GESClip symmetric by making all the
children of the resulting clips share their creators, which allows them
to be added to any of the other ungrouped clips. Once the clips are
grouped back together, the tracks loose these extra creators.
Make sure we sink the child on adding, and keep it alive until the end
in case the method fails.
Also, since the child mappings hold a ref to the child, they should give
them up in their free method. This way, the ref will be given up on
disposing, even if ges_container_remove fails.
Also, reverse setting of the start of the container if adding fails.
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
Refactoring GESVideoSource so that #GESUriVideoSource can handle
still image in a simple way
MultiFileSource has been replaced with the new `imagesequencesrc`
element, this was totally broken anyway as `multifilesrc` can not seek
properly.
This means that we have all the information about the asset
when constructing the underlying GstElements.
This also allows to cleanup some code all around
And deprecate all GESTrackElement constructors, but the GESEffect one.
Those should **never** be created by users and should become internal
in the future.
Stop having docstring for the constructors that were internal.
APIs:
- ges_timeline_get_frame_time
- ges_timeline_get_frame_at
- ges_clip_asset_get_frame_time
- ges_clip_get_timeline_time_from_source_frame
Extracting ges_util_structure_get_clocktime to internal utilities adding
support for specifying timing values in frames with the special
f<frame-number> synthax.
_sanitize_argument is supposed to wrap arguments in '"' quote marks such
that they can be parsed and copied into a GstStructure string. This
purpose is now supported more directly, which fixes some bugs, e.g.:
arguments before fix
+title my=title +title my="title" +title "my=title"
+title abc n=my=name +title abc n="my="name" +title abc n="my=name"
+title my"title +title "my"title" +title "my\"title"
+title my\title +title "my\title" +title "my\\title"
This is often very useful to have a timeoverlay inside test sources.
We do not want to use it as an effect as segments are not the sames
in GES when it comes to nleoperations.
When the `child-added` signal emission was called, the
`GESContainer->child_added` vmethod was called (the signal is
`G_SIGNAL_RUN_FIRST`) so we need to call `GESContainer->child_removed`
ourself so subclasses know they do not control the child anymore.
The properties will only have their signal emitted when they change in
value, even when g_object_set, etc, methods are used.
The _set_start method already did this, but start was missing the
EXPLICIT_NOTIFY flag. There should be no need to check that the property
has changed in ->set_start or ->set_duration
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.
