And make use of it in the typefind element. It's useful to distinguish
between the different errors why typefinding can fail, and especially to
not consider GST_FLOW_FLUSHING as an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=796894
And make use of that in the typefind element to also be able to make use
of the extension in push mode. It previously only did that in pull mode
and this potentially speeds up typefinding and might also prevent false
positives.
https://bugzilla.gnome.org/show_bug.cgi?id=796865
Before emitting have-type, switch to NORMAL
mode, as part of the have-type processing sends
the caps event downstream, which might trigger
actions like downstream autoplugging or
flushing seeks - and the latter are only
passed upstream if we've set typefind to NORMAL
mode.
When subtracting queued data sizes from upstream queries
in queue, queue2, downloadbuffer and typefind, clamp the
result to not go negative, in case upstream returned
a nonsense value that's too small (as could happen if
upstream is estimating, or just broken)
The other signal handlers of the type-found signal might have reactivated
typefind in PULL mode already, pushing a CAPS event at that point would cause
deadlocks and is in general unexpected by elements that are in PULL mode.
https://bugzilla.gnome.org/show_bug.cgi?id=765906
If an application calls gst_pad_query_caps from its "have-type" signal handler,
then the query fails because typefind->caps has not been set yet.
This patch sets typefind->caps in the object method handler, before the signal
handlers are called.
https://bugzilla.gnome.org/show_bug.cgi?id=763491
This reverts commit 0835c3d656.
It causes deadlocks in decodebin, which currently would deadlock if the caps
are already on the pad in have-type and are forwarded while copying the sticky
events (while holding the decodebin lock)... as that might cause the next
element to expose pads, which then calls back into decodebin and takes the
decodebin lock.
This needs some more thoughts.
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>
We use the segment format to detect if we run the streaming thread or not.
Without resetting we might believe we do so, although we only did in the past
and are now running in e.g. push mode.
https://bugzilla.gnome.org/show_bug.cgi?id=745073
The initial buffers (that were used for timestamping) might have PTS
and DTS set. In order to forward those properly, get the initial
PTS/DTS from the adapter and set them on the reconstructed output
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=733291
There's no point in storing them and sending them later, and doing so would
later require to distinguish between events that should come before caps and
after.
https://bugzilla.gnome.org/show_bug.cgi?id=692784
