If you want a custom clip then you have to subclass GESClip,
This class was pre historicall and only used for testing purposes, we
have GESTestClip for that.
https://bugzilla.gnome.org/show_bug.cgi?id=706855
When duration or inpoint change, we need to remove edge control points,
and set new control points with interpolated values.
Also when duration == 0, we need to remove all control points, as otherwise
the controller will raise !is_end assertions.
It's the duty of the application to set keyframes back when duration gets
!= 0 again.
We actually do not need it has everywhere where we would need it we are
already locked against the timeline.dyn_lock, we need to make sure it is
always the case in the future.
The hierarchy of the mutex was wrong and could possibly lead to
deadlocks
This virtual method does not make much sense right now, we might need it
again later, but most probably with a sensibly different API so removing
it for now.
The idea is that we should first play until the time we reach the first
position, at that point we PAUSE the pipeline, then, afterward do the
seeks as asked.
If we get the position before the ASYNC DONE, just accept it.
Add a new test that creates a given number of layers. Each layer has the same
assets / clips shifted by a different amount in the timeline. Alpha and volume
properties are different for each layer. This test is similar to the mixer
example in:
http://gist.github.com/MathieuDuponchelle/5736992#file-mixit-py
We should be able to add more clips to each layer, but this example test only
tests mixing 1 clip across 4 layers.
Conflicts:
tests/check/ges/integration.c
This second set of seeking tests performs the seeks in a PAUSED
pipeline. After all seeks are successful, the pipeline is resumed so that the
test does not timeout.
Conflicts:
tests/check/ges/integration.c
We should make sure that the newly created trackelement are inside
a container when adding them to as this is needed for GESUriClip-s.
Also do not try to set a child property on the TrackElement itself.
https://bugzilla.gnome.org/show_bug.cgi?id=703152
Setting the profile on an encodebin can fail, and if that happens, there
will be no profile set at all, we should return FALSE in GESPipeline
when that happens
