From 170662e2c17feb3d5208f8d526ee88eae946945f Mon Sep 17 00:00:00 2001 From: Stefan Kost Date: Wed, 15 Nov 2006 13:00:16 +0000 Subject: [PATCH] docs/random/ensonic/: more thinking Original commit message from CVS: * docs/random/ensonic/embedded.txt: * docs/random/ensonic/profiling.txt: * docs/random/ensonic/receipies.txt: more thinking --- ChangeLog | 7 +++++++ docs/random/ensonic/embedded.txt | 20 ++++++++++++++++++++ docs/random/ensonic/profiling.txt | 7 ++++++- docs/random/ensonic/receipies.txt | 37 +++++++++++++++++++++++++++++++++++++ 4 files changed, 70 insertions(+), 1 deletion(-) create mode 100644 docs/random/ensonic/embedded.txt create mode 100644 docs/random/ensonic/receipies.txt diff --git a/ChangeLog b/ChangeLog index dd67f58..62d890b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2006-11-15 Stefan Kost + + * docs/random/ensonic/embedded.txt: + * docs/random/ensonic/profiling.txt: + * docs/random/ensonic/receipies.txt: + more thinking + 2006-11-13 Wim Taymans Patch by: Mark Nauwelaerts diff --git a/docs/random/ensonic/embedded.txt b/docs/random/ensonic/embedded.txt new file mode 100644 index 0000000..f525a56 --- /dev/null +++ b/docs/random/ensonic/embedded.txt @@ -0,0 +1,20 @@ +$ID$ + += 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. + diff --git a/docs/random/ensonic/profiling.txt b/docs/random/ensonic/profiling.txt index 4a1d4d3..e6481a1 100644 --- a/docs/random/ensonic/profiling.txt +++ b/docs/random/ensonic/profiling.txt @@ -76,7 +76,12 @@ $Id$ == rusage + pad-probes = * check get_rusage() based cpu usage detection in buzztard this together with pad_probes could gives us decent application level profiles -* 1:1 elements are easy to handle, n:1, 1:m and n:m type elemnts are tricky +* different elements + * 1:1 elements are easy to handle + * 0:1 elements need a start timer + * 1:0 elements need a end timer + * n:1, 1:m and n:m type elemnts are tricky + adapter based elements might have a fluctuating usage in addition // result data struct { diff --git a/docs/random/ensonic/receipies.txt b/docs/random/ensonic/receipies.txt new file mode 100644 index 0000000..c74a53c --- /dev/null +++ b/docs/random/ensonic/receipies.txt @@ -0,0 +1,37 @@ +$Id$ + += receipies = + +The idea is to collect some recommendations for common, but not so trivial +tasks. docs/design/part-block.txt has something like that already. Ideally these +would go to the application developer manual and there would be sample code. + +== initial seeking == +=== question === +How to I configure the initial playback segment? + +=== idea === +1) set pipeline to PAUSED +2) send seek event +3) set pipeline to PLAYING + +=== problems === +1) would preroll the pipeline only to flush it when the seek comes + + +== async state changes == +=== question === +what to do when gst_element_set_state() returns ASYNC? + +=== idea === +1) listen to the STATE_CHANGED message on the bus +2) trigger next action + +=== problems === +This scatters logic over multiple functions (callbacks). + + +== topic == +=== question === +=== idea === +=== problems === -- 2.7.4