When message_async is not called during error cases, needs_parsing GList is
not being freed resulting in leak. Hence free'ing the same in finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=753339
There is no check to see if stream info is available. This leads to
assertion error. Adding proper error messages for the same and reported
the same as a validate warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=752758
When discovering the files, there will be different kind of errors. If we print
the exact message, then it will be more helpful for user. Especially in the case
of missing plugins, displaying which plugin is missing as error message
https://bugzilla.gnome.org/show_bug.cgi?id=752758
file:// base stream-id will vary depending on the file path. As we
don't expect everyone to use the same absolute path to place the
validate testsuite, the resulting stream-id changes. Because of that,
we can't match the stream-id in the recorded file, hence cannot do
further check. We work around this by doing what filesink would do,
which is compute a SHA256 of the URI which we can use to first
validate the ID is prefixed like expected, and decide if we should
consider the stream IDs the same or not.
https://bugzilla.gnome.org/show_bug.cgi?id=753079
while comparing the media descriptor with --expected-results, the return
values are not being handled properly, which results in wrong comparision
https://bugzilla.gnome.org/show_bug.cgi?id=748390
As stated in the bug, this comparison failing is not a critical
error, warning is enough. Add a comment so nobody thinks it's a
coding error.
https://bugzilla.gnome.org/review?bug=748390
when comparing tags, two conditions in if an else if are same
the correct way is to first check if both are NULL and return.
changed the condition accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=748390
Since _set_done() is meant to be thread safe,
it can not be used with g_object_add_weak_pointer(),
instead, one must use GWeakRef. But since it is in the API,
document that fact and add a couple assertions to make sure
it doesn't get broken in the future.
In case of files, which don't have duration in header, baseparse
estimates the duration only after 1.5 seconds. But Async_done event
is sent before the duration is estimated, which results in error.
If duration query fails, getting the duration from the media-info being
passed through --set-media-info. If media-info is also not set,
printing an error message and throwing error.
https://bugzilla.gnome.org/show_bug.cgi?id=752521
Summary:
When running valgrind we'll have 2 scenarios loaded (the normal one and
"setup_sink_props_max_lateness.scenario"). The loading code shouldn't assume
which one will contain the description it actually care about and so just look
for the fields it actually needs.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D199
Allowing users to decide the time between which the action should be
executed. In some cases executing on idle might lead to action not
being executed fast enough so the user might want to force an interval
in that case.
Summary:
Properly handling the different types that can represent ClockTime
Make use of it in gst_validate_action_get_clocktime
API: gst_validate_utils_get_clocktime
Depends on D209
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D210
Summary:
+ Fix a minor mixup bug between klass_overrides and name_overrides
Depends on D205
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D206
Summary:
This way we can subclass them getting a proper
context in the various override methods.
Depends on D204
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D205
Summary:
Otherwise we end up with circular / complicated dependencies between
Validate, its libraries, and the plugins
Depends on D203
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D204
Otherwise we end up with rounding error and instead of
seeking to 0.1 we seek to 0.09999999999 for example
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D203
This method is similar to runner_printf() but can be used
only once. The user needs to make sure all the pipeline
are in NULL state when this is called.
The method emits a "STOPPING" signal and at that point
overrides or monitors should do extra processing/checks if
needed.
+ Make use of it everywhere where it makes sense.
API:
gst_validate_runner_exit
GstValidateRunner::stopping signal
Summary:
Before returning GST_FLOW_ERROR, an element must post an ERROR GstMessage,
enforce that.
Reviewers: thiblahute, Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D201
Using sqrt of -1 is not valid and leads to undefined results.
When comparing the return value of the fucntion in validate-scenario,
it is being checked with ret == -1, so it makes sense to just return -1 in error case.
https://bugzilla.gnome.org/show_bug.cgi?id=748389
Summary:
It is possible to keep executing actions after the pipeline
has been destroyed.
API:
GST_VALIDATE_ACTION_TYPE_DOESNT_NEED_PIPELINE
Depends on D171
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D172
Summary:
Making simpler to follow the execute_next_action function.
Depends on D169
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D170
Summary:
If from anything >= PAUSED to anything <= READY we can not query
pipeline position, so do not try to.
Depends on D168
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D169
Summary:
Currently the only supported action is gtk-put-event allowing press and
release keyboard keys.
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D117
Summary:
Useful to know if we are executing the 'stop' command provided by the scenario
or not.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D155
Summary: Fix invalid read when executing without having the actual position.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D147
Summary:
This allows us to set a property on all the elements of the pipeline matching
a specific klass name.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D140
Summary:
We want to have a chance to set property on all the elements of the pipelines,
including the existing children when the element is added.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D138
And document it properly.
Summary:
The stop action was defined as "setting state to NULL" but
its actual goal is to stop the execution of the scenario. Make sure
that the scenario will not try to execute other actions when that
one has been executed.
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D103
Summary:
+ typedef GstValidateActionReturn so it can be used in the introspection
+ Add GST_VALIDATE_EXECUTE_ACTION_ERROR_REPORTED which should be used
to tell Validate that something wrong happened so the sub action
won't be executed, but that it should not report an error itself
as it has already been handled in the action function.
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D81
Summary:
And fix a bug where config actions were added to the list of action even
if they had already been executed
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D80
Summary:
Add a very simple plugin that will allow any GApplication to easily be
used with GstValidate using the LD_PRELOAD feature
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D75
Summary: And print the current repeat value of the action that have such a field
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D73
Summary:
@report was invalid when we were trying to clear the mutex.
validate: scenario: remove weak pointer when destroying action
Free an invalid read when the scenario is destroyed after the action.
Differential Revision: http://phabricator.freedesktop.org/D44
When linking actions execution without waiting on execution context, then
idle callback should keep being called so following action keep being
executed.
Summary:
There is currently no way to handle the fact that action types
might be handled only by a specific application but not handling
this action types would not cause any difference for the good execution
of the scenario as a whole
Differential Revision: http://phabricator.freedesktop.org/D33
Fixing annotations and make GstValidateIssue refcounted
We break the ABI in that commit but I do not expect anyone to register
issue type outside GstValidate yet.
Add padding in the structures so we can avoid breaking the ABI again later.
Avoiding user to have to print them in each and every action type
implementation.
This requires adding some API to prepare actions before printing them.
Preparing action in that case mean parsing the values contained in the
GstStructure parsing equations and setting back the actual value
afterward
API:
* GstValidatePrepateAction
* gst_validate_action_type_set_prepare_function
Summary:
- Add a way to force action to be executed in their own GSource dispatch, disabling chain action execution
API:
GstValidateScenario::execute-on-idle property
This reverts commit b976319ef7f977b8ce910c4b8aa1a843da3b264f.
Now that the exact same structure can be used to represent different
action types, we can not rely on the structure size to stuff
informations into the action. Users should just make use of
GstMiniObject.qdata.
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.
By default an action has no playback-time, this makes it actionable
immediatly.
When no playback-time is set on a set-property action, it will
be activated the moment the element is added in the pipeline.
gst-validate-reporter.c:119:39: error: implicit conversion from enumeration type
'GstValidateReportingDetails' to different enumeration type
'GstValidateInterceptionReturn' [-Werror,-Wenum-conversion]
GstValidateInterceptionReturn ret = GST_VALIDATE_SHOW_UNKNOWN;
~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~
gst-validate-reporter.c:124:11: error: implicit conversion from enumeration type
'GstValidateReportingDetails' to different enumeration type
'GstValidateInterceptionReturn' [-Werror,-Wenum-conversion]
ret = iface->get_reporting_level (reporter);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gst-validate-reporter.c:127:10: error: implicit conversion from enumeration type
'GstValidateInterceptionReturn' to different enumeration type
'GstValidateReportingDetails' [-Werror,-Wenum-conversion]
return ret;
~~~~~~ ^~~
In the pipeline, an EOS should always have the same seqnum of the
previous SEGMENT event that was received. If the segment is the result
of a seek, it should always be the same as the seek seqnum too.
+ (Mathieu Duponchelle): fix reporting and concatenation tests.
