mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-26 19:51:11 +00:00
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.
This commit is contained in:
Stefan Kost
parent
2c51884bb8
commit
0bd2f79ed3
3 changed files with 92 additions and 20 deletions
|
|
@ -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):
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue