docs/random/ensonic/: more ideas

Original commit message from CVS:
* docs/random/ensonic/distributed.txt:
* docs/random/ensonic/profiling.txt:
more ideas
This commit is contained in:
Stefan Kost 2006-11-06 15:17:35 +00:00
parent 894b7f9f4a
commit eb80a8aef5
3 changed files with 36 additions and 0 deletions

View file

@ -1,3 +1,9 @@
2006-11-06 Stefan Kost <ensonic@users.sf.net>
* docs/random/ensonic/distributed.txt:
* docs/random/ensonic/profiling.txt:
more ideas
2006-11-06 Stefan Kost <ensonic@users.sf.net>
* docs/gst/gstreamer-sections.txt:

View file

@ -26,7 +26,17 @@ GstElement* gst_element_factory_make_remote (const gchar *factoryname,
and some API to get a remote factory handle via hostname lookup, ip address
lookup or even zeroconf (avahi).
== remote server ==
The remote server manages pipelines with elements that are bound to the proxies.
Each pipeline has an id, that refers to the client+the clients pipeline address.
Proxyelements supply the client. pipeline address pair when creating remote
elements.
== issues / thoughts ==
* we need to distribute the clock
* is dataprotocol-library useful to send events, data, property- and state-
changes
* we need to sync the remote pipelines with the main-pipeline

View file

@ -73,6 +73,26 @@ $Id$
* the profile_percentage shows how much CPU time the element uses in relation
to the whole pipeline
== 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
// result data
struct {
beg_min,beg_max;
end_min,end_max;
} profile_data;
// install probes
gst_bin_iterate_elements(pipeline)
gst_element_iterate_pads(element)
if (gst_pad_get_direction(pad)==GST_PAD_SRC)
gst_pad_add_buffer_probe(pad,end_timer,profile_data)
else
gst_pad_add_buffer_probe(pad,beg_timer,profile_data)
// listen to bus state-change messages to
// * reset counters on NULL_TO_READY
// * print results on READY_TO_NULL