2006-11-21 08:30:20 +00:00
|
|
|
$Id$
|
2006-11-15 13:00:16 +00:00
|
|
|
|
|
|
|
|
= embedded =
|
|
|
|
|
|
|
|
|
|
== 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
|
|
|
|
|
entries marked with the avi keyframe flag.
|
|
|
|
|
|
|
|
|
|
In gstreamer core we have some indexing objects. They are curently used nowhere.
|
|
|
|
|
The idea is to use them and to make the index strategy plugable or configurable
|
|
|
|
|
at run time.
|
|
|
|
|
|
|
|
|
|
The challenge is then to rewrite muxers and demuxers to use them instead of the
|
|
|
|
|
built in index logic.
|
|
|
|
|
|
|
|
|
|
This way the different requirements of desktop and embedded platforms could be
|
|
|
|
|
encapsulated in the indexer strategy.
|
|
|
|
|
|
2006-11-21 08:30:20 +00:00
|
|
|
== 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.
|
|
|
|
|
|
