mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-04-10 10:04:23 +00:00
docs/design/draft-klass.txt: Proposal for klass field values.
Original commit message from CVS: * docs/design/draft-klass.txt: Proposal for klass field values. * docs/design/part-streams.txt: Start of a doc describing stream anatomy.
This commit is contained in:
Wim Taymans
parent
a19398105c
commit
fe37c5aad2
3 changed files with 195 additions and 0 deletions
|
|
@ -1,3 +1,11 @@
|
|||
2006-02-28 Wim Taymans <wim@fluendo.com>
|
||||
|
||||
* docs/design/draft-klass.txt:
|
||||
Proposal for klass field values.
|
||||
|
||||
* docs/design/part-streams.txt:
|
||||
Start of a doc describing stream anatomy.
|
||||
|
||||
2006-02-28 Wim Taymans <wim@fluendo.com>
|
||||
|
||||
* gst/gstbin.c: (gst_bin_get_type), (gst_bin_handle_message_func):
|
||||
|
|
|
|||
140
docs/design/draft-klass.txt
Normal file
140
docs/design/draft-klass.txt
Normal file
|
|
@ -0,0 +1,140 @@
|
|||
Element Klass definition
|
||||
------------------------
|
||||
|
||||
Status:
|
||||
|
||||
DRAFT.
|
||||
|
||||
|
||||
Purpose:
|
||||
|
||||
Applications should be able to retrieve elements from the registry of existing
|
||||
elements based on specific capabilities or features of the element.
|
||||
|
||||
A playback application might want to retrieve all the elements that can be
|
||||
used for visualisation, for example, or a video editor might want to select all
|
||||
video effect filters.
|
||||
|
||||
The topic of defining the klass of elements should be based on use cases.
|
||||
|
||||
|
||||
Proposal:
|
||||
|
||||
The GstElementDetails contains a field named klass that is a pointer to a
|
||||
string describing the element type.
|
||||
|
||||
In this document we describe the format and contents of the string. Elements
|
||||
should adhere to this specification although that is not enforced to allow
|
||||
for wild (application specific) customisation.
|
||||
|
||||
1) string format
|
||||
|
||||
<keyword>['/'<keyword]*
|
||||
|
||||
The string consists of an unordered list of keywords separated with a '/'
|
||||
character. While the / suggests a hierarchy, this is not the case.
|
||||
|
||||
2) keyword categories
|
||||
|
||||
- functional
|
||||
|
||||
Categories are base on _intended usage_ of the element. Some elements
|
||||
might have other sideeffects (especially for filers/effects). The purpose
|
||||
is to list enough keywords so that applications can do meaningfull filtering,
|
||||
not to completely describe the functionality, that is expressed in caps etc..
|
||||
|
||||
* Source : produces data
|
||||
* Sink : consumes data
|
||||
* Filter : transforms data, no modification on the data is
|
||||
intended (although it might be unavoidable)
|
||||
* Effect : applies an effect to some data, changes to data is
|
||||
intended.
|
||||
* Demuxer : splits audio, video, ... from a stream
|
||||
* Muxer : combines audio, video, ... into one stream
|
||||
* Decoder : decodes encoded data into a raw format
|
||||
* Encoder : encodes raw data into an encoded format
|
||||
* Visualisation : transforms audio into video
|
||||
* Analyzer : reports about the stream contents.
|
||||
* Debug : tee, identity, fakesrc, navseek, ...
|
||||
* Control : controls some aspect of a hardware device
|
||||
* Extracter : extracts tags/headers from a stream
|
||||
* Formatter : adds tags/headers to a stream
|
||||
* ...
|
||||
|
||||
- Based on media type
|
||||
|
||||
Purpose is to make a selection for elements operating on the different
|
||||
types of media. An audio application must be able to filter out the
|
||||
elements operating on audio, for example.
|
||||
|
||||
* Audio : operates on audio data
|
||||
* Video : operates on video data
|
||||
* Text : operates on text data
|
||||
* Metadata : operates on metadata
|
||||
* ...
|
||||
|
||||
- Extra features
|
||||
|
||||
The purpose is to further specialize the element, mostly for
|
||||
application specific needs.
|
||||
|
||||
* Network : element is used in networked situations
|
||||
* Protocol : implements some protocol (RTSP, HTTP, ...)
|
||||
* Payloader : encapsulate as payload (RTP, RDT,.. )
|
||||
* Depayloader : strip a payload (RTP, RDT,.. )
|
||||
* RTP : intended to be used in RTP applications
|
||||
|
||||
3) suggested order:
|
||||
|
||||
<functional>/<media type>/<extra...>
|
||||
|
||||
4) examples:
|
||||
|
||||
apedemux : Extracter/Metadata
|
||||
autoaudiosink : Sink/Audio
|
||||
cairotimeoverlay : Effect/Muxer/Video/Text
|
||||
dvdec : Decoder/Video
|
||||
dvdemux : Demuxer
|
||||
goom : Visualisation
|
||||
id3demux : Extracter/Metadata
|
||||
udpsrc : Source/Network/Protocol
|
||||
videomixer : Effect/Muxer/Video
|
||||
ffmpegcolorspace : Filter/Video (intended use to convert video)
|
||||
vertigotv : Effect/Video (intended use is to change the video)
|
||||
volume : Effect/Audio (intended use is to change the audio)
|
||||
vorbisdec : Decoder/Audio
|
||||
vorbisenc : Encoder/Audio
|
||||
oggmux : Muxer
|
||||
adder : Effect/Muxer/Audio
|
||||
videobox : Effect/Video
|
||||
alsamixer : Control/Audio
|
||||
audioconvert : Filter/Audio
|
||||
audioresample : Filter/Audio
|
||||
xvimagesink : Sink/Video
|
||||
navseek : Debug
|
||||
decodebin : Decoder/Demuxer
|
||||
level : Filter/Analyzer/Audio
|
||||
|
||||
Use cases:
|
||||
|
||||
- get a list of all elements implementing a video effect (pitivi):
|
||||
|
||||
klass.contains (Effect & Video)
|
||||
|
||||
- get list of muxers (pitivi):
|
||||
|
||||
klass.contains (Muxer & !Effect)
|
||||
|
||||
- get list of encoders (pitivi):
|
||||
|
||||
klass.contains (Encoder)
|
||||
|
||||
- Get a list of all visualisations (totem):
|
||||
|
||||
klass.contains (Visualisation)
|
||||
|
||||
- Get a list of all decoders/demuxer/metadata parsers/vis (playbin):
|
||||
|
||||
klass.contains (Visualisation | Demuxer | Decoder | (Extractor & Metadata))
|
||||
|
||||
|
||||
47
docs/design/part-streams.txt
Normal file
47
docs/design/part-streams.txt
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
Streams
|
||||
-------
|
||||
|
||||
This document describes the objects that are passed from element to
|
||||
element in the streaming thread.
|
||||
|
||||
|
||||
Stream objects
|
||||
--------------
|
||||
|
||||
The following objects are to be expected in the streaming thread:
|
||||
|
||||
- events
|
||||
- NEW_SEGMENT (NS)
|
||||
- EOS (EOS) *
|
||||
- TAG (T)
|
||||
- buffers (B) *
|
||||
|
||||
Objects marked with * need to be synchronised to the clock in sinks
|
||||
and live sources.
|
||||
|
||||
|
||||
Typical stream
|
||||
--------------
|
||||
|
||||
A typical stream starts with a newsegment event that marks the
|
||||
buffer timestamp range. After that buffers are send one after the
|
||||
other. After the last buffer an EOS marks the end of the stream. No
|
||||
more buffer are to be processed after the EOS event.
|
||||
|
||||
+--+ +-++-+ +-+ +---+
|
||||
|NS| |B||B| ... |B| |EOS|
|
||||
+--+ +-++-+ +-+ +---+
|
||||
|
||||
1) NEW_SEGMENT, rate, start/stop, time
|
||||
- marks valid buffer timestamp range
|
||||
- marks stream_time of buffers in NEW_SEGMENT
|
||||
- marks playback rate
|
||||
|
||||
2) N buffers
|
||||
- displayable buffers are between start/stop of the NEW_SEGMENT
|
||||
- display_time: (B.timestamp - NS.start) * NS.abs_rate
|
||||
- stream_time: display_time + NS.time
|
||||
- sync_time: display_time + base_time
|
||||
|
||||
3) EOS
|
||||
- marks the end of data, nothing is to be expected after EOS
|
||||
Loading…
Reference in a new issue