Sub action will allow user to executed action *right* after the
previous action has been completed, meaning in the end that both
action can be considered as one single action.
+ Factor out a function to fill an GstValidateAction structure from a
GstStructure
+ Factor out a function to set action playback time
The new action might change the position on purpose and we should not
fail in that case.
Also at that point we know the test of position after the seek has
been executed
+ Minor cosmetic fixes
https://bugzilla.gnome.org/show_bug.cgi?id=743994
An interlaced action is an action that will be executed ASYNC but
without that will not block following actions during its execution.
The action should be set to done later on at any point during the
execution of the scenario.
API:
+ GST_VALIDATE_EXECUTE_ACTION_INTERLACED
+ GST_VALIDATE_ACTION_TYPE_INTERLACED
https://bugzilla.gnome.org/show_bug.cgi?id=743994
This action type can take some time, we need to make sure that the
combiner/input-selector element properly pushed a buffer marked
as DISCONT to concider the action is done.
https://bugzilla.gnome.org/show_bug.cgi?id=743994
We should be able to execute the next action as soon as the previous
one is fully completed, make sure the code tries to do that and does
not artificially add some waiting time.
And make sure if the gst_validate_action_set_done is called from outside
our execution thread, we do not try to execute anything
https://bugzilla.gnome.org/show_bug.cgi?id=743994
+ And implement a corrupt-socket-recv action
+ Only compile this on Linux, LD_PRELOAD won't work on Windows.
For now the registering of the action is done through
a call to socket_interposer_init, this will get better
when we refactor the action logic.
https://bugzilla.gnome.org/show_bug.cgi?id=743871
As caps events are downstream, caps set travels from sinks to
sources. Adding pending setcaps values to sink pads makes no sense
as when a new caps is set on the sink it would compare with values
currently set on the source pad, causing a critical failure when
renegotiation happens.
If the user did not specify any playback time we should be able to
execute actions even if the pipeline can't answer the position query
+ Make simpler to read the conditions of an action execution
The ->execute function now return a GstValidateExecuteActionReturn
which can be set as ASYNC in order to tell the scenario that the action
will be executed asynchronously, when the action is done, the caller is
responsible for calling gst_validate_action_set_done(); so that the
scenario keeps going on.
In this commit we make sure that the old API keeps working as
GST_VALIDATE_EXECUTE_ACTION_ERROR == FALSE and
GST_VALIDATE_EXECUTE_ACTION_OK == TRUE
Morevover GstValidateExecuteActionReturn is just a define
API:
+ gst_validate_action_set_done
+ GstValidateExecuteActionReturn
https://bugzilla.gnome.org/show_bug.cgi?id=739854
We had quite a bit of code dedicated to handled GstPipeline monitoring
inside GstValidateBinMonitor, cleanly split that code into a new object
type
https://bugzilla.gnome.org/show_bug.cgi?id=740704
Depending on the type of event where the bug occurs,
it is not the same issue type. That allows us to have
much precise reports, and better explain the user
where the issue stands.
