GitLab

As they are used in the testsuite to define known issues

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.

Allow 'pipeline' fields in validateflow to be interpolated with
directory keys like $(medias)s.

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.

And... add some expression parser unit tests

- 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.

Mainly so it can be used in unit tests.

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 we will be able to use 'set-vars' for it

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.

gst_validate_utils_get_clocktime() is resetting the value if it's not
present in the struct so we were overriding it on the next iterations.

We were missing the env variables in the command written to the log
file, making it impossible to re-run the test later from the logs.

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.

This reverts commit 05ce6d3b.

We can't do that as it breaks meson logic to set envvars

Do it once only once it is fully populated

Running it takes quite some time and we can easily cache it.

It's all handled from the same thread.

We want to early return if either no max value has been set for the
scenario or if we didn't receive any QoS information.

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).

self.proc_env is created when starting the test but this API can be call
by generator when creating the test.

The 'max-dropped' description field can now be used to specify the max
number of buffers than can be dropped by the QoS system.

The 'max-latency' description field can now be used to specify the max
latency allowed for the running pipeline.

Our RTSP server is not accurate, it makes no sense to perform
accuracy checks on the client-side segments.

Those are not consts are they can be modified at runtime

Now that we do not print infos about successful tests when redirecting.

There are cases where a crash happens after the program ends