We were implementing the logic for moving/trimming elements specific
to SourceClip but this was not correct ass the new timeline tree allows
us to handle that for all element types in a generic and nice way.
This make us need to have groups trimming properly implemented in the
timeline tree, leading to some fixes in the group tests.
This adds tests for the various cases known to not be handled properly
by the previous code.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/92
Previous usage of the property proxy-target seemed to alternate between
the two definitions:
+ The asset we are the default proxy of
+ The asset we are in the proxy list of
Now, the latter definition is used, which seems more useful to a user
since knowing the latter can easily allow you to find out the former.
The previous behaviour of ges_asset_set_proxy (asset, NULL) was not very
clear. It is now defined so that it clears all the proxies for 'asset'.
This means that after this call, the GESAsset:proxy property will indeed
be NULL.
Also fixed:
+ We can call ges_asset_set_proxy (asset, proxy) when 'proxy' is already
in the proxy list of 'asset'.
+ Handling of removing the default proxy in ges_asset_unproxy. This was
sending out the wrong notifies.
+ Prohibiting circular proxying. Before we could only prevent one case,
we should now be able to prevent all cases. This will prevent a hang
in ges_asset_request.
The test_proxy_asset test needs the internal method
ges_asset_finish_proxy. The test also uses the associated internal methods
ges_asset_try_proxy and ges_asset_cache_lookup. However, these are
marked with GES_API in ges-internal.h, which allows us access to them
here.
The new method is not marked as GES_API because it would not allow us to
remove the method in the future without removing it from the symbols list.
We do not want to add to the problem.
The test was simply commented out since we may wish to support tests
that access internal methods in the future using meson.
We should not be accepting ges_asset_set_proxy (NULL, proxy) as part of
the API! This behaviour was used internally in combination with
ges_asset_try_proxy, which is called on a still loading asset, so it was
moved to ges_asset_finish_proxy.
In the test_timeline.test_auto_transition, the corresponding xges only
has one layer, so we should only expect one layer when we extract the
timeline. This fixes a change that was missing from commit
d3e2cf55e3
We try to do our best to have the video frames scaled the best way
to fill most space on the final frames, keeping aspect ratio. The user
can later on rescale or move the sources as usual but it makes the
default behaviour a better and more natural especially now that we
set default restriction caps to the video tracks.
And fix the unit test to take that change into account
Basically we were advertising that the source size would be the
size of the track if it hadn't been defined by end user, but since
we started to let scaling happen in the compositor, this is not true
as the source size is now the natural size of the underlying video
stream.
Remove the unit test and reimplemented using a validate scenario which
make the test much simpler to read :=)
In general, brought the behaviour of the `start`, `duration` and
`inpoint` setters in line with each other. In particular:
1. fixed return value the GESSourceClip `duration` setter
2. changed the GESClip `start` setter
3. fixed the inpoint callback for GESContainer
4. changed the type of `res` in GESTimelineElement to be gint to
emphasise that the GES library is using the hack that a return of -1
from klass->set_duration means no notify signal should be sent out.
Also added a new test for clips to ensure that the setters work for
clips within and outside of timelines, and that the `start`, `inpoint`
and `duration` of a clip will match its children.
Aiming at fixing a rare race condition where we get:
../subprojects/gstreamer/libs/gst/check/gstcheck.c:1258:F:nlecomposition:test_seek_on_nested:0: nested_src0_0x1a1a310 is not destroyed, 1 refcounts left!
The idea is that there might have a remaining GstMessage
with the nested_src as `message.src` on the bus that has
yet to be processed in some conditions leading to a reference
still existing when unrefing the pipeline.
Subprojects simply consist of adding the GESProject
to the main project asset list. Then those are recursively
serialized in the main project in the <asset> not, when deserializing,
temporary files are created and those will be used in clips
as necessary
Otherwise if we shutdown a composition whith an nested composition
(inside a source in the test) and leak it, we end up with the nested
composition task still running (in READY) which is bad.
Add a test for that which leaks the pipeline on purpose.
This is implemented on top of a Tree that represents the whole timeline.
SourceClips can not fully overlap anymore and the tests have been
updated to take that into account. Some new tests were added to verify
that behaviour in greater details
Each timeline element is in a layer (potentially spanning
over several), it is very often useful to retrieve an element
layer priority (from an app perspective more than the element
priority itself as that is a bit of an implementation detail
in the end).
Port tests to it
