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.
|
|
|
|
|
2018-04-27 16:40:31 +00:00
|
|
|
In gstreamer core we have some indexing objects. They are currently used nowhere.
|
|
|
|
The idea is to use them and to make the index strategy pluggable or configurable
|
2006-11-15 13:00:16 +00:00
|
|
|
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.
|
2018-04-27 16:40:31 +00:00
|
|
|
The rank of an element right now refers to the quality/maturity of the element.
|
2011-09-07 11:14:38 +00:00
|
|
|
Elements with higher rank should be functionally more complete. If we have
|
2006-11-21 08:30:20 +00:00
|
|
|
multiple elements that are feature complete there is a draw.
|
|
|
|
|
2018-04-27 16:40:31 +00:00
|
|
|
There are more decision criteria thinkable:
|
2007-03-28 13:44:41 +00:00
|
|
|
* target processor (CPU,DSP,GPU)
|
2018-04-27 16:40:31 +00:00
|
|
|
* resource usage (CPU, memory)
|
2006-11-21 08:30:20 +00:00
|
|
|
* license (proprietary, open source)
|
|
|
|
* quality (in terms of the audio/image quality)
|
|
|
|
|
|
|
|
One problem of taking criteria like quality and performance into account when
|
2007-03-28 13:44:41 +00:00
|
|
|
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.
|