docs: Document validate core configuration

docs/gst-validate-config.md

@@ -6,17 +6,64 @@ short-description: GstValidate configuration
 # GstValidate Configuration
 
 GstValidate comes with some possible configuration files
-to setup its plugins (and potentially core behaviour),
+to setup its plugins and core behaviour, The config format is very similar
+to the [scenario](gst-validate-scenarios.md) file format.
 
 You can check the [ssim plugin](plugins/ssim.md)
 and the [validate flow plugin](plugins/validateflow.md)
 for examples.
 
+## Core settings parametters
+
+Config name should be `core`.
+
+### `verbosity`
+
+Default: `position`
+
+See [GstValidateVerbosityFlags](GstValidateVerbosityFlags) for possible values.
+
+### `action`
+
+The [action type](gst-validate-action-types.md) to execute, the action type
+must be a CONFIG action or the action type must have a `as-config` argument. When the `action`
+is specified in a parametter, a validate action is executed using the other parametters of the
+config as configuration for the validate scenario action.
+
+#### Example:
+
+```
+GST_VALIDATE_CONFIG="core, action=set-property, target-element-name="videotestsrc0", property-name=pattern, property-value=blue" gst-validate-1.0 videotestsrc ! autovideosink
+```
+
+This will execute the `set-property, target-element-name="videotestsrc0",
+property-name=pattern, property-value=blue` validate action directly from the
+config file
+
+### `scenario-action-execution-interval`
+
+Default: `0` meaning that action are executed in `idle` callbacks.
+
+Set the interval between [GstValidateScenario](gst-validate-scenarios.md) actions execution.
+
+### `max-latency`
+
+Default: `GST_CLOCK_TIME_NONE` - disabled
+
+Set the maximum latency reported by the pipeline, over that defined latency the scenario will report
+an `config::latency-too-high` issue.
+
+### `max-dropped`
+
+Default: `GST_CLOCK_TIME_NONE` - disabled
+
+The maximum number of dropped buffer, a `config::too-many-buffers-dropped` issue will be reported
+if that limit is reached.
 
 ## Variables
 
-You can use variables in the configs the same way you can
-set them in [gst-validate-scenarios](gst-validate-scenarios.md).
+You can use variables in the configs the same way you can set them in
+[gst-validate-scenarios](gst-validate-scenarios.md).
 
 Defaults variables are:
 
@@ -25,10 +72,10 @@ Defaults variables are:
 - `$(CONFIG_DIR)`: The directory the running scenario is in.
 - `$(CONFIG_NAME)`: The name of the config file
 - `$(LOGSDIR)`: The directory where to place log files. This uses the
-   `GST_VALIDATE_LOGSDIR` environment variable if avalaible or `$(TMPDIR)`
-   if the variables hasn't been set. (Note that the
+   `GST_VALIDATE_LOGSDIR` environment variable if avalaible or `$(TMPDIR)` if
+   the variables hasn't been set. (Note that the
    [gst-validate-launcher](gst-validate-launcher.md) set the environment
-   variables.
+   variables).
 
 You can also set you own variables by using the `set-vars=true` argument:
 
@@ -36,8 +83,8 @@ You can also set you own variables by using the `set-vars=true` argument:
 core, set-vars=true, log-path=$(CONFIG_DIR/../log)
 ```
 
-It is also possible to set global variables (also usable from [scenarios](gst-validate-scenarios.md))
-with
+It is also possible to set global variables (also usable from
+[scenarios](gst-validate-scenarios.md)) with:
 
 ``` yaml
 set-globals, TESTSUITE_ROOT_DIR=$(CONFIG_DIR)

docs/sitemap.txt

@@ -4,6 +4,7 @@ index.md
 	gst-validate-media-check.md
 	gst-validate-launcher.md
 	gst-validate-scenarios.md
+	gst-validate-config.md
 	gst-validate-environment-variables.md
 	gst-validate-action-types.md
 	ges-validate-action-types.md