docs/: Update fast tagreading draft and performance profiling ideas.

Original commit message from CVS:
* docs/design/draft-tagreading.txt:
* docs/random/ensonic/profiling.txt:
Update fast tagreading draft and performance profiling ideas.

ChangeLog

@@ -1,3 +1,9 @@
+2007-11-13  Stefan Kost  <ensonic@users.sf.net>
+
+	* docs/design/draft-tagreading.txt:
+	* docs/random/ensonic/profiling.txt:
+	Update fast tagreading draft and performance profiling ideas.
+
 2007-11-09  Wim Taymans  <wim.taymans@gmail.com>
 
 	* libs/gst/base/gstbasesink.c: (gst_base_sink_set_last_buffer):

docs/design/draft-tagreading.txt

@@ -3,20 +3,20 @@ Tagreading
 
 The tagreading (metadata reading) use case for mediacenter applications is not
 to well supported by the current GStreamer architecture. It uses demuxers on the
-files, which generelly said takes too long. what we want is specialized elements
+files, which generelly said takes too long (building seek-index, prerolling).
-that just do the tag-reading.
+What we want is specialized elements / parsing modes that just do the
+tag-reading.
 
-The idea is to have one plugin 'tagread' simmilar to 'typefind' that provides
+The idea is to define a TagReadIFace. Tag-demuxers, classic demuxers and decoder
-elements for the different formats. The advantage of having those in on plugin
+plugins can just implement the interface or provide a separate element that
-would be that when building a metadatabase one only loads this plugin.
+implements the interface.
 
-Then there would be a tagbin, that similar to decodebin does a typefind and then
+In addition we need a tagreadbin, that similar to decodebin does a typefind and
-plugs the right tagread element. It might plug a demuxer as a fallback solution.
+then plugs the right tagread element(s). If will only look at elements that
+implement the interface. It can plug serval if possible.
 
 For optimal performance typefind and tagread could share the list of already
-peeked buffers.
+peeked buffers (but no idea how we could implement that).
-
-Still it would be nice to reuse code from demuxers/tag-filters.
 
 
 Design
@@ -33,14 +33,31 @@ The plan is that applications can do the following:
 
 * it should have one sinkpad of type ANY
 * it should send EOS when all metadata has been read
-  (and all tags have been sent)
+  "done"-signal from all tagread-elements
-* it could have a generic element that uses taglib
+* special tagread-elements should have RANK_NONE to be not autoplugged by
-  http://developer.kde.org/~wheeler/taglib.html
+  decodebin
-* tagread-elements should have RANK_NONE to be not autoplugged by decodebin
 
+Interface
+---------
+* gboolean iface property "tag-reading"
+  Switches the element to tagreading mode. Needed if normal element implement
+  that behaviour. Elements will skip parsing unneeded data, don't build a
+  seeking index, etc.
+* signal "done"
+  Equivalent of EOS.
 
-Open Issues
+Use Cases
------------
+---------
+
+* mp3 with id3- and apetags
+  * plug id3demux ! apedemux
+* avi with vorbis audio
+  * plug avidemux
+  * new pad -> audio/vorbis
+  * plug vorbisdec or special vorbiscomment reader
+
+Additional Thoughts
+-------------------
 * would it make sense to have 2-phase tag-reading (property on tagbin and/or
   tagread elements)
   * 1st phase: get tag-data that are directly embedded in the data
@@ -55,6 +72,10 @@ Open Issues
     GstTagList *gst_tag_cache_load_tag_data (GstTagCache *self, const gchar *uri);
     gst_tag_cache_store_tag_data (GstTagCache *self, const gchar *uri, GstTagList *tags);
 
+Code Locations
+--------------
+* tagreadbin -> gst-plugins-base/gst/tagread
+* tagreaderiface -> gst-plugins-base/gst-libs/gst/tag
 
 Reuse
 -----

docs/random/ensonic/profiling.txt

@@ -3,7 +3,7 @@ $Id$
 = profiling =
 
 == what information is interesting? ==
-* pipeline throughoutput
+* pipeline through-output
   if we know the cpu-load for a given datastream, we could extrapolate what the
   system can handle
   -> qos profiling
@@ -12,7 +12,6 @@ $Id$
 
 
 = qos profiling =
-
 * what data is needed ?
   * (streamtime,propotion) pairs from sinks
     draw a graph with gnuplot or similar
@@ -37,7 +36,6 @@ $Id$
 
 
 = core profiling =
-
 * scheduler keeps a list of usecs the process function of each element was
   running
 * process functions are: loop, chain, get, they are driven by gst_pad_push() and
@@ -61,7 +59,7 @@ $Id$
 * the profile_percentage shows how much CPU time the element uses in relation
   to the whole pipeline
 
-== rusage + pad-probes =
+= rusage + pad-probes =
 * check get_rusage() based cpu usage detection in buzztard
   this together with pad_probes could gives us decent application level profiles
 * different elements
@@ -89,3 +87,50 @@ $Id$
   // * reset counters on NULL_TO_READY
   // * print results on READY_TO_NULL
 
+= PerformanceMonitor =
+Write a ld-preload lib that can gather data from gstreamer and logs it to files.
+The idea is not avoid adding API for performance meassurement to gstreamer.
+
+== Services ==
+library provides some common services used by the sensor modules.
+* logging
+* timestamps
+
+== Sensors ==
+Sensors do meassurements and deliver timestampe performance data.
+* bitrates and latency via gst_pad_push/pull per link
+* qos ratio via gst_event_new_qos(), gst_pad_send_event()
+* cpu/mem via get_rusage
+  * when (gst_clock_get_time) ?
+  * we want it per thread
+* queue fill levels
+
+== Wanted Sensors ==
+* dropped buffers
+
+== Log Format ==
+* we have global data, data per {link,element,thread}
+
+<timestamp> [<sensor-data>] [<sensor-data>]
+
+* sample
+timestamp [qos-ratio] [cpu-load={sum,17284,17285}]
+00126437  [0.5]       [0.7,0.2,0.5]
+00126437  [0.8]       [0.9,0.2,0.7]
+
+* questions
+** should we have the log config in the header or in some separate config?
+   - if config, we just specify the config when capturing put that
+     in the first log line
+   - otheriwse the analyzer ui has to parse it from the first line
+
+== Running ==
+LD_PRELOAD=libgstperfmon.so GST_PERFMON_DETAILS="qos-ratio,cpu-load=all" <application>
+LD_PRELOAD=libgstperfmon.so GST_PERFMON_DETAILS="qos-ratio,cpu-load=sum" <application>
+
+== Exploration
+pygtk ui, mathplotlib
+
+== Ideas ==
+* can be used in media test suite as a monitor
+