mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-03 05:05:52 +00:00
60 lines
2.5 KiB
Plaintext
60 lines
2.5 KiB
Plaintext
== Main components
|
|
|
|
Gst-validate is composed of 4 parts: the issues, the reports, the runner and
|
|
the reporters.
|
|
|
|
= Issue
|
|
Gst-Validate's main target is finding problems in GStreamer elements/pipelines.
|
|
To make it easier to track down exactly what happens, the tests run by
|
|
Gst-Validate use an extensible list of 'Issues'. Each Issue describes a
|
|
potential error situation and has an unique ID and a severity level.
|
|
|
|
The issues list can be extended by 3rd party libraries if specific needs
|
|
should be met.
|
|
|
|
= Reporters
|
|
A reporter is the object that implements the GstValidateReporter interface and
|
|
is responsible for performing tests on some target element/scenario. The
|
|
reporter is able to create 'Reports' whenever a test it executes fails.
|
|
|
|
= Reports
|
|
The GstValidateReports are created whenever a test fails, they are posted to the
|
|
stderr and also are posted to the GstValidateRunner for accumulation.
|
|
|
|
Each report contains information about the object that generated the issue,
|
|
the issue associated with the report and a specific debug message for the case,
|
|
this helps tracking down the problem and fixing it.
|
|
|
|
= Runner
|
|
The GstValidateRunner is the point of communication for the app to gst-validate
|
|
monitoring. It provides an API to gather reports and to make them accessible
|
|
to the application.
|
|
|
|
== Reporter types
|
|
|
|
= Monitors
|
|
The monitors are used to wrap around pipelines (and elements and pads) and
|
|
attach to their data flow handling functions to be able to intercept the data
|
|
and compare it with the expected behaviors. There are 3 types of monitors:
|
|
|
|
* GstValidateElementMonitor
|
|
* GstValidateBinMonitor
|
|
* GstValidatePadMonitor
|
|
|
|
All 3 inherit from the base GstValidateMonitor class. Their name suggest what
|
|
they monitor and they have a relationship to their children and parents. A bin
|
|
monitor has, possibly, child element monitors and element monitors have child
|
|
pad monitors. The monitors are responsible for listening to new children added
|
|
to their monitored object and creating monitors for them. For example, element
|
|
monitors listen to element's pad-added signal and create pad monitors whenever
|
|
a new pad is added.
|
|
|
|
Most (if not all) the checks are implemented at the GstValidatePadMonitor,
|
|
as it is where the data flow happens.
|
|
|
|
= FileChecker
|
|
The file checker is another reporter that is used to make sure a file has a
|
|
few expected properties. It inspects the file and compares the results with
|
|
expected values set by the user. Values such as file duration, file size, if
|
|
it can be played back and also if its encoding and container types.
|