Since caps are no longer 'shared' between two pads (but forwarded from
source pad to sink pad) we end up with the first chain pad not having
specified caps (i.e. typefind:src).
This solves the issues by getting the pad's peer caps.
It is not optimal since it will (for most demuxers) return the pad
template caps, which might contain non-fixed caps (ex : with
qtdemux "video/quicktime; video/mj2; audio/x-m4a; application/x-3gp")
https://bugzilla.gnome.org/show_bug.cgi?id=667337
... to also properly indicate chain's endpad if no elements are in the
chain (due to the endpad being a raw demuxer pad, or one setup without
decoders since uridecodebin or higher up decided not to need those).
Previously we always used textoverlay for rendering the output of
a parser, now the same code as for the renderers is used and the
element with the highest rank is used.
Fixes bug #663822.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Replace g_thread_create() with g_thread_try_new().
Make appsink return a GstSample. Remove the pull_buffer_list method because it
is not very useful anymore.
Pass GstSample to the conversion function.
Update playbin2 and examples
This happens when the internal elements are added before any NEWSEGMENT
event arrived and in that case we shouldn't send a NEWSEGMENT event
to the internal elements at all. They will get the NEWSEGMENT event
from upstream later.
If the sink supports raw audio/video, we first check
if the decoder could output any raw audio/video format
and assume it is compatible with the sink then. We don't
do a complete compatibility check here if converters
are plugged between the decoder and the sink because
the converters will convert between raw formats and
even if the decoder format is not supported by the decoder
a converter will convert it.
We assume here that the converters can convert between
any raw format.
Fixes bug #665120.
After preroll the multiqueue limits are still set to the preroll
limits if use-buffering is set to TRUE. In that case we only want
time limits on the multiqueue if upstream is seekable.
Such streams were detected as seekable, as the query on the typefind
element was testing the m3u8 file listing the actual streams, and
not going through the demuxer(s).
We now check for seekability for each multiqueue following a demuxer,
so the query will flow through the elements which might prevent seeking.
https://bugzilla.gnome.org/show_bug.cgi?id=647769
The ghostpad acceptcaps functions are not valid in this case because
we don't only accept the caps accepted by the target but could also
insert converters. Fixes bug #663892.