... in the extent that a non-waiting pad (so indicated by newsegment)
turns out to provide the best buffer, which is then forced to waiting
for book-keeping purposes, but that should only be temporary.
See bug #415754.
This handles muxing of sparse/subtitle streams and has
lots of cleanup. Still missing is special support for
live streams but this can be added later without breaking
API/ABI.
Based on the version from the videomixer plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=415754
This will make sure we spawn a new plugin scanner helper for each plugin
to be introspected, which helps with making sure we don't load too many
shared objects (libs, plugins) at the same time on systems where there
is a hard limit like on Android.
A better version might re-use the scanner for up to N times, though
it's not clear whether that would actually improve things dramatically.
https://bugzilla.gnome.org/show_bug.cgi?id=662091
The second caps ownership is transfered, no need to require it to
be writable from the caller function. Instead, _append and _merge
make it writable on their own.
Discovered because of an assertion on encoding-profile.c in
_get_input_caps using _merge but not passing writable caps.
Speeds up negotiation a fair bit on a contrived pipeline
with a dozen colorspace conversions.
Hopefully clears out the cache every time it ought to.
https://bugzilla.gnome.org/show_bug.cgi?id=662291
API: GstBaseParseClass::detect()
This is called with the first buffers until the subclass has finished detection
and only afterwards the original buffers are handled as before. The vfunc allows
detection of the stream format without breaking the upstream framing.
Returning a newly allocated string makes no sense. It's unexpected for a
getter, and also this behaves differently in 0.10, so it would make future
merges harder.
Except for these two places here in core which were updated for the new
semantic, the return value is getting leaked all over the place.
