After a seek we need to wait for the right segment (meaning the segment
with seqnum == last seek/flush stop seqnum) to check whether the segment.time
has been properly set.
In the case and element is in READY or is going to READY state, it can
always return GST_FLOW_FLUSHING.
Avoid a race where a demuxer sinkpad has not been set to FLUSHING when we are
still processing a buffer but downstream is already FLUSHING and thus
the demuxer is already returning FLUSHING.
MAX(0, ((gint64) priv->segment_start - priv->seek_pos_tol) will be a high
positive number thanks to being interpreted as unsigned values if
segment_start < seek_pos_tol. Fix this by explicitly checking for this case
and only doing the subtraction otherwise.
This fixes the problem from fdccffbb2e
completely now.
https://bugzilla.gnome.org/show_bug.cgi?id=763602
This way we do not need the LD_PRELOAD hack anymore
Add a new libgstvalidateplugin GStreamer plugin, making sure it shares
the exact same code as the library (exposing only the wanted symbols).
Fix the way we set where to install GstValidate plugins
Try to keep backward compatibility even if tracers should never be instantiated
after an GstElement has been instantiated.
Differential Revision: https://phabricator.freedesktop.org/D459
This ensures our sink pad event wrapper is properly called if the
element implement a GstPadEventFullFunc instead of a regular one.
Removes all stray "buffer received before segment" issues with
queue/multiqueue
PTS and DTS can be deceiving as a change in segment can dramatically change
playback synchronization. Track the running-time as well to properly
get any change in synchronization
Having a default value of 0 meant that a g_idle_add loop was constantly
running, causing each test to use 100% cpu.
This is no longer required. Using a 10ms interval brings down cpu usage
to a sane value
When a file does not contain any stream info, then there is no need
to create the media info file as, it is not considered to be a valid file
and no validate checks are done for the same.
This skips unnecessary files like .txt, .dump files
https://bugzilla.gnome.org/show_bug.cgi?id=754006
The user might have scenarios specific to a particular pipeline, and the
application might have several pipelines running and scenarios that
apply on specific pipeline. We have to handle that valid use case.
Summary:
Move variable declarations in the for block so we won't try re-free
tldir in case of early short circuiting of the 'for' code.
Depends on D348
Reviewers: thiblahute
Reviewed By: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D349
Summary:
We were checking if the path was a full one but was using the
scenario_name instead of this path when trying to load the scenario.
Depends on D346
Reviewers: thiblahute
Reviewed By: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D348
writer_new_discover() API should be able to accept NULL GError and in case of
error, if GError is passed on as parameter, it should be propagated, else it
should be free'd.
https://bugzilla.gnome.org/show_bug.cgi?id=753340
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.
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
