Moved testQuery after testFragmentDownloadError so that testDownloadError
and testFragmentDownloadError are grouped together.
The commit just moved the testQueryCheckDataReceived and
GST_START_TEST (testQuery) functions but git gets confused in matching the
lines and reports a lot of changes in the patch.
https://bugzilla.gnome.org/show_bug.cgi?id=762144
To allow the adaptivedemux live stream tests to run in non-realtime, use a
GstTestClock as the system clock. This allows the unit tests to complete
more quickly than if they had to complete in real time.
https://bugzilla.gnome.org/show_bug.cgi?id=762147
There are several places in adaptivedemux where it waits for
time to pass, for example to wait until it should next download
a fragment. The problem with this approach is that it means that
unit tests are forced to execute in realtime.
This commit replaces the use of g_cond_wait_until() with single
shot GstClockID that signals the condition variable. Under normal
usage, this behaves exactly as before. A unit test can replace the
system clock with a GstTestClock, allowing the test to control the
timing in adaptivedemux.
https://bugzilla.gnome.org/show_bug.cgi?id=762147
A realtime clock is used in many places, such as deciding which
fragment to select at start up and deciding how long to sleep
before a fragment becomes available. For example dashdemux needs
sample the client's estimate of UTC when selecting where to start
in a live DASH stream.
The problem with dashdemux calculating the client's idea of UTC is
that it makes it difficult to create unit tests, because the passage
of time is a factor in the test.
This commit changes dashdemux and adaptivedemux to use the
GstSystemClock, so that a unit test can replace the system clock when
it needs to be able to control the clock.
This commit makes no change to the behaviour under normal usage, as
GstSystemClock is based upon the system time.
https://bugzilla.gnome.org/show_bug.cgi?id=762147
When application change pipeline state NULL->READY and then READY->NULL,
glimagesink will not clear glsink->window_id. After that, when application
change state NULL->READY, the new_window_id is equal to window_id, glimagesink
will not set window handle. It will use the internal window but not the window
create by application.
https://bugzilla.gnome.org/show_bug.cgi?id=765241
Currently, gst_srtp_dec_sink_setcaps is happy if the "roc" field is not
provided in the caps. If it is not provided the stream will be properly
inserted in the hash table with a default "roc". Then, when the first
buffer arrives validate_buffer will find an existing stream in the hash
table and will not signal request-key, not allowing the user to provide
a "roc".
This patch expects "roc" in gst_srtp_dec_sink_setcaps, if not found a
request-key will be signaled and the user will be able to provide all
the srtp fields, including "roc".
https://bugzilla.gnome.org/show_bug.cgi?id=765079
When the sub-class is delaying deactivation of the old program,
but it has the same program number as the new program, don't
overwrite the old program in the hash table and then steal
the new program back out of it. Instead, add the new program to
the hash table after handling removal of the old one.
