GitLab

We will be changing states, set the handles-state variable accordingly

We might be working with something that is not a path

As soon as the track is changed, the pipeline state is set to NULL
by execution 'stop' action even if there is a 'playback-time' with 5sec.
If the AV sink is not synchronized,
audio fakesink and video fakesink has different position value.
When the validate request the position information of pipeline
to do 'stop' action, the audio fakesink response of the position query
with the bigger value than 5sec.

https://bugzilla.gnome.org/show_bug.cgi?id=755101

This way testsuite implementation can have the information

If the scenario handles the states and wants to stay in PAUSED, it's not a
good idea to change the state to PLAYING when receiving BUFFERING=100%. This
caused a race condition in varios seeking tests, most often in the dash scrub
seeking test.

If the scenario handles the states and wants to stay in PAUSED, it's not a
good idea to change the state to PLAYING when receiving BUFFERING=100%. This
caused a race condition in varios seeking tests, most often in the dash scrub
seeking test.

Fixed now

It apparently succeeds now.

And make sure to create a new dict for extra_env_vars when instanciating
GstValidateTest

It is used there but was set in each and every subclasses

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

mutex is being initialized but not cleared.

https://bugzilla.gnome.org/show_bug.cgi?id=752754

when checking the restriction caps, not adding proper check, which
results in assertion error when calling gst_caps_from_string

https://bugzilla.gnome.org/show_bug.cgi?id=752749

Fix some trivial spelling mistakes in documentation
and document about --update-media-info.

https://bugzilla.gnome.org/show_bug.cgi?id=752748

When media file name consists of some special characters of the format
[b-a].mp3, then it fails with 'bad character range' error and exits.
call re.escape to escape the characters before using it in findall

https://bugzilla.gnome.org/show_bug.cgi?id=752650

When --medias-paths option is being used, right now we have to
specify the full path, like /home/user/gst/master/media/
But when inside master directory, would like to specify only
media/ and expect it to work. Using os.path.abspath and create uri based on that.
This way we can either just pass media/ or pass the full path as parameters.

https://bugzilla.gnome.org/show_bug.cgi?id=752518

in validate.py, some mixer test generators are being added by default.
When passing --media-paths, i would not want to test these.
So instead of setting up the validate test suite, just call tester.register_defaults().

https://bugzilla.gnome.org/show_bug.cgi?id=752518

Right now reverse playback happens till the beginning of the media file.
But for files which are longer than 150 seconds,
Timeout 'Hard timeout reached: 150 secs' error happens. So we should set the
start time within 150 seconds.

https://bugzilla.gnome.org/show_bug.cgi?id=753216

Which should put the testsuite in a clean state (basically using git
reset --hard for git based testsuite for example)

This is now supported and works as expected.

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

Casting the result of g_strmp0 to boolean won't make gboolean
value 0 or 1. We need proper 0 and 1 so we can use == comparision.

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

replace comparse_stream with compare_streams

https://bugzilla.gnome.org/show_bug.cgi?id=748390

When file name consists of characters from other languages, say korean,
then it throws an error
Error initializing: Invalid byte sequence in conversion input

Hence setting locale to all to fix this.
And changing the media-info argument to type G_OPTION_ARG_FILENAME

https://bugzilla.gnome.org/show_bug.cgi?id=752945

API:
  gst_validate_action_get_scenario

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.