mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2025-01-23 07:38:16 +00:00
Code Issues 1 Projects Releases Wiki Activity

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

Browse source
This commit is contained in:
Sebastian Dröge 2011-09-08 14:46:23 +02:00
parent 5f5d832a3b
commit 2ad501aa51
1 changed files with 7 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
docs/design/design-decodebin.txt
View file

@ -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.
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.
- 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.