gstreamer/validate/docs/validate-design.txt

62 lines
2.5 KiB
Text
Raw Normal View History

2013-07-19 14:14:39 +00:00
== Main components
2013-09-02 16:22:51 +00:00
Gst-validate is composed of 4 parts: the issues, the reports, the runner and
the reporters.
2013-08-08 15:35:50 +00:00
= Issue
2013-09-02 16:22:51 +00:00
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.
2013-08-08 15:35:50 +00:00
The issues list can be extended by 3rd party libraries if specific needs
should be met.
= Reporters
2013-09-02 16:22:51 +00:00
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.
2013-08-08 15:35:50 +00:00
= Reports
2013-09-02 16:22:51 +00:00
The GstValidateReports are created whenever a test fails, they are posted to the
stderr and also are posted to the GstValidateRunner for accumulation.
2013-08-08 15:35:50 +00:00
Each report contains information about the object that generated the issue,
2013-08-27 08:38:52 +00:00
the issue associated with the report and a specific debug message for the case,
2013-08-08 15:35:50 +00:00
this helps tracking down the problem and fixing it.
= Runner
2013-09-02 16:22:51 +00:00
The GstValidateRunner is the point of communication for the app to gst-validate
2013-08-08 15:35:50 +00:00
monitoring. It provides an API to gather reports and to make them acessible
to the application.
== Reporter types
2013-07-19 14:14:39 +00:00
= Monitors
2013-08-27 08:38:52 +00:00
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
2013-07-19 14:14:39 +00:00
and compare it with the expected behaviors. There are 3 types of monitors:
2013-09-02 16:22:51 +00:00
* GstValidateElementMonitor
* GstValidateBinMonitor
* GstValidatePadMonitor
2013-07-19 14:14:39 +00:00
2013-09-02 16:22:51 +00:00
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
2013-07-19 14:14:39 +00:00
monitor has, possibly, child element monitors and element monitors have child
2013-08-27 08:38:52 +00:00
pad monitors. The monitors are responsible for listening to new children added
2013-07-19 14:14:39 +00:00
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.
2013-09-02 16:22:51 +00:00
Most (if not all) the checks are implemented at the GstValidatePadMonitor,
as it is where the data flow happens.
2013-07-19 14:14:39 +00:00
2013-08-08 15:35:50 +00:00
= 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.
2013-07-19 14:14:39 +00:00