So it can be used directly in the documentation Also add a special "all"
argument to `gst-validate-1.0 --inspect-action-type` so we can generate
the documentation for all action types easily.
_Q_VALIDATE_MONITOR was defined twice because it wasn't declared
as extern in the header, so it would be defined as variable in all
included files. This doesn't seem to cause problems on Linux, but
seems to cause build failures on macOS.
Fixes#42
Basically nothing guarantees that the set of pads we aggregated the flow
for is the same as the one that was aggregated during the actual data
flow as some pads could have been removed meanwhile.
Commit 394242c224 ("validate:scenario: Enhance variable
implementation") caused the duration parameter to be stored
as a double instead of GstClockTime, which the _execute_pause
implementation expects. Fix the parameter type and use
gst_validate_action_get_clocktime to handle duration correctly.
https://gitlab.freedesktop.org/gstreamer/gst-devtools/merge_requests/73
There is a mockdecryptor that has been added into validate-sources and
this element is base on GstBaseTransform. This added a deps against
gstbase which was leading to linking errors when building with meson.
Especially the init section and the --quiet.
Remove the whole manual build/source dir include addition
to the g-ir-scanner args seeing that things worked fine
without the args being passed to the scanner at all.
Previously validateflow tests did not fail when the pad was not
attached.
This was a limitation caused by how the Validate API worked. Before, the
`notify::validate-runner` signal was not emitted until a monitor was
attached to the override. This made impossible to listen for the
runner's `stopping` signal.
This patch fixes the problem by setting `validate-runner` for all
existing overrides when the runner is initialized and adding checks in
validateflow to error in the case no pad was attached.
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
