It is not needed and pulling it in is causing a link problem with msvc.
Including ges-internal.h sets the default debug category in assets.c to
_ges_debug. Because _ges_debug is marked as DATA in the libges.def, it
will only be linked from libges.dll if it is marked in the source with
dllimport. Instead of messing with that we can just remove this include.
https://bugzilla.gnome.org/show_bug.cgi?id=775295
With the addition of the .def file for libges we need to make
sure the check-export script from common gets executed so that the
.def stays up to date.
https://bugzilla.gnome.org/show_bug.cgi?id=774641
The underlying integer type for enums are implementation defined and may
not be the same size as gint/guint. So implicitly casting from pointers-
to-enum-types to pointers-to-int-types is unsafe. MSVC warns on these.
https://bugzilla.gnome.org/show_bug.cgi?id=774641
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.
This keeps everything in a more consistent order and makes sure that the
base class is already set up completely before we start doing anything.
It also prevents from doing any setup if the base class fails, and
possibly not shutting things down again then.
https://bugzilla.gnome.org/show_bug.cgi?id=774480
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
In some cases when rippling clip we could get the algo lost because
a transition existed between two clips (for example at the end of c1
and at the begining of c2) but while rippling it would have required
a transition at the end of c2 and beginning of c1, and we were properly
not destroying the old one (as the two clips were in the moving context)
but we were still creating the other transition in the end...
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1362
We set TrackElement track type very early when creating effects
so it now uses that information to find TrackElement in clips
by track type.
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1370
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
Computation was not taking into account the fact that the start of
the element being moved could be at the middle of a group and not
necessarily at the start!
Fixes T7544
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1282
We were only concidering that we should let the group handle moving
transitions when changing transitions but in fact as soon as a
transition is happenning between two clips that are in a same group
the group properly handles moving the transition, so let the
group do its job.
Fixes T7543
Differential Revision: https://phabricator.freedesktop.org/D1281
