Apart from code readability, it allows compilers to detect wrong usages,
such as the call to gst_validate_action_new() which was using the wrong
argument
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=774638
Instead of trying to parsing stdout, generate json messages and
send them over a socket so that gst-validate-launcher can properly
have informations about gst-validate subprocess execution.
Keeping negotation information around and trying to figure
out precisely why the elements could not negotied the caps
when we get a NOT_NEGOTIATED error on the bus giving the
user details about it.
In the case and element is in READY or is going to READY state, it can
always return GST_FLOW_FLUSHING.
Avoid a race where a demuxer sinkpad has not been set to FLUSHING when we are
still processing a buffer but downstream is already FLUSHING and thus
the demuxer is already returning FLUSHING.
The user might have scenarios specific to a particular pipeline, and the
application might have several pipelines running and scenarios that
apply on specific pipeline. We have to handle that valid use case.
Summary:
Before returning GST_FLOW_ERROR, an element must post an ERROR GstMessage,
enforce that.
Reviewers: thiblahute, Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D201
Summary:
If from anything >= PAUSED to anything <= READY we can not query
pipeline position, so do not try to.
Depends on D168
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D169
We had quite a bit of code dedicated to handled GstPipeline monitoring
inside GstValidateBinMonitor, cleanly split that code into a new object
type
https://bugzilla.gnome.org/show_bug.cgi?id=740704
