gst-validate has a hard-dep on json-glib-1.0 so maintain optionality of
it all by only dragging it in as a fallback if we know we can satisfy
the dependencies.
Generating those files is useful for users building the GStreamer stack
using meson and having to link it to another project which is still
using the autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=776810
We were using the actual mixer pad to release the smart mixer
pad, which seemed to be on purpose, but was not properly handle,
moreover, it is now forbiden to pass a pad not inside a GstElement
when releasing it.
Also properly remove ghost pads from Smart mixer, we were planly
failling at it.
Do not list all the possible options in the man page but only the help
options.
This is in order to avoid duplication and prevent the man page from
becoming obsolete in case the options change in the code but do not get
updated in the man page.
https://bugzilla.gnome.org/show_bug.cgi?id=776063
It was making no sense to loose the information about the pspec itself
to retrieve the child associated to it and was failling when we were
forcing the AssociateType::prop synthax
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
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
