This tests add an idle probe on an idle pad from a separate thread
so that the callback is called immediatelly. This callback will sit
still and then we try to push a buffer on this same pad. It verifies
that the idle probe blocks data passing
https://bugzilla.gnome.org/show_bug.cgi?id=747852
When idle probe runs directly from the gst_pad_add_probe() function
we need to make sure that no data flow happens as idle probe
is a blocking probe. The idle probe will prevent that any
buffer, bufferlist or serialized events and queries are not
flowing while it is running.
https://bugzilla.gnome.org/show_bug.cgi?id=747852
When a bin changes states upwards, and a child fails to change,
any child that was already switched will not be reset to its
original state, leaving its state inconsistent with the bin,
which does not change state due to the failure.
If the state change was from NULL to READY, it means that deleting
this bin will cause those children to be deleted while not in
NULL state, which is a Bad Thing. For other upward changes, it
is less of a problem, as a subsequent switch back to NULL will
cause an actual downwards change on those inconsistent elements,
albeit from the "wrong" state.
We now reset state to the original one when a child fails.
Includes unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=747610
An element that performs decryption does not naturally fit within any
of the existing element factory class types. It is useful to be able
to easily get a list of all elements that support decryption so that
a union can be computed between the protection systems that have a
supported decryptor and the allowed protection systems for a particular
stream.
This commit adds a new GST_ELEMENT_FACTORY_TYPE_DECRYPTOR and its
associated string identifier "Decryptor". It also adds
GST_ELEMENT_FACTORY_TYPE_DECRYPTOR to GST_ELEMENT_FACTORY_TYPE_DECODABLE
so that uridecodebin can auto-plug a decryption element.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
gst_type_find_element_src_event() is supposed to consume @event but wasn't
doing so when it was handling the event itself.
https://bugzilla.gnome.org/show_bug.cgi?id=747775
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Otherwise we're going to set a rather arbitrary DTS of segment.start (usually
0) for live sources, which confuses synchronization if the source started
capturing at a later time. And it's especially wrong for raw media, for which
we should not set any DTS at all.
https://bugzilla.gnome.org/show_bug.cgi?id=747731
There is no reason I can see to set mq->buffering = TRUE when
use_buffering is set; the code here also calls update_buffering(), which
will set mq->buffering = TRUE if this is warranted because of low buffer
levels.
https://bugzilla.gnome.org/show_bug.cgi?id=745937
gst_selector_pad_chain() was popping cached buffers out of the queue without
freeing those. Make sure we don't steal the GstBuffer as the cached buffer ref
has been passed to the pad chain function.
This can be reproduced by running the
validate.file.playback.switch_subtitle_track_while_paused.test5_mkv scenario
with Valgrind.
https://bugzilla.gnome.org/show_bug.cgi?id=747611
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
It could be triggered by:
gst-launch-1.0 videotestsrc num-buffers=20 ! videcrop bottom=214748364 ! videoconvert ! autovideosink
Spotted while testing:
https://bugzilla.gnome.org/show_bug.cgi?id=743910
1) segment.accum -> segment.base
2) Refer to GstSegment members as S.foo instead of
NS.foo, the event is now called a segment event
rather than newsegment event.
3) There's no more abs_rate field in GstSegment,
and there never was an abs_applied_rate field.
https://bugzilla.gnome.org/show_bug.cgi?id=690564
Use case: we want to block the source pad of a leaky queue and
drop the buffer that causes the block. If we return PROBE_DROP
then the buffer gets dropped, but we get called again. If we
return PROBE_OK we can't easily drop the buffer. If we just
replace the item into the GstPadProbeInfo structure with NULL,
GStreamer will push a NULL buffer to the next element when we
unblock the pad probe. This patch ensures it doesn't do that.
https://bugzilla.gnome.org/show_bug.cgi?id=734342
Also skip gst_pipeline_get_clock() and gst_pipeline_set_clock() from the
bindings as they are confused with gst_element_*_clock().
API: gst_pipeline_get_pipeline_clock()
https://bugzilla.gnome.org/show_bug.cgi?id=744442
Update test_seeking testcase to verify the render and render_list
virtual method handle buffers and buffer list containing multiple
memory blocks correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=747223
