Smart rendering has been broken since, mostly forever, but some code
was there pretending it was supported... let's try to stop pretending.
We now keep track of the smart rendering state in the timeline, track
and sources to be able to:
* tell decodebin to stop plugging more (decoding elements) as soon as
downstream supports the format.
* avoid plugging converters after the source element when smart
rendering.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/198>
Stop setting the track 'caps' property. The previous code could
overwrite a users own setting of the caps for video and audio caps.
Moreover, the 'caps' property is listed as construct only, and users
will likely expect it to stay the same after a track has been added to a
timeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/198>
While this is not correct, we can't predict from what thread a
GstElement will be disposed as it might still be referenced by
a GstMessage somewhere which is freed by, any thread.
In this specific case we can assume that GES user will already have
let go his timeline reference and we should not avoid assert in that
specific case as it should be safe to let the timeline be destroyed
at that point.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/175>
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 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
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
These are showing up in performance profile of 1000+ clips looped addition.
All this is done at commit time as well, so let that do only one update and
sorting.
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
Summary:
Normally, mixing_operation is created and added to nlecomposition
as a child element so it will be freed when nlecomposition is removed
from a track.
Reviewers: thiblahute
Projects: #gstreamer_editing_services
Differential Revision: https://phabricator.freedesktop.org/D319
Summary:
The backend commits itself automatically in these cases, so track
needs to do so too.
Reviewers: thiblahute
Reviewed By: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D94
Summary:
+ [API] GESTrack::commited signal.
+ [API] ges_track_commit_sync
We were emitting commited when timeline_commit was called, which
wasn't very helpful. This commit makes it so we emit commited once
all the compositions have actually been commited.
We also add a synchronous commit method to spare the user
the need to connect to the signal and wait, and update the
documentation.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D83
Summary: Before checking if we have a specific constructor for a track type.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D63
Summary:
We should not restrict the CapsFeatures on the track caps.
If someone want to do such a restriction he should add it to
the restriction caps directly
Test Plan: Run testsuite
Reviewers: mathieu.duponchelle
If priv->timeline is False the function does not set any value for
timeline_duration before using it in gap_new (). Initialize the value to aviod
unexpected behaviour.
CID #1268405
The strategy here is to seek at the new end of the composition. And in
GES we always add a 1ns long gap at the end of the tracks so that all
track have the exact same duration, and we have black frames when the
timeline is empty
In case we are not in a PLAYING state and the project is loaded, the
only thing that should be done is to fill the gaps and this way when the
composition get to PLAYING, their initialization will be enough to get
everything on track.
