Shared objects listed in GST_QA_OVERRIDE are loaded on startup,
and the symbol gst_qa_create_overrides is run. It should create
any override needed. While it can do anything it wants, this
is discouraged.
GST_QA_OVERRIDE should be a comma separated list of shared objects,
any relative paths should be from the current working directory
at the time they are loaded (ie, if the process to be traced
changes cwd, use absolute paths).
No attempt whatsoever is made at not running what was not meant.
Includes a sample shared object for illustration purposes.
Overrides can now be registerd by gtype, meaning that they will
be attached to monitors that the target is of the requested type.
Also by element klass, that will check that the element has the
selected class in its details
It is used to iterate over overrides and modify the report level if
the overrides wants to do so.
Also adds a new mutex only for the overrides to avoid deadlocks when
reporting if we used the same lock for iterating the overrides
Reports now point to Issues, that are uniquely identified and have
translatable descriptions. This way we are going to be able to uniquely
identify the issues and applications can enable/disable checks for
specific elements.
That was never set, but it is needed for the reporter to properly add
reports to the runner.
We still keep a reference on the monitor to make things simpler
This way we can report issues from a scenario
Also add a Seek aread to the known areas list
We now need to pass the runner to the scenario instead of the
pipeline as the GstQaReporter interface needs it.
Various type of object should be able to do some reporting, so we have
to make sure all the code to do that is in one place. Creating an interface
makes it simple to share information and it avoid to have a baseclass for
something that is not actually important enough to create a baseclass.
Conflicts:
gst/qa/gst-qa-pad-monitor.c
A scenario correspond to a suite of action to execute on a pipeline,
for the time being, we only support seeking the pipeline, but in the
future we can imagine doing some queries, setting pipeline state, etc...
The scenario can be loaded thanks to the GST_QA_SCENARIO environment
variable, making it usable with any existant application, in case, the
application can be used interactively, the user should either, not load
any scenario or let the application run without interacting with it.
When handling elements that spawn multiple threads (hardware
enc/decoders), the pad monitor has to protect its variables specially
because some checks involve iterating over internally linked pads to
add/get some data for comparison (expected events, timestamp ranges,
caps).
Aside from locking its own mutex, the pad monitor can also lock the
parent's mutex when it needs to use data from its internally linked
pads. The locking order should always be parent and then individual
pad-monitor mutexes. This should prevent deadlocks when multiple
pad-monitors from the same element start doing checks at the same time
from different threads.
Only check if fields are proxied for sink getcaps as it is when
downstream restrictions should be proxied. Also improve the
fields comparison to handle single value x multi value
(list/array/range) contain relations.
Replace the macro with a more powerful variadic function that can
check for more acceptable types for the same caps.
This removes a few more false positives
flush events shouldn't fail, so we don't need to rollback when it
returns false from downstream (this is common when downstream is still
not-linked) and it would cause gst-qa to spit false positives.
Also refactor the common event handling for both sink and src event
functions into a common place. Currently we handle flushes the same
for both pad's directions
Keep the full range stored by the element in the monitor and check
if outgoing timestamps are within that range. It is simple and
should generally work.
