mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-03-28 20:05:38 +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