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
User needs to specify the enum value as a string, to be used
as with gst_util_set_object_arg.
Also enhance reporting and verify that the set value has actually
been taken into account.
The fact that Scenario.pipeline was not accessible in a thread way lead
to the fact that all users had to take the unref the last pipeline ref
in the main thread, otherwise we were crying. This was an ugly
restriction which lead to issue when using scenario on gst-rtsp-server.
This break the API as this commit remove the GstValidateScenario.pipeline
field but it is worth it.
Since glib version 2.54, g_object_newv() is deprecated.
This patch changes that function with a simpler g_object_new(),
since no properties are set.
https://bugzilla.gnome.org/show_bug.cgi?id=782860
When replacing an action structure, also update the action name with
the (new) name from the new structure. Otherwise we end up with
a bogus name from the previous (deleted) structure.
The name of the action comes directly (i.e. not copied) from the
contained GstStructure field. Therefore make sure to take that
name from the proper structure field (copied just before) and
not from an outside one.
And let following actions to be executed (setting the action as
INTERLACED) which will make sure the track switch happened at some
point. It means the user has to set the pipeline to PLAYING so we can
make it works but we do not have choice here I think
https://bugzilla.gnome.org/show_bug.cgi?id=781213
Protect the expected seek values with the same lock as the one
that will be used to read/validate the resulting segments and flush
values.
Avoids races with duplicated seeks (i.e. a seek that was already
sent and handled via another pad, such as in demuxers).
https://bugzilla.gnome.org/show_bug.cgi?id=781112
We want to be able to do GstValidate.Monitor and not
GstValidate.ValidateMonitor.
And do not pass header to the list of sources to build libraries as
it is not needed.
