docs: add design and usage docs
authorThiago Santos <thiago.sousa.santos@collabora.com>
Fri, 19 Jul 2013 14:14:39 +0000 (11:14 -0300)
committerThiago Santos <thiago.sousa.santos@collabora.com>
Fri, 19 Jul 2013 14:14:39 +0000 (11:14 -0300)
validate/docs/qa-design.txt [new file with mode: 0644]
validate/docs/qa-usage.txt [new file with mode: 0644]

diff --git a/validate/docs/qa-design.txt b/validate/docs/qa-design.txt
new file mode 100644 (file)
index 0000000..d216234
--- /dev/null
@@ -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.
diff --git a/validate/docs/qa-usage.txt b/validate/docs/qa-usage.txt
new file mode 100644 (file)
index 0000000..404e1f6
--- /dev/null
@@ -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.
+