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.
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
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.
Remove error from GstQaErrorReport, making it only GstQaReport. Add
a level and use area and subarea code, with an extra string for message
adding details.
Provide macros on qa-monitor to make it easy to create reports.
Do not take the initial format set to TIME too seriously when we
haven't got any newsegment event yet. If it is the first segment
received, switch our internal segment tracker to the event format
Segments, upstream seeks and flushes. Adding the following checks:
* A flush stop is expected after a flush start
* After a seek, the flushes/segment seqnum should be the same as the seek
The base class adds a 'object' property to hold the monitored object,
it can only be set on construction. Also the constructor now
automatically calls the element set up
