From eb80a8aef59918e5c5e848d394110bba04d89e7f Mon Sep 17 00:00:00 2001 From: Stefan Kost Date: Mon, 6 Nov 2006 15:17:35 +0000 Subject: [PATCH] docs/random/ensonic/: more ideas Original commit message from CVS: * docs/random/ensonic/distributed.txt: * docs/random/ensonic/profiling.txt: more ideas --- ChangeLog | 6 ++++++ docs/random/ensonic/distributed.txt | 10 ++++++++++ docs/random/ensonic/profiling.txt | 20 ++++++++++++++++++++ 3 files changed, 36 insertions(+) diff --git a/ChangeLog b/ChangeLog index 5a55720..a9b0cfc 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2006-11-06 Stefan Kost + * docs/random/ensonic/distributed.txt: + * docs/random/ensonic/profiling.txt: + more ideas + +2006-11-06 Stefan Kost + * docs/gst/gstreamer-sections.txt: add new API and fix the build diff --git a/docs/random/ensonic/distributed.txt b/docs/random/ensonic/distributed.txt index 4309353..19f2c5d 100644 --- a/docs/random/ensonic/distributed.txt +++ b/docs/random/ensonic/distributed.txt @@ -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 diff --git a/docs/random/ensonic/profiling.txt b/docs/random/ensonic/profiling.txt index 4e5aeae..4a1d4d3 100644 --- a/docs/random/ensonic/profiling.txt +++ b/docs/random/ensonic/profiling.txt @@ -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 -- 2.7.4