| == 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. |