The GstQaRunner is now a simple aggregator of reports that it receives
from monitors and filechecker. This allows it to be used in both
scenarios without APIs that expect GstElement or Monitors, that are
only used on the pipeline monitoring QA tests.
Adds a property that triggers the file playback tests on
GstQaFileCheker. Also enable it in the gst-transcoding post file checks.
The implementation is simple, just create a playbin2 and use fakesinks
as sinks, set it to playing and wait for either EOS or ERROR messages.
Use our own custom comparison to allow to add more fine grained error
reporting. Also the encoding profile is_equal function is too strict as
it also compares profiles names, that doesn't matter to us.
This commit implementation is still initial and needs improvements as it
isn't using the restriction caps, which includes information that might not be
on the profile format caps.
It is an object that is capable to run a few file checks. The
implemented tests are: file size, duration, if the file is seekable and
comparing the file stream types with a encoding profile
The pause action instructs the pipeline to go to paused state and then
return to playing. It has the argument 'duration', that indicates the
duration for which the pipeline will remain in paused
expose gst_qa_issue_register and gst_qa_issue_new to allow applications
to register their own custom issues.
Issues IDs should use Areas higher than GST_QA_AREA_OTHER for custom
areas. And to add more issues to existing areas, the IDs should be
higher than GST_QA_ISSUE_ID_CUSTOM_FIRST.
Custom issues registering should be done at startup and from the same
thread as there is no locking around the issues hashtable
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