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.
In the media descriptor files, we now have the md5sum of the actual
content of encoded buffers so that we can check that the buffer content is
perfectly what is was supposed to be.
+ Fix the check of whether a frame is a keyframe in the string
comparison (g_ascii_strcasecmp return 0 if string matches)
https://bugzilla.gnome.org/show_bug.cgi?id=736138
Yeah that was tough. Helpful already though, for example:
GST_VALIDATE_REPORT_LEVEL=none,x:all gst-validate src name=x ! sink
will only report issues reported by the source.
+ Add test.
That's some pretty specific code but it should be helpful.
The following syntax can be used : element-name::pad-name.
+ Free return of gst_object_get_name.
+ Defines reporting levels and document them.
+ Add API to get the default level.
+ fix indentation.
+ fix some typos.
+ Add the beginning of a reporting test.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735665
The process is to check for a similar report in intercept_report on
the pads of the upstream element, set that report as the master report
of the intercepted report, and return REPORTER_KEEP instead
of REPORTER_REPORT.
A master report is a report that has been detected by a monitor
to stem from the same issue. It thus contains a list of
"shadow reports" which it will browse when printing itself.
The _register naming corresponds much better to what the method does
and makes it more similar to how we refer to this kind of action in
GStreamer.
It is a last minute API change, but that API should not change anymore
after 1.4 is released.
Currently implemented tests are:
* Settup and cleanup on monitor is done properly
* Some tests in the PadMonitor are done properly, namely:
- Buffer before segment
- Buffer outside segment
- First buffer running time is always 0
- The Demuxer flow aggregation is properly checked
https://bugzilla.gnome.org/show_bug.cgi?id=736379
Instead just include required (public and local) header
gst-validate-scenario.h:43:44: error: redefinition of typedef 'GstValidateActionParameter' is a C11 feature [-Werror,-Wtypedef-redefinition]
WHen seeking in paused the position right after should be pretty much
the exact one, but sometimes it can be a little different because of
rounding issues and similare.
When checking that all action were executed, we need to make sure that
actions such as EOS or stop are not taken into account as we might have
shorter medias than the duration of the scenario, and that should not be
fatal.
+ Plug a leak on the way
emit-signal action allows to emit signals to elements in scenarios.
The implementation only accepts signals without arguments for now but
it can be extended to use parameters if needed in the future
Get the GValue directly from the structure and do not assume everything
is stored as a string and use the GstStructure's GValue to set the property
to the instances
Allows setting element's properties during a scenario. Very useful
for testing that elements behave correctly when changing properties
during playing state
https://bugzilla.gnome.org/show_bug.cgi?id=733070
Position/duration query may fail, or yield unknown values (eg,
unknown duration for live streams). In these cases, we must ensure
we do not use those invalid values.
https://bugzilla.gnome.org/show_bug.cgi?id=715160
If the initial buffer is before segment.start, we don't want to raise
the "first buffer doesn't have 0 running-time" issue.
Also add debug for tracking issues
gst-validate-utils.c:413:7: error: variable 'v0' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (c == '!') {
^~~~~~~~
gst-validate-utils.c:424:10: note: uninitialized use occurs here
return v0;
^~
gst-validate-utils.c:413:3: note: remove the 'if' if its condition is always false
if (c == '!') {
^~~~~~~~~~~~~~~
gst-validate-utils.c:411:13: note: initialize the variable 'v0' to silence this warning
gdouble v0;
^
= 0.0
1
This property enables the user to have actions executed independently
of the state of the pipeline.
Conflicts:
validate/gst/validate/gst-validate-scenario.c
