The latency query originally had a fallthrough to the default
label at the end as fallback, but that got messed up when the
DURATION and POSITION queries were added, so it then fell through
to the duration query handler instead. Restore original behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=699077
Duration query would return TRUE and duration=-1. This
worked in the unit test because the unit test implementation
was a bit broken.
Both queries need to access rate with a lock.
Fix broken duration query test as well. It relied on broken
behaviour by the videorate query handler, and also it was
implemented as a downstream query rather than an upstream
query. And we must return HANDLED from the probe so that the
query we intercept actually returns TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=699077
There was already a check for that, but it failed because
subformat_guid[0] is a guint32 and that is then casted implicitely to a
guint16 when recursing... just that we checked the uncasted value.
This caused an infinite recursion and thus stack overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=777265
When the decodebin state change fails because of an error
message, we might not go through PAUSED->READY. Don't leak
a ref to decodebin pads due to pad blocking in that case.
This is because we return ASYNC going to PAUSED, and if
we fail before reaching PAUSED the only transition we'll
see is READY->NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=775893
This adds some extra options that affect pattern=ball mode, allowing the
animation to be synced to running time or wall-time clock for comparing
sync across different instances / pipelines / machines.
Also added is the ability to invert the rendering colours every second,
and some different ball motion patterns.
https://bugzilla.gnome.org/show_bug.cgi?id=740557
The state of urisourcebin (and all elements contained within) can
change at any point in time, including when setting up the typefind
element.
In order to avoid ending up with typefind starting without being fully
connected, lock the state and connect to the 'have-type' signal.
Sometimes there is a human-oriented timecode that represents an
interval between two other timecodes. It corresponds to the human
perception of "add X hours" or "add X seconds" to a specific timecode,
taking drop-frame oddities into account. This interval-representing
timecode is now a GstVideoTimeCodeInterval. Also added function to add it to
a GstVideoTimeCode.
https://bugzilla.gnome.org/show_bug.cgi?id=776447
Due to the special nature of adaptivedemux, reconfigure happens
frequently with seek/track-change.
In very exceptional cases, the following sequence is possible:
* EOS event is pushed to queue element and still buffers are queued
* During draining remaining buffers, reconfiguration downstream
happens due to track switch.
* The queue gets a not-linked flow return from downstream
* Because the sinkpad is EOS, the queue registers an
error on the bus, causing the pipeline to fail.
Avoid the sinkpad getting marked EOS in the first place, by using a
custom event in place of EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=777009
It is often usefull to make sure that you get a full copy of a profile.
For example you want to let the user modify it in the user interface
but still keep an unchanged version for later use.
API:
gst_encoding_profile_copy
Generating those files is useful for users building the GStreamer stack
using meson and having to link it to another project which is still
using the autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=776810
When shutting down decodebin2 and parsebin, they set their
output pads to flushing, and there is a very small window
where elements might send a sticky event such as a tag event
(which silently fails due to flushing) and then sends a buffer,
and the buffer will return GST_FLOW_ERROR because it can't
forward sticky events. The element will then send an error
message on the bus. This can also happen when elements send EOS
just as shutdown is happening. Since we're about to destroy all
the elements inside parsebin and decodebin anyway, just discard
error messages from them.
A nicer but more difficult fix for GStreamer 2.0 is to make
all event pushing / handling in core return a GstFlowReturn
like buffers do, so we can report a FLUSHING state cleanly.
