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.
As such, they only emit a signal if their value changes, either through
their _set_inpoint or _set_max_duration methods, or through
g_object_set, etc.
Also, we now require the ->set_max_duration method to be implemented.
This was added to GESGroup, which will only allow the max-duration to be
set to GST_CLOCK_TIME_NONE.
Unless this property is set to TRUE, the in-point must be 0 and the
max-duration must be GST_CLOCK_TIME_NONE.
Also added EXPLICIT_NOTIFY flags to the active and track-type
properties such that their notifies are emitted only if the property
changes, even when the g_object_set, etc, methods are used.
Also added a missing notify signal to the set_active method.
Previously the control bindings were not properly copied into the pasted
clip. Also changed the order so that elements are added to the clip
before the clip is added to the timeline.
Add the child-property-added and child-property-removed signals to
GESTimelineElement.
GESContainer is able to use this to keep their child properties in sync
with their children: if they are added or removed from the child, they
are also added or removed from the container.
Hold the notify signals for the container and the children until after
the child has been fully added or removed.
After the previous commit, this was used to ensure that the
notify::priority signal was sent for children of a clip *after* the
child-removed signal. This stopped being the case when the code in
->child_removed was moved to ->remove_child (the latter is called before
the child-removed signal is emitted, whilst the former is called
afterwards). Rather than undo this move of code, which was necessary to
ensure that ->add_child was always reversed, the notify::priority signal
is now simply delayed until after removing the child has completed. This
was done for all notify signals, as well as in the add method, to ensure
consistency.
This allows the test_clips.py test_signal_order_when_removing_effect to
pass.
Also make subclasses take a copy of the list of the children before
setting the start and duration, since this can potentially re-order the
children (if they have the SET_SIMPLE flag set).
Previously, we relied on ->child_removed to reverse the priority changes
that occured in ->add_child. However, ->child_removed is not always
called (the signal child-removed is not always emitted) when a
->add_child needs to be removed. However, ->remove_child is always
called to reverse ->add_child, so the code was moved here. Otherwise, we
risk that the priorities of the clip will contain gaps, which will cause
problems when another child is added to the clip.
