[Bug 788431] New: tracers: Latency tracer should not include sink synchronization pause

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788431

            Bug ID: 788431
           Summary: tracers: Latency tracer should not include sink
                    synchronization pause
    Classification: Platform
           Product: GStreamer
           Version: 1.13.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: nicolas at ndufresne.ca
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

As of today, we calculate the latency after the buffer has been pushed out of
the peer of the sink sinkpad. As a side effect, if the sink is doing
synchronization on the clock, we will wait for a variable about of time, time
that gets included into the measure latency. This makes the result quite
unreliable (specially on video).

The intention with this trace is to measure the effective latency (including
processing time) inside the pipeline, ignoring the sources and sink latency,
which cannot be measured effectively.

To illustrace better, let's take two camera sources. For both the latency have
been estimated to 1 frame (let's assume 17ms). Then I build a supposedly
zero-latency pipeline like this:

  videosource1 ! videosink
  videosource2 ! videosink

Both sources produce proper timestamps. If videosource1 effectively had 16ms of
latency, the latency tracer would 1ms latency, while if the videosource2 only
take 2ms of real latency, the latency tracer report 14ms. So basically, a lower
latency camera reports more latency through the tracer. This is the case for
v4l2src which currently just assume 1 frame latency since the API does not
explicitly give back this latency. I'm working on adding a proper latency
estimation in that element, but still, would like this to not affect the value
from the latency tracer as it's counter intuitive.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.