3 short-description: GstValidate configuration
6 # GstValidate Configuration
8 GstValidate comes with some possible configuration files
9 to setup its plugins and core behaviour. The config format is very similar
10 to the [scenario](gst-validate-scenarios.md) file format.
12 You can check the [ssim plugin](plugins/ssim.md)
13 and the [validate flow plugin](gst-validate-flow.md)
16 ## Core settings parameters
18 Config name should be `core`.
24 See [GstValidateVerbosityFlags](GstValidateVerbosityFlags) for possible values.
28 The [action type](gst-validate-action-types.md) to execute, the action type
29 must be a CONFIG action or the action type must have a `as-config` argument. When the `action`
30 is specified in a parameter, a validate action is executed using the other parameters of the
31 config as configuration for the validate scenario action.
36 GST_VALIDATE_CONFIG="core, action=set-property, target-element-name="videotestsrc0", property-name=pattern, property-value=blue" gst-validate-1.0 videotestsrc ! autovideosink
39 This will execute the `set-property, target-element-name="videotestsrc0",
40 property-name=pattern, property-value=blue` validate action directly from the
43 ### `scenario-action-execution-interval`
45 Default: `0` meaning that action are executed in `idle` callbacks.
47 Set the interval between [GstValidateScenario](gst-validate-scenarios.md) actions execution.
51 Default: `GST_CLOCK_TIME_NONE` - disabled
53 Set the maximum latency reported by the pipeline, over that defined latency the scenario will report
54 an `config::latency-too-high` issue.
58 Default: `GST_CLOCK_TIME_NONE` - disabled
60 The maximum number of dropped buffers, a `config::too-many-buffers-dropped` issue will be reported
61 if that limit is reached.
63 ### `fail-on-missing-plugin`
65 Default: `false` meaning that tests are marked as skipped when a GStreamer plugin is missing.
69 You can use variables in the configs the same way you can set them in
70 [gst-validate-scenarios](gst-validate-scenarios.md).
72 Defaults variables are:
74 - `$(TMPDIR)`: The default temporary directory as returned by `g_get_tmp_dir`.
75 - `$(CONFIG_PATH)`: The path of the running scenario.
76 - `$(CONFIG_DIR)`: The directory the running scenario is in.
77 - `$(CONFIG_NAME)`: The name of the config file
78 - `$(LOGSDIR)`: The directory where to place log files. This uses the
79 `GST_VALIDATE_LOGSDIR` environment variable if available or `$(TMPDIR)` if
80 the variables hasn't been set. (Note that the
81 [gst-validate-launcher](gst-validate-launcher.md) set the environment
84 You can also set you own variables by using the `set-vars=true` argument:
87 core, set-vars=true, log-path=$(CONFIG_DIR/../log)
90 It is also possible to set global variables (also usable from
91 [scenarios](gst-validate-scenarios.md)) with:
94 set-globals, TESTSUITE_ROOT_DIR=$(CONFIG_DIR)
97 ## `change-issue-severity` settings parameters
99 You can change issues severity with the `change-issue-severity` configuration
100 with the following parameters:
102 * `issue-id`: The GQuark name of the issue, for example: `event::segment-has-wrong-start`,
103 You can use `gst-validate-1.0 --print-issue-types` to list all issue types.
104 * `new-severity`: The new [`severity`](GstValidateReportLevel) of the issue
105 * `element-name` (*optional*): The name of the element the severity
107 * `element-factory-name` (*optional*): The element factory name of the elements the
108 severity change applies to
109 * `element-classification` (*optional*): The classification of the elements the
110 severity change applies to