Events passing through #GstPads that have a running time
offset set via gst_pad_set_offset() will get their offset
adjusted according to the pad's offset.
If the event contains any information that related to the
running time, this information will need to be updated
before usage with this offset.
This reverts commit b9313afc75.
This should be fixed in upstream libcheck instead. We want
to keep diff of our local copy to upstream libcheck
to a minimum.
This should never happen theoretically, but since a transient
failure would get us to silently read wrong data, it's worth
erroring out. And it silence this:
Coverity 206034
GST_DEBUG_BIN_TO_DOT_FILE() would cause a segfault whenever it encountered an
element's caps that had a field value being NULL. Such fields are successfully
handled e.g. by GST_*_OBJECT(), and with this patch so does
GST_DEBUG_BIN_TO_DOT_FILE(). Even if string fields with a NULL value are
not supposed to be valid in caps, such caps can be created.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727701
The step can end up being zero if the underlying value isn't a valid
range GValue.
In those cases, return FALSE.
We don't use g_return*_if_fail since it will already have been triggered
by the above-mentionned _get_step() functions.
Spotted by Coverity.
We iterate the current discont group backwards and push each GOP forwards,
starting from the last one. However if the first buffer in the current
discont group is a keyframe, we will keep it around until next time,
which is far from ideal. Just push it.
If the toplevel bin is not not a pipeline, we place the bin in a
pipeline. Also make sure that we connect to the deep-notify of this new
pipeline because we will g_signal_handler_disconnect() from it later.
The qlock is released between popping a buffer from the queue
and pushing it. When this buffer causes the sink to wait in
preroll, this lets a query see that the queue is empty, and
push the query then wait for it to be serviced. However, this
will not be done till after peroll, and this will thus block.
If upstream was waiting on buffering to reach 100% before
switching to PLAYING, a deadlock would ensue.
We fix it by refusing the query when buffering, as per Wim's
recommendation on IRC.
Every instance of calling bin_do_message_forward() first took the
object lock, so that bin_do_message_forward() could drop it and
then reclaim. Instead, only take the object lock afterward where
needed.
This prevents situations where a first branch would get seeked and
receive a buffer before all branches got seeked, and thus collected
would get called based on EOS from the previous segment.
As a consequence, during the process of seeking, don't decrease
the eospads number when a FLUSH_STOP is received.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724571
