docs/libs/: add types of base classes to enable gobject specific stuff in the docs

Original commit message from CVS:
* docs/libs/Makefile.am:
* docs/libs/gstreamer-libs.types:
add types of base classes to enable gobject specific stuff in the docs
* docs/random/ensonic/embedded.txt:
more ideas about isolating platform specific things
This commit is contained in:
Stefan Kost 2006-11-21 08:30:20 +00:00
parent 2760bf504d
commit 04f6dc0ab7
4 changed files with 42 additions and 7 deletions

View file

@ -1,3 +1,12 @@
2006-11-21 Stefan Kost <ensonic@users.sf.net>
* docs/libs/Makefile.am:
* docs/libs/gstreamer-libs.types:
add types of base classes to enable gobject specific stuff in the docs
* docs/random/ensonic/embedded.txt:
more ideas about isolating platform specific things
2006-11-20 Wim Taymans <wim@fluendo.com> 2006-11-20 Wim Taymans <wim@fluendo.com>
Patch by: Sebastian Droege <slomo at ubuntu dot com> Patch by: Sebastian Droege <slomo at ubuntu dot com>

View file

@ -58,10 +58,8 @@ HFILE_GLOB=$(DOC_SOURCE_DIR)/*/*.h
CFILE_GLOB=$(DOC_SOURCE_DIR)/*/*.c CFILE_GLOB=$(DOC_SOURCE_DIR)/*/*.c
# Dependencies for the intermediate scanobj tool # Dependencies for the intermediate scanobj tool
#SCANOBJ_DEPS = $(top_builddir)/gst/elements/libgstelements.la \ SCANOBJ_DEPS = $(top_builddir)/libs/gst/controller/libgstcontroller-@GST_MAJORMINOR@.la \
# $(top_builddir)/gst/schedulers/libgstbasicomegascheduler.la \ $(top_builddir)/libs/gst/base/libgstbase-@GST_MAJORMINOR@.la
# $(top_builddir)/libs/gst/control/libgstcontrol-@GST_MAJORMINOR@.la
SCANOBJ_DEPS = $(top_builddir)/libs/gst/controller/libgstcontroller-@GST_MAJORMINOR@.la
# Extra options to pass to gtkdoc-scanobj or gtkdoc-scangobj. # Extra options to pass to gtkdoc-scanobj or gtkdoc-scangobj.
SCANOBJ_OPTIONS=--type-init-func="g_type_init();gst_init(&argc,&argv)" SCANOBJ_OPTIONS=--type-init-func="g_type_init();gst_init(&argc,&argv)"

View file

@ -1,4 +1,18 @@
#include <gst/gst.h> #include <gst/gst.h>
#include <gst/controller/gstcontroller.h>
#include <gst/controller/gstcontroller.h>
gst_controller_get_type gst_controller_get_type
#include <gst/base/gstadapter.h>
gst_adapter_get_type
#include <gst/base/gstbasesrc.h>
gst_base_src_get_type
#include <gst/base/gstbasesink.h>
gst_base_sink_get_type
#include <gst/base/gstbasetransform.h>
gst_base_transform_get_type
#include <gst/base/gstcollectpads.h>
gst_collect_pads_get_type
#include <gst/base/gstpushsrc.h>
gst_push_src_get_type

View file

@ -1,9 +1,8 @@
$ID$ $Id$
= embedded = = embedded =
== index handling == == index handling ==
For avidemux I currently have a big patch doing memory optimized index handling. For avidemux I currently have a big patch doing memory optimized index handling.
It basically thins out the index to save memory. Right now it only keeps index It basically thins out the index to save memory. Right now it only keeps index
entries marked with the avi keyframe flag. entries marked with the avi keyframe flag.
@ -18,3 +17,18 @@ built in index logic.
This way the different requirements of desktop and embedded platforms could be This way the different requirements of desktop and embedded platforms could be
encapsulated in the indexer strategy. encapsulated in the indexer strategy.
== ranking ==
Autopluggers like playbin and decodebin use the element caps plus static ranks
to create piplines.
The rank of an elemnt right now refers to the quality/maturity of the element.
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:
* 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.