docs/random/ensonic/profiling.txt: Ideas about qos profiling.

Original commit message from CVS:
* docs/random/ensonic/profiling.txt:
Ideas about qos profiling.
This commit is contained in:
Stefan Kost 2006-08-30 12:28:55 +00:00
parent cf85710b39
commit 8a74297153
2 changed files with 39 additions and 1 deletions

View file

@ -1,3 +1,8 @@
2006-08-30 Stefan Kost,,, <ensonic@users.sf.net>
* docs/random/ensonic/profiling.txt:
Ideas about qos profiling.
2006-08-29 Wim Taymans <wim@fluendo.com> 2006-08-29 Wim Taymans <wim@fluendo.com>
* gst/gstcaps.c: (gst_caps_structure_is_subset_field): * gst/gstcaps.c: (gst_caps_structure_is_subset_field):

View file

@ -1,6 +1,6 @@
$Id$ $Id$
Could schedulers do a little profiling? = core profiling =
* scheduler keeps a list of usecs the process function of each element was * scheduler keeps a list of usecs the process function of each element was
running running
@ -24,3 +24,36 @@ Could schedulers do a little profiling?
* the profile_percentage shows how much CPU time the element uses in relation * the profile_percentage shows how much CPU time the element uses in relation
to the whole pipeline to the whole pipeline
= qos profiling =
* what data is needed ?
* streamtime,propotion pairs from sinks
draw a graph with gnuplot or similar
* number of frames in total
* number of frames dropped from each element that support QOS
elements that don't support QOS wont have this information anyway
* idea1: parse data from debug log
GST_QOS gstbasesink.c:1188:gst_base_sink_send_qos:<xvimagesink0> qos: proportion: 0.895615, diff -16437500, timestamp 0:00:09.208333333
basesink gstbasesink.c:1542:gst_base_sink_render_object:<xvimagesink0> buffer late, dropping
basesink gstbasesink.c:2534:gst_base_sink_change_state:<alsasink0> rendered: 1028, dropped: 0
basesink gstbasesink.c:2534:gst_base_sink_change_state:<xvimagesink0> rendered: 598, dropped: 10
+ easy to do
- debug log changes timing
* idea2: query data (via gst-launch)
* add -r, --report option to gst-launch
* send duration to get total number of frames (GST_FORMAT_DEFAULT for video is frames)
* during playing we need to somehow listen to/capture/intercept QOS-events to record
'streamtime,proportion' pairs
* after EOS, send qos-queries to each element in the pipeline
* qos-query will return:
number of frames rendered
number of frames dropped
* print a nice table with the results
+ robust
+ also available to application
- changes in core