GstShark - InterLatency 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 interlatency tracer measures the time that a buffer takes to travel from one point to another inside the pipeline. The total latency of the pipeline is the time that the buffer needs to go from the source to the sink element (most downstream). However, the interlatency tracer makes it possible to know what route of the pipeline is adding more time to the overall latency by displaying the exact time that the buffer took to go through every element on the pipeline.

The interlatency tracer only provides accurate data when the elements on the pipeline correspond to the categories: source elements, sink elements, or filter elements. This is a known limitation of the tracer.

The interlatency tracer provides the times that each buffer took to get from the source pad of the source element to each other element's source pad. The time displayed in the logs has precision in the order of nanoseconds. As it is expected, the highest values correspond to the time needed for the buffer to travel from the source element to the sink element at the end of the pipeline.

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

Graph

Pipeline

Consider the following pipeline as an example.

$ GST_DEBUG="GST_TRACER:7" GST_TRACERS="interlatency" gst-launch-1.0 videotestsrc ! queue ! videorate max-rate=15 ! fakesink sync=true

The videotestsrc source element is the origin of the buffers. This point is the reference point. and the one that is going to be used as the zero for determining the elapsed time since the buffers went out of the source element and arrived on the source pad of the next elements or in case of the sink element on the sink pad. Every element is connected from its own source pad to the sink pad of the next element as it is shown on the following graph. Besides the pipeline and the graph of it, at following there is the output log of the inter latency tracer and for this scenario, it will display the measurement of 3 times: the time elapsed from the source pad of element 1 to the source pad of element 2, the time elapsed from the source pad of element 1 to the source pad of element 3 and the time elapsed from the source pad of element 1 to the sink pad of element 4; every measure for every buffer that the source element generates.

Output

0:00:05.005932055 12129       0xbbc720 TRACE             GST_TRACER :0:: interlatency, from_pad=(string)videotestsrc0_src, to_pad=(string)queue0_src, time=(string)0:00:01.066017418;
0:00:05.005967402 12129       0xbbc720 TRACE             GST_TRACER :0:: interlatency, from_pad=(string)videotestsrc0_src, to_pad=(string)videorate0_src, time=(string)0:00:01.066054304;
0:00:05.072540930 12129       0xbbc720 TRACE             GST_TRACER :0:: interlatency, from_pad=(string)videotestsrc0_src, to_pad=(string)fakesink0_sink, time=(string)0:00:01.132617436;

Each log entry includes the from_pad and to_pad fields to identify the path that is being measured. It includes also a time field that provides the time it took to get to the specified pad.

Plot