While in many cases it's desirable to wait for a buffer to be pushed
downstream when using appsrc-push, in some cases this is not possible as
such pushing action is dependent on following actions that would not be
executed if we wait.
An example for this is prerolling:
appsrc ! qtdemux ! video/x-h264 ! decodebin name=dec ! %(videosink)s
description, seek=false, handles-states=true
appsrc-push, target-element-name=appsrc0, file-name="raw_h264.0.mp4"
set-state, state=playing
appsrc-eos, target-element-name=appsrc0
In order for the preroll to occur, both the appsrc needs to push the
buffer and the state needs to reach PLAYING. But `set-state` cannot
finish if the buffer has not been pushed (the state transition does not
finish) and conversely pushing the buffer will not finish until the
state has reached.
Making appsrc-push not wait for the buffer solves this problem. This
patch makes appsrc-push aware of this issue by only waiting for the
buffer to be pushed if the pipeline is in a state that allows buffers to
flow.
Since gst_validate_action_set_done() is asynchronous, the bus EOS
handler may already be running before the action is actually finished.
This patch ensures that is not a problem.
This change allow tests to check performance of elements by checking the
frequency at which buffers are pushed on src pads.
I re-used most of the logic from fpsdisplaysink to compute the
frequency.
We can now uses something like:
GST_VALIDATE_CONFIG='core,min-buffer-frequency=60,target-element-factory-name=v4l2src'
The 'buffer-frequency-start' optional field can be used to ignore the
frequency during the start of the pipeline. This is useful when testing live
pipelines where configuring and setting up elements can take some time slowing
down the first buffers.
- Stop arbitrarily consider params as ClockTime based on their names
but add a convetion that the `.type` field of the ActionType should
end by `(GstClockTime)` when it is a clock time.
And require them to follow the `$varname` (can't be $(varname) as
parenthesis have another meaning in those expressions).
Still accept "duration" and "position" as varname for backward compat
but update our scenarios anyway.
This way it is clear that you are using a variable reading the scenario
and we can verify that what the scenario writer intents is to use an
already set variable.
There was a race in appsrc-push when the pushed buffer caused an EOS.
The EOS event could be handled by the main thread, finishing the test
while the action, executing in the streaming thread, has not finished
yet.
A mutex is now introduced to add mutual exclusion for the two threads so
that an EOS does not cause the termination of the test while the action
is still going.
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).
This is particularly useful for scenario that define constants
that are used to check video frame checksum for example, we can
now have one single 'scenario' file that defines consts for the
checksum of the frames, and those can be reused everywhere.
gst_validate_override_register_by_name() was not working when using a
pad name because by the time gst_validate_pad_monitor_do_setup()
was called to set the name of the monitor it was too late for overrides
to have any effect.
Patch written by Thibault.
You often want to make sure that elements from a particular plugins
are always/never plugged, `set-rank,name=plugin-name,rank=XXX` allows
you to simply do that.
Any local variable related to the stream should be resetted
when the pad is deactivated
Avoids weird issues when elements are re-used (and pads are deactivated
and reactivated).
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.
It fails to generate gst-validate-enum-types.h and gst-validate-enum-types.c
when build out of source tree. Add the path for template files.
https://bugzilla.gnome.org/show_bug.cgi?id=795531
Signed-off-by: Kai Kang <kai.kang@windriver.com>
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
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
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)
When those are special cased to support that, such as the `set-property`
action.
This special handling was added in
4927c65710
validate: disable QOS features when running with valgrind
before we started to support executing arbitrary config action from
configuration files.
Apart from code readability, it allows compilers to detect wrong usages,
such as the call to gst_validate_action_new() which was using the wrong
argument
