The following implementation details where exposed as public symbols:
- _ges_container_get_priority_offset
- _ges_container_set_height
- _ges_container_set_priority_offset
- _ges_uri_asset_cleanup
but it was not correct and that should never have been used outside
GES.
Moving those declarations to the internal header and marking as
internal.
GstDiscoverer objects were leaked by tests making the leaks detector
unusable.
Introduce ges_deinit(), similiar to gst_deinit(), doing some cleanup
before exiting the process.
https://bugzilla.gnome.org/show_bug.cgi?id=776805
We were using the actual mixer pad to release the smart mixer
pad, which seemed to be on purpose, but was not properly handle,
moreover, it is now forbiden to pass a pad not inside a GstElement
when releasing it.
Also properly remove ghost pads from Smart mixer, we were planly
failling at it.
It was making no sense to loose the information about the pspec itself
to retrieve the child associated to it and was failling when we were
forcing the AssociateType::prop synthax
The underlying integer type for enums are implementation defined and may
not be the same size as gint/guint. So implicitly casting from pointers-
to-enum-types to pointers-to-int-types is unsafe. MSVC warns on these.
https://bugzilla.gnome.org/show_bug.cgi?id=774641
In some cases when rippling clip we could get the algo lost because
a transition existed between two clips (for example at the end of c1
and at the begining of c2) but while rippling it would have required
a transition at the end of c2 and beginning of c1, and we were properly
not destroying the old one (as the two clips were in the moving context)
but we were still creating the other transition in the end...
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1362
We set TrackElement track type very early when creating effects
so it now uses that information to find TrackElement in clips
by track type.
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1370
Computation was not taking into account the fact that the start of
the element being moved could be at the middle of a group and not
necessarily at the start!
Fixes T7544
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1282
We were only concidering that we should let the group handle moving
transitions when changing transitions but in fact as soon as a
transition is happenning between two clips that are in a same group
the group properly handles moving the transition, so let the
group do its job.
Fixes T7543
Differential Revision: https://phabricator.freedesktop.org/D1281
GESLayer is now responsible for setting clips priorites. Also
GESClip top effects priorities are now set by the
ges_clip_set_top_effect_index method, the user should never call
ges_timeline_element_set_priority as it will anyway be overriden
by GES itself.
Differential Revision: https://phabricator.freedesktop.org/D1280
All operations should have higher priorites and sources should be
on top of those. We now first set the operations priorities in
a first pass and then stack sources on top of those.
Differential Revision: https://phabricator.freedesktop.org/D1279
In case effects have been added priorites might become wrong,
but until the timeline is not commited, it does not matter.
Make sure all priorities are correct before commiting compositions
Differential Revision: https://phabricator.freedesktop.org/D1277
Fix all tests as we now have 1 priority inside the layer
dedicated to transitions (basically no source clip will
ever have a priority of 0 inside a layer).
Differential Revision: https://phabricator.freedesktop.org/D1276
And simplify the way we start computing children priority
making min_priority already relative to the clip itself.
Differential Revision: https://phabricator.freedesktop.org/D1275
Had to separate timeline_emit_group_added from timeline_add_group
to avoid emitting group-added when the project is being loaded.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D1302
Fixes a regression where we decode streams twice,
this was introduced when we started creating NLE
object at GESTrackElement construct time.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=769193
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
It's what introspection.mak does as well. Should
fix spurious build failures on gnome-continuous
(caused by g-ir-scanner getting compiler details
via python which is broken in some environments
so passing the compiler details bypasses that).
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
Otherwise if frame positionner is disposed after track element has been
finalized, it will raise a critical message because we will try to
disconnect a signal handler on a freed track element object.
https://bugzilla.gnome.org/show_bug.cgi?id=766525
Those are implemented with the exact same API at the GESTimelineElement
level now, and user of those APIs with high level languages will get the
exact same API.
This is formally an API break but I am sure no one ever used that and
we should make sure the method is removed as soon as possible because
it has no reason to be exposed.
This is the only header which shall be included by user. Otherwise some
language using gir to generate binding, e.g Vala, will includes all
headers files in alphabetical order which causes compilation errors due
to incomplete type.
https://bugzilla.gnome.org/show_bug.cgi?id=765856
Debugging must be configuring first (before any parsing), and then
the types are initialized at the end.
Fixes issues with debugging categories not being available at the
start
Before this patch, NLE and GES did not support NleOperations (respectively
GESEffects) that changed the speed/tempo/rate at which the source plays. For
example, the 'pitch' element can make audio play faster or slower. In GES 1.5.90
and before, an NleOperation containing the pitch element to change the rate (or
tempo) would cause a pipeline state change to PAUSED after that stack; that has
been fixed in 1.5.91 (see #755012 [0]). But even then, in 1.5.91 and later,
NleComposition would send segment events to its NleSources assuming that one
source second is equal to one pipeline second. The resulting early EOS event
(in the case of a source rate higher than 1.0) would cause it to switch stacks
too early, causing confusion in the timeline and spectacularly messed up
output.
This patch fixes that by searching for rate-changing elements in
GESTrackElements such as GESEffects. If such rate-changing elements are found,
their final effect on the playing rate is stored in the corresponding NleObject
as the 'media duration factor', named like this because the 'media duration',
or source duration, of an NleObject can be computed by multiplying the duration
with the media duration factor of that object and its parents (this is called
the 'recursive media duration factor'). For example, a 4-second NleSource with
an NleOperation with a media duration factor of 2.0 will have an 8-second media
duration, which means that for playing 4 seconds in the pipeline, the seek
event sent to it must span 8 seconds of media. (So, the 'duration' of an
NleObject or GES object always refers to its duration in the timeline, not the
media duration.)
To summarize:
* Rate-changing elements are registered in the GESEffectClass (pitch::tempo and
pitch::rate are registered by default);
* GESTimelineElement is responsible for detecting rate-changing elements and
computing the media_duration_factor;
* GESTrackElement is responsible for storing the media_duration_factor in
NleObject;
* NleComposition is responsible for the recursive_media_duration_factor;
* The latter property finally fixes media time computations in NleObject.
NLE and GES tests are included.
[0] https://bugzilla.gnome.org/show_bug.cgi?id=755012
Differential Revision: https://phabricator.freedesktop.org/D276
Read only properties will throw a GLib warning like this
when accessed with "set_child_property":
Warning: g_object_set_property: property 'text-x' of object class 'GstTextOverlay' is not writable
Avoiding all the pending_xx dance and making the code simpler.
This is now possible thanks to the various recent refactoring.
Thanks to that the user is able to set_child_property on objects
that are not in GESTrack yet, as expected.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D739
Making it possible to create the nleobject right at the creation
of the element.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D738
In get_property we should return the default values if
we have not created any GESTitleSource yet
(instead of segfaulting).
And fix GESTitleSource default values!
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D737
This way we have informations about the content of the
children as soon as possible.
Most code paths where already ready to handle that as we use it for
copying clips.
Fix framepositionner to properly handle that (it would have broke
with copied clips before).
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D736
Allowing pasting groups paste exactly what had been copied
And not the new version of the contained objects
This technically breaks the C API but this is a new API and I believe
and hope nobody is using it right now.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D616
it should always have been private
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D617
This commit was causing issue where we were reporting the toplevel
element as an element but that element was actually in another
not serialized group. That is very tricky to handle for end users
as they are not guaranteed the toplevel clips were actually not
contained in another element.
This reverts commit ceb82ba302.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D627
ges-validate.c:237:22: error: implicit conversion from enumeration type
'GESEdge' to different enumeration type 'GESEditMode'
[-Werror,-Wenum-conversion]
GESEditMode edge = GES_EDGE_NONE;
~~~~ ^~~~~~~~~~~~~
ges-validate.c:277:41: error: implicit conversion from enumeration type
'GESEditMode' to different enumeration type 'GESEdge'
[-Werror,-Wenum-conversion]
new_layer_priority, mode, edge, position))) {
^~~~
https://bugzilla.gnome.org/show_bug.cgi?id=759758
Allowing application to force the asset system to recheck if an
asset has been "fixed" and can be used again
API:
+ ges_asset_needs_reload
Differential Revision: https://phabricator.freedesktop.org/D584
Otherwise we could have not negotiated errors in audiomixer when
the channel/channel-mask do not match
Differential Revision: https://phabricator.freedesktop.org/D493
Reviewed-by: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
We just need to make sure they are always serialized in the right
order (which is the case) and de serializing them will lead to the
right behaviour.
We should not serialize the priority as the priority of the source
itself depends on the action having been done on the parent clip,
and we do not serialize the source priorities (and should not, GES
should just do the right thing).
Differential Revision: https://phabricator.freedesktop.org/D491
