Pipelines declared in gst-integration-testsuites can rely on the validate HTTP
server, so when an URI pointing to it is detected, advertise the server as
needed before starting the test.
For this to work the test scenario should explicitely declare the pipeline uri,
as shown in this example:
"some_playbin3":
{
"pipeline": "playbin3 uri=%(uri)s video-sink=%(videosink)s",
"config": [
"%(validateflow)s, pad=sink:sink"
],
"scenarios": ["play_15s"],
"uri": "http://127.0.0.1:%(http-server-port)s/defaults/html/foo.html"
}
This means that we can now pass any extra key that `populate_tests`
expects, meaning any key expected by FakeMediaDescriptor and
a few other keys supported by the methods such as
`expected-issues` and `extra_env_vars`
Instead of having the issues centered on the test classes, they
are now focusing on the "bug".
And harmise names on `expected_issue` not `expected_failures`
validateflow can be used to check the buffers and events flowing through
a custom pipeline match an expectation file. This can be used to test
non-regular-playback use cases like demuxers handling adaptive streaming
fragment pushing.
This patch includes also new actions used for these cases:
`appsrc-push`, `appsrc-eos` and `flush` (plus `checkpoint`, which is
only available with validateflow).
When defining pipelines_descriptions to run test on in a `.json` file, you might
need to point to paths in the testsuite directory (for media files URIs
for example), you can now do
`"pipeline": "filesrc location="$(config_path)s/../medias/some/file.mkv...`
Introducing the `.media_info.push` media info extension, which is meant
to let the launcher know that those file should run with the "pushfile://"
protocol.
And allow symlinking "normal" `.media_info` to their `.pushfile` variant
so that both can share the exact same content.
This is useful when you want to check only the demuxer output.
- Keep the information in the media file so that we can launch media-check
with the proper arguments in the launcher. Update it accordingly.
- Refactor compare_streams to simplify it, which in the end leads to
reporting all the issues instead of exiting on the first one.
We will run a simple pipeline with the IQA element to run ssim (dssim)
tests on the rendered files, comparing it with a reference file.
For now we use the very empiric 1.0 value as a ssim error threshold and
the goal is basically to detect completely broken renderings.
The issue is closed upstream (because of concentrating on decodebin3
instead), and initial forever testing seems to show the issue doesn't
happen anymore
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)
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
