diff --git a/ChangeLog b/ChangeLog index d0b8c34c0a..55bc71d3b3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2007-11-13 Stefan Kost + + * docs/design/draft-tagreading.txt: + * docs/random/ensonic/profiling.txt: + Update fast tagreading draft and performance profiling ideas. + 2007-11-09 Wim Taymans * libs/gst/base/gstbasesink.c: (gst_base_sink_set_last_buffer): diff --git a/docs/design/draft-tagreading.txt b/docs/design/draft-tagreading.txt index b1272da12f..ecf017aa2b 100644 --- a/docs/design/draft-tagreading.txt +++ b/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 -that just do the tag-reading. +files, which generelly said takes too long (building seek-index, prerolling). +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 -elements for the different formats. The advantage of having those in on plugin -would be that when building a metadatabase one only loads this plugin. +The idea is to define a TagReadIFace. Tag-demuxers, classic demuxers and decoder +plugins can just implement the interface or provide a separate element that +implements the interface. -Then there would be a tagbin, that similar to decodebin does a typefind and then -plugs the right tagread element. It might plug a demuxer as a fallback solution. +In addition we need a tagreadbin, that similar to decodebin does a typefind and +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. - -Still it would be nice to reuse code from demuxers/tag-filters. +peeked buffers (but no idea how we could implement that). 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) -* it could have a generic element that uses taglib - http://developer.kde.org/~wheeler/taglib.html -* tagread-elements should have RANK_NONE to be not autoplugged by decodebin + "done"-signal from all tagread-elements +* special 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 ----- diff --git a/docs/random/ensonic/profiling.txt b/docs/random/ensonic/profiling.txt index d6acbb4c52..0866c6957e 100644 --- a/docs/random/ensonic/profiling.txt +++ b/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} + + [] [] + +* 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" +LD_PRELOAD=libgstperfmon.so GST_PERFMON_DETAILS="qos-ratio,cpu-load=sum" + +== Exploration +pygtk ui, mathplotlib + +== Ideas == +* can be used in media test suite as a monitor +