<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 5 juin 2019 17 h 55, Taoming Huang <<a href="mailto:taoming29@gmail.com">taoming29@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I am working a WebrRTC RTP streaming application which has a low latency requirements using GStreamer 1.14. I would like to calculate latency, and emit it as a metrics on an element basis. I have several ideas, but I'm not sure if they are valid.</div><div><ol><li>GStreamer Tracer -- This has too much burden on the CPU as far as I tested.</li></ol></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Since 1.16 the latency tracer supports per element latency, and also trace the latency being reported. The per element latency trace adds a bit of load, but I've never seen anything close to 1ms overhead (and is constant), so nothing close to a problem for the quality of the measurements. The tracing of the reported latency is near to free. All algorithm in this tracer are 0(1).</div><div dir="auto"><br></div><div dir="auto">I'm sure you can backport this tracer to 1.14 without issues if needed.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Latency query -- Latency query calculates latency for the pipeline/element, and I think it only updates when elements are added or removed.</li></ol></div></div></blockquote></div></div><div dir="auto">This is tracked by the new latency tracer. When an element has a latency change, a latency message is posted. It's up to the application to decide when to update.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Buffer probe with PTS -- I thought PTS will be a unique ID and will not be changed, and we can calculate the running time (absolute time - base time) before the buffer comes into the element, and calculate the running time after the buffer comes out of the element -- However, it seems that buffers can either be dropped or changed -- I wonder in this case, will the buffer PTS be changed?</li></ol></div></div></blockquote></div></div><div dir="auto">Timestamp on buffers don't really help with measuring latency. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ol><li>Buffer probe/new plugin with GstMeta -- If the PTS is not reliable, I thought about adding the running time timestamp into buffers using GstMeta before coming into the element, and when the buffers come out of the element, we can check the added timestamp with the current running time which is the latency measurement -- However, again, will the metadata that I added be changed in the element?</li></ol></div></div></blockquote></div></div><div dir="auto">Same.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div></div>