From 2ad501aa518b2358cd6df90f98888f3598123e65 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= Date: Thu, 8 Sep 2011 14:46:23 +0200 Subject: decodebin: Update design documentation about how Parser/Converter are handled --- docs/design/design-decodebin.txt | 36 ++++++++---------------------------- 1 file changed, 8 insertions(+), 28 deletions(-) (limited to 'docs/design') 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. + -- cgit v1.2.1 From 76ed3fb04d55839176a7b546d876efbc946f4419 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim-Philipp=20M=C3=BCller?= Date: Fri, 9 Sep 2011 13:10:13 +0100 Subject: docs: fix some typos in the decodebin design document --- docs/design/design-decodebin.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/design') diff --git a/docs/design/design-decodebin.txt b/docs/design/design-decodebin.txt index 957014f21..9d74f7115 100644 --- a/docs/design/design-decodebin.txt +++ b/docs/design/design-decodebin.txt @@ -255,11 +255,11 @@ 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. -- cgit v1.2.1