We have an optiominisation to avoid double seeks when a seek is passed
the end of the current stack. The problem, is that we no longer flush
the pipeline when this code is reached. This patch comments out this
optimization adding a FIXME. As mention, flushing the stack instead of
seeking would work, but does not seem trivial considering all the
mechanic inplace to forward or not the events.
https://bugzilla.gnome.org/show_bug.cgi?id=787405
The allocation query may block on the sink when in pause. As a side effect, we
may never get a buffer now that tee does forward the allocation query.
This would often lead in a pipeline stall.
https://bugzilla.gnome.org/show_bug.cgi?id=787405
Otherwise they will just be the ones from the previous seek event/
stack setup and be meaningless.
Also document the priv->segment meaning.
Fixes https://phabricator.freedesktop.org/T7796
To avoid a race when tearing down the composition (PAUSED_TO_READY),
we should make sure to tear down the current stack and let the GstBin
class handle the remaining thing to do during the change state.
We should still ignore any error happening when tearing down the
bin state just in case.
https://bugzilla.gnome.org/show_bug.cgi?id=775051
This reverts commit 57d40bec1a.
Apparently it causes timeouts in the unit tests on Jenkins and
Thibault's machine, and in the gst-validate tests.
Caused by elements staying in PAUSED and waiting to be set to PLAYING.
Needs further investigation.
Otherwise we could set the state of the children to PAUSED already (i.e.
start dataflow) from the composition's task, while the composition
itself is currently chaining up to the parent class' change state
function and did not activate the pads yet. This causes buffers and
events to be discarded, and everything to stop with a not-negotiated
error.
https://bugzilla.gnome.org/show_bug.cgi?id=774480
The seek action might currently be handled (in which case it is not in
the actions list and the action lock is not locked), but not actually
handled completely yet (the seqnum is not stored yet).
To prevent this, we remember what the current action is that is being
handled, and also compare to that.
https://bugzilla.gnome.org/show_bug.cgi?id=774149
Those tag are meaningless in for the new stream created by the composition
First step toward fixing T3070
Differential Revision: https://phabricator.freedesktop.org/D1327
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
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
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
Those error are really critical and we are then enable to keep
working. Just post an ERROR message on the bus and let the
application deal with it.
Reviewed-by: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Differential Revision: https://phabricator.freedesktop.org/D740
Summary:
After invoking GClosure, the item of action list becomes
orphan so it lost a chance to be freed. In addition, even
when disposing, the list of actions has few items so we
have to check the list.
Reviewers: thiblahute
Projects: #gstreamer_editing_services
Reviewed By: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D324
