gstreamer/docs/random/ensonic/profiling.txt

$Id$

= profiling =

== what information is interesting? ==
* pipeline throughoutput
  if we know the cpu-load for a given datastream, we could extrapolate what the
  system can handle
  -> qos profiling
* load distribution
  which element causes which cpu load/memory usage


= 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 capture QOS-events to record 'streamtime,proportion' pairs
    gst_pad_add_event_probe(video_sink->sink_pad,handler,data)
  * during playback we like to know when an elemnt drops frames
    what about elements sending a qos_action message?
  * 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
      * QOS stats first
      * list of 'streamtime,proportion' pairs
    
  + robust
  + also available to application
  - changes in core

= 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
  gst_pad_pull_range()
* scheduler keeps a sum of all times
* each gst-element has a profile_percentage field

* when going to play
  * scheduler sets sum and all usecs in the list to 0
* when handling an element
  * remember old usecs t_old
  * take time t1
  * call elements processing function
  * take time t2
  * t_new=t2-t1
  * sum+=(t_new-t_old)
  * profile_percentage=t_new/sum;
  * should the percentage be averaged?
     * profile_percentage=(profile_percentage+(t_new/sum))/2.0;

* 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
* different elements
  * 1:1 elements are easy to handle
  * 0:1 elements need a start timer
  * 1:0 elements need a end timer
  * n:1, 1:m and n:m type elemnts are tricky
    adapter based elements might have a fluctuating usage in addition
  
  // 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