mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-04-26 06:54:49 +00:00
docs: add design and usage docs
This commit is contained in:
parent
a7353e988b
commit
3db8c081a9
2 changed files with 55 additions and 0 deletions
34
validate/docs/qa-design.txt
Normal file
34
validate/docs/qa-design.txt
Normal file
|
@ -0,0 +1,34 @@
|
||||||
|
|
||||||
|
== Main components
|
||||||
|
|
||||||
|
Gst-qa is composed of 3 parts: the monitors, the runner and the reports.
|
||||||
|
|
||||||
|
= Monitors
|
||||||
|
The monitors are used to wrap around pipeline (and elements and pads) and
|
||||||
|
attach to its data flow handling functions to be able to intercept the data
|
||||||
|
and compare it with the expected behaviors. There are 3 types of monitors:
|
||||||
|
|
||||||
|
* GstQaElementMonitor
|
||||||
|
* GstQaBinMonitor
|
||||||
|
* GstQaPadMonitor
|
||||||
|
|
||||||
|
All 3 inherit from the base GstQaMonitor 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 listenning to new childs 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 GstQaPadMonitor, as it is
|
||||||
|
where the data flow happens.
|
||||||
|
|
||||||
|
= Runner
|
||||||
|
The GstQaRunner is the point of communication for the app to gst-qa
|
||||||
|
monitoring. It provides an API to start monitoring a pipeline and then to
|
||||||
|
access the results.
|
||||||
|
|
||||||
|
= Reports
|
||||||
|
The GstQaReports are created when a check fails, it is posted to the runner
|
||||||
|
with information about the element that found the problem, along with details
|
||||||
|
about it.
|
21
validate/docs/qa-usage.txt
Normal file
21
validate/docs/qa-usage.txt
Normal file
|
@ -0,0 +1,21 @@
|
||||||
|
Using gst-qa is quite simple, there are 2 ways to test your pipeline/element.
|
||||||
|
|
||||||
|
== Creating a Runner
|
||||||
|
This method requires writing a specific application (or modifying yours) to
|
||||||
|
add a GstQaRunner to it. Create a GstQaRunner with gst_qa_runner_new
|
||||||
|
(GstPipeline *) and pass the pipeline you want to monitor to it.
|
||||||
|
|
||||||
|
Then call gst_qa_runner_setup to start up the qa system for your pipeline.
|
||||||
|
After that just use the GstPipeline as usual and the gst-qa system will
|
||||||
|
collect the reports. You can access them after your pipeline has stopped.
|
||||||
|
|
||||||
|
== Using LD_PRELOAD and an existing application
|
||||||
|
If you want to test an already existing application without modifying it. Just
|
||||||
|
use:
|
||||||
|
|
||||||
|
LD_PRELOAD=path/to/libgstqa.so yourapp ...
|
||||||
|
|
||||||
|
gst-qa will try to replace GstPipeline creating functions and already
|
||||||
|
configure runners for you, reports will be printed to stdout when they
|
||||||
|
are found.
|
||||||
|
|
Loading…
Reference in a new issue