$Id$ = core profiling = * scheduler keeps a list of usecs the process function of each element was running * process functions are: loop, chain, get * 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 = 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: qos: proportion: 0.895615, diff -16437500, timestamp 0:00:09.208333333 basesink gstbasesink.c:1542:gst_base_sink_render_object: buffer late, dropping basesink gstbasesink.c:2534:gst_base_sink_change_state: rendered: 1028, dropped: 0 basesink gstbasesink.c:2534:gst_base_sink_change_state: 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