If we were in PAUSED, the current clock time and base time don't have much to
do with the running time anymore as the clock might have advanced while we
were PAUSED. The system clock does that for example, audio clocks often don't.
Updating the start time in PAUSED will cause a) the wrong position to be
reported, b) step events to step not just the requested amount but the amount
of time we spent in PAUSED. The start time should only ever be updated when
going from PLAYING to PAUSED to remember the current running time (to be able
to compensate later when going to PLAYING for the clock time advancing while
PAUSED), not when we are already in PAUSED.
Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com>
The updating of the start time when the state is lost was added in commit
ba943a82c0 to fix the position reporting when
the state is lost. This still works correctly after this change.
https://bugzilla.gnome.org/show_bug.cgi?id=739289
The subclass should do that already, but just in case do it ourselves too as a
fallback. Without this, e.g. playbin will just wait forever if this fails
because it is triggered as part of an ASYNC state change.
Otherwise PTS and DTS will come out of sync if upstream continues to provide
PTS and not DTS, and we have to skip some data from the stream or PTS are not
exactly increasing with the duration of each packet.
https://bugzilla.gnome.org/show_bug.cgi?id=765260
If we don't store the value in prev_dts, we would over and over again
initialize the DTS from the last known upstream PTS. If upstream only provides
PTS every now and then, then this causes DTS to be rather static.
For example in adaptive streaming scenarios this means that all buffers in a
fragment will have exactly the same DTS while the PTS is properly updated. As
our queues are now preferring to do buffer fill level calculations on DTS,
this is causing huge problems there.
See https://bugzilla.gnome.org/show_bug.cgi?id=691481#c27 where this part of
the code was introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=765096
POSIX standards requires strsignal() to return a pointer to a char,
not a const pointer to a char. [1] On uClibc, and possibly other
libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares
const char *strsignal (int sig) which causes a type error.
[1] man 3 strsignal
https://bugzilla.gnome.org/show_bug.cgi?id=763567
Many parsers are storing tags only in pre_push_frame(), if we wouldn't check
afterwards we would push buffers before those tags and a lot of code assumes that
tags are available before preroll.
https://bugzilla.gnome.org/show_bug.cgi?id=763553
Similar to the stress test functions for buffers that has a callback to
create the buffer to be pushed, it's useful to have functions that use a
callback to create the event to be pushed.
API: gst_harness_stress_push_event_with_cb_start()
API: gst_harness_stress_push_event_with_cb_start_full()
API: gst_harness_stress_send_upstream_event_with_cb_start()
API: gst_harness_stress_push_upstream_event_with_cb_start_full()
https://bugzilla.gnome.org/show_bug.cgi?id=761932
Depending on when gst_harness_pull was called - before the buffer reached
gst_harness_chain or after we can get different behaviors of the test
with enabled blocking push mode. The fix makes the behavior always the
same. In pull function we get the buffer first, thus making sure
gst_harness_chain waits for the signal, and emitting the signal after.
https://bugzilla.gnome.org/show_bug.cgi?id=761931
Set the sink_forward_pad to NULL before tearing down sink_harness to
avoid that the harness tries to forward events/queries to it while it's
tearing down.
https://bugzilla.gnome.org/show_bug.cgi?id=761904
We have no guarantees about what flags are set on buffers we take
out of the GstAdapter. If we push out multiple buffers from the
first input buffer (which will have discont set), only the first
buffer we push out should be flagged as discont, not all of the
buffers produced from that first initial input buffer.
Fixes issue where the first few mp3 frames/seconds of data in push
mode were skipped or garbled in some cases, and the discont flags
would also trip up decoders which were getting drained/flushed for
every buffer. This was a regression introduced in 1.6 apparently.
Does not matter here but makes Coverity more happy. It can't
know that g_list_remove() only looks at the pointer value but
does not dereference it.
CID 1348454
Currently, the query values are being set even if the query itself was
determined to have failed. Fix this to ensure the values are only set in
case of a query success.
https://bugzilla.gnome.org/show_bug.cgi?id=760479
There's not much lost by having the clock idle around a bit longer but it will
potentially allow anybody wanting to use the same clock server again to sync
much faster.
If multiple net/NTP clocks are created for the same server, reuse the same
internal clock for all of them. This makes sure that we don't flood the server
with too many requests and also possibly allows faster synchronization if
there already was an earlier synchronized clock when creating a new one.
Watching videos with variant bitrate is common to have delta
more than 10 kbps, resulting in tag list spam.
Instead of relying on fixed 10 kpbs delta, it is better to
calculale the difference in percentage and update tag list
only when bitrate changes more than 2%.
https://bugzilla.gnome.org/show_bug.cgi?id=759055
My previous fix for #758029 wasn't quite right and simply made the race rarer.
Some of the files are installed by install-exec and others by install-exec, so
the hooks need to be split too.
https://bugzilla.gnome.org/show_bug.cgi?id=758029
