GstShark - Schedule time tracer

GstShark
Getting Started
Getting the code Dependencies Building tracers Eclipse Plugin
Generating trace files
Tracer Parameters
Available Tracers
InterLatency Processing time Frame rate Schedule time CPU usage Graphic Bitrate Queue Level Buffer
Results
Common Trace Format Pipeline Diagram
Visualization Tools
gstshark-plot Eclipse plugin
Examples
CPU usage analysis Frame rate example Processing time example Scheduling time example Interlatency example
Contact Us

The schedule time tracer is very similar to the processing time tracer. The processing time is focused on measuring the time that an element takes to completely process a given buffer and that is why it is measured on the source pad of that element because when the buffer gets to that point is when the element has finished its process and the buffer is ready to be pushed to next element. On the other side, what the scheduling time tracer does is measure the elapsed time since one buffer arrived at the sink pad of the element with the immediate consecutive one, without taking into consideration the time needed for the element to compute the arrived data buffer.

In the same way as the processing time tracer and the inter latency tracer, the schedule time tracer was developed to provide precise data to the user about the time needed by the pipeline to process a given data buffer completely and, with this, the performance of the pipeline. This tracer is not focused on the performance of the pipeline itself, like the processing time tracer and the inter latency tracer, instead, it helps the user detect when and where data is being lost. In pipelines where live sources are present for audio and video and the outcome has several issues with synchronization or with frozen images, this tracer proves very useful. The schedule time tracer is useful for detecting bottlenecks on the pipeline, buffer drops, inter-clock differences, and others.

This tracer does not have any limitation of the type of element that is being measured, the only requirement is that it has to have a sink pad because of the nature of the tracer.

The schedule time tracer measures the difference between the arrival of a data buffer on the sink pad of an element and the arrival of the following buffer. So, under normal operation, these values remain constant for the same element once the pipeline is stable. However, when buffer drops or other issues happen, the tracer measures an increased delay between two immediate buffers.

Problems running the pipelines shown on this page? Please see our GStreamer Debugging guide for help.

Graph

Pipeline

The following pipeline demonstrates the use of the scheduletime tracer and the results obtained.

$ GST_DEBUG="GST_TRACER:7" GST_TRACERS="scheduletime" gst-launch-1.0 v4l2src device=/dev/video0 do-timestamp=true ! 'video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, framerate=(fraction)10/1' ! videoconvert ! queue ! avenc_h263p ! fakesink sync=true

Output

0:00:01.696032908 13338 0x16532d0 TRACE GST_TRACER :0:: scheduletime, pad=(string)capsfilter0_sink, time=(string)0:00:00.099998663;
0:00:01.696074070 13338 0x16532d0 TRACE GST_TRACER :0:: scheduletime, pad=(string)videoconvert0_sink, time=(string)0:00:00.100000780;
0:00:01.706234597 13338 0x16532d0 TRACE GST_TRACER :0:: scheduletime, pad=(string)queue0_sink, time=(string)0:00:00.100140205;
0:00:01.706300516 13338 0x1653400 TRACE GST_TRACER :0:: scheduletime, pad=(string)avenc_h263p0_sink, time=(string)0:00:00.100140252;
0:00:01.711455532 13338 0x1653400 TRACE GST_TRACER :0:: scheduletime, pad=(string)fakesink0_sink, time=(string)0:00:00.088935196;

Each line of the log output contains a pad field that identifies the element being measured and a time field that shows the measured delay between consecutive buffers.