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

1 files changed, 8 insertions, 28 deletions

diff --git a/docs/design/design-decodebin.txt b/docs/design/design-decodebin.txt
index 07cd3d4ac..957014f21 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.
+