Merge branch 'master' into 0.11

Conflicts:
	ext/ogg/gstoggdemux.c
	ext/pango/gsttextoverlay.c
	gst-libs/gst/audio/gstaudioencoder.c
	gst-libs/gst/audio/gstbaseaudiosrc.c
	gst/playback/gstsubtitleoverlay.c
	gst/videorate/gstvideorate.c

1 files changed, 10 insertions, 30 deletions

diff --git a/docs/design/design-decodebin.txt b/docs/design/design-decodebin.txt
index 6506a4e97..7ca84b6ca 100644
--- a/docs/design/design-decodebin.txt
+++ b/docs/design/design-decodebin.txt
@@ -255,40 +255,20 @@ for baseline profile, and software fallback for main/high profile; or a DSP
 codec only supporting certain resolutions, with a software fallback for
 unusual resolutions). So if decodebin just plugged the most highest-ranking
 decoder, that decoder might not be be able to handle the actual stream later
-on, which would yield in an error (this is a data flow error then which would
+on, which would yield an error (this is a data flow error then which would
 be hard to intercept and avoid in decodebin). In other words, we can't solve
 this issue by plugging a decoder right away with the parser.
 
-So decodebin need to communicate to the parser the set of available decoder
+So decodebin needs to communicate to the parser the set of available decoder
 caps (which would contain the relevant capabilities/restrictions such as
 supported profiles, resolutions, etc.), after the usual "autoplug-*" signal
 filtering/sorting of course.
 
-This could be done in multiple ways, e.g.
-
-  - plug a capsfilter element right after the parser, and construct
-    a set of filter caps from the list of available decoders (one
-    could append at the end just the name(s) of the caps structures
-    from the parser pad template caps to function as an 'ANY other'
-    caps equivalent). This would let the parser negotiate to a
-    supported stream format in the same way as with the static
-    pipeline mentioned above, but of course incur some overhead
-    through the additional capsfilter element.
-
-  - one could add a filter-caps equivalent property to the parsers
-    (and/or GstBaseParse class) (e.g. "prefered-caps" or so).
-
-  - one could add some kind of "fixate-caps" or "fixate-format"
-    signal to such parsers
-
-Alternatively, one could simply make all decoders incorporate parsers, so
-that always all formats are supported. This is problematic for other reasons
-though (e.g. we would not be able to detect the profile in all cases then
-before plugging a decoder, which would make it hard to just play the audio
-part of a stream and not the video if a suitable decoder was missing, for
-example).
-
-Additional considerations: the same problem exists with sinks that support
-non-raw formats. Consider, for example, an audio sink that accepts DTS audio,
-but only the 14-bit variant, not the 16-bit variant (or only native endiannes).
-Ideally dcaparse would convert into the required stream format here.
+This is done by plugging a capsfilter element right after the parser, and
+constructing set of filter caps from the list of available decoders (one
+appends at the end just the name(s) of the caps structures from the parser
+pad template caps to function as an 'ANY other' caps equivalent). This let
+the parser negotiate to a supported stream format in the same way as with
+the static pipeline mentioned above, but of course incur some overhead
+through the additional capsfilter element.
+