mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-04-13 19:44:10 +00:00
docs/design/draft-klass.txt: Add example that needs more thinking.
Original commit message from CVS: * docs/design/draft-klass.txt: Add example that needs more thinking. * docs/design/draft-missing-plugins.txt: More thoughts about wtrapper plugins. * docs/random/ensonic/embedded.txt: * docs/random/ensonic/profiling.txt: More design work.
This commit is contained in:
Stefan Kost
parent
462f32dd4a
commit
df19b21c56
6 changed files with 71 additions and 29 deletions
12
ChangeLog
12
ChangeLog
|
|
@ -1,3 +1,15 @@
|
|||
2007-03-28 Stefan Kost <ensonic@users.sf.net>
|
||||
|
||||
* docs/design/draft-klass.txt:
|
||||
Add example that needs more thinking.
|
||||
|
||||
* docs/design/draft-missing-plugins.txt:
|
||||
More thoughts about wtrapper plugins.
|
||||
|
||||
* docs/random/ensonic/embedded.txt:
|
||||
* docs/random/ensonic/profiling.txt:
|
||||
More design work.
|
||||
|
||||
2007-03-25 Wim Taymans <wim@fluendo.com>
|
||||
|
||||
* libs/gst/base/gstbasesrc.c: (gst_base_src_get_range),
|
||||
|
|
|
|||
2
common
2
common
|
|
@ -1 +1 @@
|
|||
Subproject commit dec151d15512e4cca2dcdd36d9c6c4a2185760ec
|
||||
Subproject commit 57d4a1587556bd42c850601773c662211694c5a6
|
||||
|
|
@ -22,7 +22,7 @@ Purpose:
|
|||
|
||||
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
|
||||
|
|
@ -33,13 +33,13 @@ Proposal:
|
|||
|
||||
<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,
|
||||
|
|
@ -56,17 +56,17 @@ Proposal:
|
|||
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
|
||||
|
|
@ -92,7 +92,7 @@ Proposal:
|
|||
|
||||
- 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
|
||||
|
|
@ -104,9 +104,9 @@ Proposal:
|
|||
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?
|
||||
|
|
@ -114,13 +114,13 @@ Proposal:
|
|||
* 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
|
||||
|
|
@ -149,18 +149,24 @@ Proposal:
|
|||
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):
|
||||
|
|
|
|||
|
|
@ -249,6 +249,12 @@ A three step process:
|
|||
case, but may become an issue in future when applications like buzztard,
|
||||
jokosher or pitivi start requestion elements by name, for example ladspa
|
||||
effect elements or so.
|
||||
|
||||
This case could be handled if those wrapper plugins would also provide a
|
||||
gst-install-xxx-plugins-helper, where xxx={ladspa|visual|...}. Thus if the
|
||||
distro specific gst-install-plugins-helper can't resolve a request for e.g.
|
||||
element-bml-sonicverb it can forward the request to
|
||||
gst-install-bml-plugins-helper (bml is the buzz machine loader).
|
||||
|
||||
|
||||
7) Further references:
|
||||
|
|
|
|||
|
|
@ -25,10 +25,33 @@ Elements with higher rank should be functionaly more complete. If we have
|
|||
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.
|
||||
|
|
|
|||
|
|
@ -14,22 +14,17 @@ $Id$
|
|||
= 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
|
||||
|
|
|
|||
Loading…
Reference in a new issue