答复: Measure pipeline I/O latency

[Lijia (George Lee, Euler)]

GstTracer framework indeed can help identify and calculate the time it takes for gst buffer traverses from source to sink in the pipeline, but that time DOES NOT reflect real latency metrics of pipeline performance. In terms of ultra-low latency design goal of media engine that consists of GStreamer sub-system and underlying video/audio driver stack such as demux/decoder/display(render) building block, it is essential to know breakdown of latency for GStreamer and media driver stack, after that we also can know where to optimize or re-work plugin architecture for attaining ultra-low latency goal at endpoint side. However GstTracer is less helpful in that regard coz the data gathered from it does not cover entire situation. 

In my opinion maybe for next formal release of GStreamer, we should consider this new feature which in real-world is very stunning to developer.

-----邮件原件-----
发件人: Arun Raghavan [mailto:arun at arunraghavan.net] 
发送时间: 2016年12月21日 15:06
收件人: Lijia (George Lee, Euler) <george.lee at huawei.com>; gstreamer-devel at lists.freedesktop.org
主题: Re: Measure pipeline I/O latency

On Wed, 21 Dec 2016, at 12:24 PM, Lijia (George Lee, Euler) wrote:
> I am working on ultra-low latency pipeline design for GStreamer 
> 1.10.x, with that goal the primary step should measure the total real 
> processing latency across each element which the overall pipeline makes up of, i.e.
> pipeline I/O latency. Even though there is latency compensation 
> mechanism from source to sink in the pipeline, but it is still not 
> what I am looking for.
> 
> On the other hand I am not sure whether existing GStreamer release has 
> built-in latency metrics mechanism for respective each element or 
> overall pipeline? Maybe we need re-invent such kind of this metrics 
> for GStreamer.

We do have the GstTracer framework which might let you break things down to at least how much time a buffer spends within each element, but if you're looking for sources of I/O latency, you might find something like latencytop or ftrace more helpful (since they are able to perform more system-wide profiling which might be relevant in the case of I/O).

-- Arun