This was keeping around 500-700kB of data for each test, which was
gradually raising memory usage of a full run by 100MB+
The reports are definitely not needed, and we only need to keep
information from the subprocess env variable that we might need
later on for final reporting
The xml-based MediaDescriptor were keeping open the XML file and the
associated ElementTree structures, resulting in memory usage of several
hundred megabytes.
Instead cache the information we need immediately and release the
XML structure
Since we now check position/status of pipeline at regular intevals,
we no longer need to impose a different timeout based on the
protocol used.
Avoids having 4min long timeouts for no reason (30s is enough)
Instead of creating a separate TCPServer for each test, just create
one which handles all connections in a threaded fashion.
Shaves off ~500ms per test
https://bugzilla.gnome.org/show_bug.cgi?id=791159
When the --shuffle option is used, the tests will be run out of order.
This optimizes CPU utilization since it allows running synchronized
and unsynchronized tests at the same.
stopping the subprocess is done from the main thread, this would
throttle starting/stopping any tests by one second.
Start with 50ms, and gradually increase the wait between iterations
So that Test from several TestManager can run in parallel and thus avoid
waiting for tests from one TestManager to run the following one.,
Also by design TestsLauncher should always have been the responsible for
... launching tests.
WARNING: The variable(s) 'DATADIR', 'LIBDIR' in the input file
'subprojects/gst-devtools/validate/launcher/config.py.in' are not
present in the given configuration data
WARNING: Passed invalid keyword argument "scanobj_args". This will
become a hard error in the future.
WARNING: Keyword argument "install" defined multiple times. This
will be a an error in future Meson releases.
Make sure to use it where appropriate and add some logging when
setting an object property from an action.
And use the valgrind.conf to set all the properties instead of having
a mixture of a config scenario and the config file (making sure the
max-lateness is set on any sink)
Note: The notion of "live" here is in the *content* sense and not in the
GStreamer sense.
Ex:
* A rtsp stream is always "live" in the GStreamer sense but might not always
provide live content.
* HLS/DASH streams are not "live" in the GStreamer sense but might
provide "live" content.
Some scenarios might:
* require live content
* not be compatible with live content
This patch adds two new properties for scenarios:
* live_content_required (default False) for scenarios that can only work with
live content.
* live_content_compatible (default False) for scenarios that can work with
both live and non-live content.
This patch adds support for reading a "live" property from stream_info
Try to emulate a bit better a real video sink by making the video
fakesink handle/calculate/report QoS.
Also use the same lateness value as default videosink
