mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-06-08 17:19:25 +00:00
43cbc42c45
Original commit message from CVS: the 'brown paper bag' commit. sorry for the email spam on this one, but it will be laaaarrrggggeee
109 lines
2.8 KiB
Plaintext
109 lines
2.8 KiB
Plaintext
<!-- ##### SECTION Title ##### -->
|
|
GstType
|
|
|
|
<!-- ##### SECTION Short_Description ##### -->
|
|
Identifies the data
|
|
|
|
<!-- ##### SECTION Long_Description ##### -->
|
|
<para>
|
|
GstTypes exist to try to make sure data eveyrone is talking about the
|
|
right kind of data. They aid quite a bit in autoplugging, in fact make it
|
|
possible. Each well-formed type includes a function (typefind) that will
|
|
take one or more buffers and determine whether or not it is indeed a
|
|
stream of that type, and possible a metadata to go with it. It may
|
|
provide related metadata structure IDs (and must if it provides metadata
|
|
from the typefind function).
|
|
</para>
|
|
|
|
<para>
|
|
Because multiple elements and plugins are very likely to be using the same
|
|
types, the process of creating/finding types is designed to be done with a
|
|
single function call. All operations on GstTypes occur via their guint16
|
|
ID numbers, with the GstType structure "private" to the GST library. A
|
|
plugin wishing to use a give type would contain a static struct of type
|
|
GstTypeFactory, which lists the MIME type, possible extensions (which may
|
|
overlap the mime-types file), a typefind function, and any other cruft I
|
|
decide to add.
|
|
</para>
|
|
|
|
<para>
|
|
A plugin init function would take this typefactory and hand it to the
|
|
gst_type_new() (FIXME: badly named) function, which would first search for
|
|
that same MIME type in the current list. If it found one, it would
|
|
compare the two to see if the new one is "better". Better is defined as
|
|
having more extentions (to be merged) or a typefind function verses none.
|
|
</para>
|
|
|
|
<para>
|
|
The point of returning an existing MIME type is a result of the goal of
|
|
unifying types enough to guarantee that, for instance, all MP3 decoders
|
|
will work interchangably. If MP3 decoder A says "MIME type 'audio/mpeg'
|
|
with extensions 'mpeg3'" and decoder B says "MIME type 'audio/mpeg' with
|
|
extensions 'mp3'", we don't want to have two types defined, possibly with
|
|
two typefind functions. If we did, it's not obvious which of the two would
|
|
be tried first (luck) and if both would really identify streams as mp3
|
|
correctly in all cases. And whichever wins, we're stuck using the
|
|
associated decoder to play that stream. We lose the choice between any
|
|
valid mp3 decoder, and thus the whole point of the type system.
|
|
</para>
|
|
|
|
<!-- ##### SECTION See_Also ##### -->
|
|
<para>
|
|
#GstTypeFactory
|
|
</para>
|
|
|
|
<!-- ##### STRUCT GstType ##### -->
|
|
<para>
|
|
A type.
|
|
</para>
|
|
|
|
@id:
|
|
@mime:
|
|
@exts:
|
|
@factories:
|
|
|
|
<!-- ##### FUNCTION gst_type_register ##### -->
|
|
<para>
|
|
|
|
</para>
|
|
|
|
@factory:
|
|
@Returns:
|
|
|
|
|
|
<!-- ##### FUNCTION gst_type_find_by_mime ##### -->
|
|
<para>
|
|
|
|
</para>
|
|
|
|
@mime:
|
|
@Returns:
|
|
|
|
|
|
<!-- ##### FUNCTION gst_type_find_by_ext ##### -->
|
|
<para>
|
|
|
|
</para>
|
|
|
|
@ext:
|
|
@Returns:
|
|
|
|
|
|
<!-- ##### FUNCTION gst_type_find_by_id ##### -->
|
|
<para>
|
|
|
|
</para>
|
|
|
|
@id:
|
|
@Returns:
|
|
|
|
|
|
<!-- ##### FUNCTION gst_type_get_list ##### -->
|
|
<para>
|
|
|
|
</para>
|
|
|
|
@Returns:
|
|
|
|
|