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.
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
This way we can let the user determine what he want to come out of the
track.
API:
- ges_track_set_caps (The track caps are now construct only)
+ ges_track_set_restriction_caps
+ ges_track_get_restriction_caps
+ GESTrack.props.restriction_caps
The GNL API changed to go from a model where user could
enable/disable updates in the composition, which leaded to races
in many places, to a model where any positioning change in the
composition is not directly done but 'cached' and then the user
has to commit those changes so they become effective in the media
processing stack.
The new API in GES is pretty similare and is basically copy
pasting this new design.
We still need to see if in some context it would make sense to add
a mode where we would commit any changes ourself at the end of our
operation for basic use cases.
Removed APIs:
ges_timeline_enable_update
ges_timeline_is_updating
ges_track_enable_update
ges_track_is_updating
New APIs:
ges_track_commit
ges_timeline_commit
... Not the other way round.
+ Add and enhance debugging info on the way
The user should not be responsible for removing the GESTrackElements from
GESTracks, instead, removing it from a GESClip should imply removing
it from any GESTrack it is in.
This patch changes sensibly the behaviour when we remove a
GESTrackElement from a GESTrack, not remoing it from the GESClip it is
in. *But*, users should never remove a GESTrackElement from a GESTrack
anyway. The testsuite has been updated to that new behaviour.
Modifies some API:
ges_timeline_object_create_track_objects now take a GESTrackType instead of a
GESTrack as second argument, and return a GList instead of a boolean
ges_timeline_object_create_track_object now take a GESTrackType instead of a
GESTrack as second argument
