Stopping to do it at the bin description level but properly
plugging them where they are needed and cleanly ghosting the pads
where it makes most sense.
This introduces support for GES to request pads on the most upstream
element in case no static pad can be ghosted.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/187>
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>
The out-point, which is an internal time, is used instead of the
duration for determining the control binding value at the end of the
element.
Also, allow the user to switch off the auto-clamping of control sources
if they are not desired. And allow them to clamp specific control sources
individually.
Also, fix a lot of memory leaks related to control sources. In
particular, releasing the extra ref gained by source in
g_object_get (binding, "control-source", &source, NULL);
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/177>
Unlike ges_container_add, this lets you set the index and will check
that track selection did not fail. This is useful for time effects whose
addition would create an unsupported timeline configuration.
Also can use the clip add error in ges_timeline_add_clip to let the user
know when adding a clip to a layer that its in-point is set larger than
the max-duration of its core children.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/177>
Allow the user to register a child property of a base effect as a time
property. This can be used by GES to correctly calculate the
duration-limit of a clip when it has time effects on it. The existing
ges_effect_class_register_rate_property is now used to automatically
register such time effects for rate effects.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/177>
This was complexifying the implementation for very little gain.
Each source type should ideally have its own API.
In that patch we make it so we do not have to subclass anything
but instead use GESAsset to pass information about how the pipeline
should look like.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/175>
Each active non-core child must have a corresponding active core child
in the same track. Therefore, if we de-activate a core child, we also
need to de-activate all the non-core children in the same track.
Similarly, if we activate a non-core child, we need to activate the
corresponding core child as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
We first change the duration of the splitted clip, then we add the new
clip to the layer and assign the tracks for its children. Normally, when
a clip is added to a layer it will have its track elements created, if
needed, and then assigned to their tracks. This will fail if any sources
would fully or triple overlap existing sources in the same track.
However, here we were adding the clip to the layer *and* avoiding the
track assignment process and instead setting the tracks explicitly. In
particular, the order was:
+ add new clip to layer with no tracks assigned
+ shrink the split clip
+ assign the tracks for the new clip
This has been changed to:
+ shrink the split clip
+ add new clip to layer with no tracks assigned
+ assign the tracks for the new clip
Thus, the order of events for any users connecting to object signals
will be close to that of adding another clip to the layer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Make sure that the priority of an appended layer is the lowest (highest
in value) when appending a layer to the timeline. This change is
important when appending a layer to a timeline, which can easily have a
gap in priorities if a layer has been removed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
These tests expose some of the new editing behaviour in timeline
tree. In particular, we test:
+ edits for clips within groups within a group
+ that an edit can succeed if a snap allows it to
+ that snapping occurs at a specific point, and that we alternate
between one call to snapping-started and one call to snapping-ended
with corresponding values
+ that an edit can fail if a snap causes it to
+ no snapping is released when an edit fails
+ We tests for the expected changes, and otherwise check that the
configuration of the timeline has remained unchanged
+ The timeline configuration remains the same when an edit fails
+ That each clip overlap has a corresponding auto-transition
+ That particular auto-transitions are created when a new overlap is
formed
+ That particular auto-transitions are destroyed when an overlap ends
+ That auto-transitions are not replaced when two clips move but
maintain their overlap
+ That the timeline does not contain any unaccounted for clips
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Only emit snapping-ended if we have a valid snap time. Moreover, we
should emit a new snapping-started even if we are snapping at the same
location. This is because a new snap will always correspond to a new edit,
possibly involving different snapping elements, which a user would want
to know about.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Editing has been simplified by breaking down each edit into a
combination of three basic single-element edits: MOVE, TRIM_START, and
TRIM_END.
Each edit follows these steps:
+ Determine which elements are to be edited and under which basic mode
+ Determine which track elements will move as a result
+ Snap the edit position to one of the edges of the main edited element,
(or the edge of one of its descendants, in the case of MOVE), avoiding
moving elements.
NOTE: in particular, we can *not* snap to the edge of a neighbouring
element in a roll edit. This was previously possible, even though the
neighbour was moving!
+ Determine the edit positions for clips (or track elements with no
parent) using the snapped value. In addition, we replace any edits of
a group with an edit of its descendant clips. If any value would be
out of bounds (e.g. negative start) we do not edit.
NOTE: this is now done *after* checking the snapping. This allows the
edit to succeed if snapping would cause it to go from being invalid to
valid!
+ Determine whether the collection of edits would result in a valid
timeline-configuration which does not break the rules for sources
overlapping.
+ If all this succeeds, we emit snapping-started on the timeline.
+ We then perform all the edits. At this point they should all succeed.
The simplification/unification should make it easier to make other
changes.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/97
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/98
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
The duration-limit is the maximum duration that can be set for the clip
given its current children and their properties. If a change in the
children properties causes this to drop below the current duration, it
is automatically capped by this limit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
Made sure that adding a new track only uses select-tracks-for-object for
core children to determine whether a track elements should be added to the
new track or not, and *not* any other track. In particular, there should
be *no* change in the existing tracks of the timeline when adding another
track. Moreover, a new track should not invoke the creation of track
elements for other tracks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/160>
The property had been deprecated and is unused.
This property is not needed. Any internal time effect that an nleoperation
wraps is itself responsible for converting seek/segment timestamps.
Previously, the ghostpads were performing a rate conversion after the
rate element had already done so, essentially doubling their effect on
seeks and segment times. This was always unnecessary, but went unnoticed
by the tempochange test because it was using an identity element rather
than an actual rate-changing element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/160>
Avoid loosing (too much) precision when rescaling back and forth by
storing values in gdoubles.
Handle the fact that position values can be negative
Also fix debug category static variable
as it clashes with the instance variable name in a few methods.
Instead of focusing on the instances of the clips and their children,
we relax the check to allow moving track element clip between clips
that share a common asset. This makes it as correct conceptually but
more flexible, and the code becomes simpler.
Previously, the code was not able to detect that an element overlaps on
its end, nor could it detect that an element overlaps two elements that
already overlap.
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
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.
