Proposal:
- The GstElementDetails contains a field named klass that is a pointer to a
+ 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
<keyword>['/'<keyword]*
- The string consists of an _unordered_ list of keywords separated with a '/'
+ 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
-
+ - functional
+
Categories are base on _intended usage_ of the element. Some elements
might have other side-effects (especially for filers/effects). The purpose
is to list enough keywords so that applications can do meaningfull filtering,
elements can also be implemented with GstBaseTransform.
* Demuxer : splits audio, video, ... from a stream
* Muxer : interleave audio, video, ... into one stream, this is
- like mixing but without losing or degrading each separate
+ like mixing but without losing or degrading each separate
input stream. The reverse operation is possible with a
Demuxer that reproduces the exact same input streams.
* Decoder : decodes encoded data into a raw format, there is typically
no relation between input caps and output caps. The output
- caps are defined in the stream data. This separates the
+ caps are defined in the stream data. This separates the
Decoder from the Filter and Effect.
* Encoder : encodes raw data into an encoded format.
* Mixer : combine audio, video, .. this is like muxing but with
applying some algorithm so that the individual streams
- are not extractable anymore, there is therefore no
+ are not extractable anymore, there is therefore no
reverse operation to mixing. (audio mixer, video mixer, ...)
* Converter : convert audio into video, text to audio, ... The converter
typically works on raw types only. The source media type
- Extra features
- The purpose is to further specialize the element, mostly for
+ The purpose is to further specialize the element, mostly for
application specific needs.
* Network : element is used in networked situations
audio card, video card, usb, ...)
* Visualisation : intended to be used for audio visualisation
* Debug : intended usage is more for debugging purposes.
-
+
- Categories found, but not yet in one of the above lists
-
+
* Bin : playbin, decodebin, bin, pipeline
* Codec : lots of decoders, encoder, demuxers
should be removed?
* File : like network, should go to Extra?
* Editor : gnonlin, textoverlays
* DVD, GDP, LADSPA, Parser, Player, Subtitle, Testing, ...
-
+
3) suggested order:
<functional>[/<media type>]*[/<extra...>]*
4) examples:
-
+
apedemux : Extracter/Metadata
audiotestsrc : Source/Audio
autoaudiosink : Sink/Audio/Device
level : Filter/Analyzer/Audio
tee : Connector/Debug
+ 5) open issues:
+
+ - how to differencial physical devices from logical ones?
+ autoaudiosink : Sink/Audio/Device
+ alsasink : Sink/Audio/Device
+
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)
- get list of video encoders (pitivi):
-
+
klass.contains (Encoder & video)
- Get a list of all audio/video visualisations (totem):
multiple elements that are feature complete there is a draw.
There are more decission criteria thinkable:
+* target processor (CPU,DSP,GPU)
* ressource usage (CPU, memory)
* license (proprietary, open source)
* quality (in terms of the audio/image quality)
One problem of taking criteria like quality and performance into account when
-autoplugging, is that elemnts might have options to control them.
-
+autoplugging, is that elements might have objects-properties that influence
+them.
+
+Beside adding more ranking criteria, we might consider adding an overridable
+mechanism for picking elements (basically registry filters that not decide on
+the base of ranks). Applications might choose the filter mechanism based on the
+use-case (which gstreamer not know right now).
+
+== g_malloc vs. g_try_malloc ==
+g_malloc/g_new should not be used when allocating space of a size that is
+derived from a value found in the file. Instead one should use g_try_malloc or
+g_try_new and check the return value.
+
+$ find . -name "*.c" -exec grep "g_malloc" {} \; | wc -l
+190
+$ find . -name "*.c" -exec grep "g_try_malloc" {} \; | wc -l
+0
+$ find . -name "*.c" -exec grep "g_new" {} \; | wc -l
+398
+$ find . -name "*.c" -exec grep "g_try_new" {} \; | wc -l
+3
+
+This is not strickly related to embedded, but its easier to crash gstreamer on
+embedded this way.
= qos profiling =
* what data is needed ?
- * streamtime,propotion pairs from sinks
+ * (streamtime,propotion) pairs from sinks
draw a graph with gnuplot or similar
* number of frames in total
* number of frames dropped from each element that support QOS
elements that don't support QOS wont have this information anyway
+ * needs to be media type specific:
+ * video: full frames
+ * audio: partial buffers can be dropped in the sink, count number of dropped
+ audio frames
-* idea1: parse data from debug log
- GST_QOS gstbasesink.c:1188:gst_base_sink_send_qos:<xvimagesink0> qos: proportion: 0.895615, diff -16437500, timestamp 0:00:09.208333333
- basesink gstbasesink.c:1542:gst_base_sink_render_object:<xvimagesink0> buffer late, dropping
- basesink gstbasesink.c:2534:gst_base_sink_change_state:<alsasink0> rendered: 1028, dropped: 0
- basesink gstbasesink.c:2534:gst_base_sink_change_state:<xvimagesink0> rendered: 598, dropped: 10
-
- + easy to do
- - debug log changes timing
-
-* idea2: query data (via gst-launch)
+* idea2: query data (e.g. via. gst-launch)
* add -r, --report option to gst-launch
* send duration to get total number of frames (GST_FORMAT_DEFAULT for video is frames)
* during playing we need to capture QOS-events to record 'streamtime,proportion' pairs
projects / platform / upstream / gstreamer.git / commitdiff