<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 12/21/2016 09:36 AM, Lijia (George Lee, Euler) wrote: </div> <blockquote cite="mid:66C5EB29B1BF4047A864681546B66FC0D7CF55@DGGEMA502-MBX.china.huawei.com" type="cite"> <pre wrap="">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. </pre> </blockquote> First step is to formulate the exact question we want to get answers for - 'getting a latency break down' is unfortunately too high level. Look at the definition of latency, e.g. " <meta http-equiv="content-type" content="text/html; charset=utf-8"> <span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, Arial, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none;">Latency is the delay from input into a system to desired outcome". <span style="color: rgb(0, 0, 0); font-family: Calibri, Helvetica, Arial, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none;"> In the case of playing a video latency is only an issue if the sum of the latencies in each element is more that what we require to play video (the frame rate and audio rate detemining the upper bounds). Now there are many thing that make this more complicated. E.g. when parsing the container format we aren't yet constarined by the frame rate, since we don't play yet. But this is also a kind of latency (the preroll-time). Once we're playing we also need to consider buffering, so if we have buffering peak latencies before the buffer are not fatal, but the overall latency increases. In general we can get a lot of data out of a running pipleine with the tracer. So if we have concrete questions that we seek answers for we can write tracer tools that post process the logs to answer those and extend the tracers as needed. Stefan <blockquote cite="mid:66C5EB29B1BF4047A864681546B66FC0D7CF55@DGGEMA502-MBX.china.huawei.com" type="cite"> <pre wrap=""> 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 [<a class="moz-txt-link-freetext" href="mailto:arun@arunraghavan.net">mailto:arun@arunraghavan.net</a>] 发送时间: 2016年12月21日 15:06 收件人: Lijia (George Lee, Euler) <a class="moz-txt-link-rfc2396E" href="mailto:george.lee@huawei.com"><george.lee@huawei.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> 主题: Re: Measure pipeline I/O latency On Wed, 21 Dec 2016, at 12:24 PM, Lijia (George Lee, Euler) wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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 _______________________________________________ gstreamer-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </pre> </blockquote> </body> </html>