⌂
Home

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 measuring the elapsed time since one buffer arrived to the sink pad of the element with the immediate consecutive one, without taking in consideration the time needed for the element to compute the arrived data buffer.

In the same way than the processing time tracer and the inter latency tracer, the schedule time tracer was developed to providing 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 bottle necks 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.

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

Sample diagram

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.

←
Framerate tracer

⌂
Home

→
CPU usage tracer