gst-plugins-base: decodebin: Update design documentation about how Parser/ Converter are handled

[Sebastian Dröge]

Module: gst-plugins-base
Branch: master
Commit: 2ad501aa518b2358cd6df90f98888f3598123e65
URL:    http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=2ad501aa518b2358cd6df90f98888f3598123e65

Author: Sebastian Dröge <sebastian.droege at collabora.co.uk>
Date:   Thu Sep  8 14:46:23 2011 +0200

decodebin: Update design documentation about how Parser/Converter are handled

---

 docs/design/design-decodebin.txt |   36 ++++++++----------------------------
 1 files changed, 8 insertions(+), 28 deletions(-)

diff --git a/docs/design/design-decodebin.txt b/docs/design/design-decodebin.txt
index 07cd3d4..957014f 100644
--- a/docs/design/design-decodebin.txt
+++ b/docs/design/design-decodebin.txt
@@ -264,31 +264,11 @@ 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.
+