This should allow for more meaningful errors. Dereferencing NULL
is more useful information than dereferencing a random address
happened to be on the stack.
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.
This had been fixed recently by failing queries when the
queue2 was buffering, but this happens to break some other
case (playbin on a local http server and matroska), while
this patch works for both.
See https://bugzilla.gnome.org/show_bug.cgi?id=728345
Keep it simple. Likely also makes things easier for bindings,
and efficiency clearly has not been a consideration given how
the existing code handled these lists.
In order to be deterministic, multiple waiting GstClockIDs needs to be
released at the same time, or else one can get into the situation that
the one being released first can add itself back again before the next
one waiting is released.
Test added for new API and old tests rewritten to comply.
We want to iterate over items idx to idx + length
We use the len variable as the corrected number of memory to iterate
and then properly go over all items.
Fixes the issue where specifying any idx different from 0 had no effect
Spotted by clang static analyzer
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.
