This action can be used to change the rank of a particular element,
so you can force a particular element to be used when using
autoplugging elements (such as decodebin, encodebin, and friends)
This type of actions is used to change some parametter on GStreamer
core and it plugins, it can be fore example, to change the rank of a
plugin or things like that.
It is a random number, but it will in most cases give people a hint
that gst-validate reported a critical issue, and thus set the return
code, only by looking at it
Also make use of gst_validate_runner_print() in
gst-validate-transcoding.c as we were copy pasting that method there.
Always keep probing the pipeline for the current position and compare
with the latest requested seek segment to detect if the seek boundaries
are being respected
The "switch-track" command can be used to switch tracks. The "type"
argument selects which track type to change (can be "audio", "video",
or "text"). The "index" argument selects which track of this type
to use: it can be either a number, which will be the Nth track of
the given type, or a number with a "+" or "-" prefix, which means
a relative change (eg, "+1" means "next track", "-1" means "previous
track").
Conflicts:
validate/gst/validate/gst-validate-scenario.c
When used with LD_PRELOAD, the application might use various pipelines
for several different thing, we need to make it possible to spcify a
specific pipeline (or set of pipelines) on which to run the scenario.
The format is in the form of:
scenario_name:pipelinename_pattern*
Improve buffer timestamp range check:
* Only do it for encoders or decoders
* Audio has an acceptable tolerance of 100ms
To do this, keep track of the caps on the pad and store
if it is dealing with audio or video
Allows both src and sink pad to keep track of the current caps, but
the duplicated caps check is still only applied to sink pads as
src pads can push the same caps multiple times when it isn't linked
Makes the result a bit more readable than a compact multi-line list.
FIXME: Figure out how to print the description of the issues (which can
spawn multiple lines) in a nice way.
Tag events are hard to track and check if properly serialized because
they mutate too much inside elements. There is no reliable way currently
to match a tag event pushed into an element and another tag event
leaving the element (other than if the pointers are actually the same).
