We might receive another seek from the application while the action task is
handling a previous seek (and thus setting seeking_itself to TRUE). To prevent
this seek to go through directly instead of being added as an action, also
check if the seek event was received from our action task thread or some other
thread.
https://bugzilla.gnome.org/show_bug.cgi?id=767053
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
When nlecomposition is finalized with pending add action or io,
associated elements are not unreffed as they should since caller gives
us the reference when calling gst_bin_add causing them to be leaked.
So to make sure we don't leak a reference on element when adding one to
the bin, each stage (action and pending_io) hold a reference on element
and release it when stage is done.
https://bugzilla.gnome.org/show_bug.cgi?id=766455
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
Summary:
sanitized_timeline is created when parsing command line,
but it isn't free'd.
Reviewers: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D382
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
