Gst Tracing - Strange Results for Latency

[Andreas Wittmann]

Hi,

I tried to use the tracing infrastructure of GStreamer to determine the latency of pipeline elements. After some tests with unexpected results I stripped down my pipeline and set the following env. variables:

set GST_DEBUG=GST_TRACER:7
set GST_TRACERS=latency(flags=element) 

gst-launch-1.0 videotestsrc num-buffers=1024 ! video/x-raw, width=(int)1920, height=(int)1080, framerate=(fraction)60/1 !  glupload ! fakesink >> out_fhd.txt 2>&1

gst-launch-1.0 videotestsrc num-buffers=1024 ! video/x-raw, width=(int)3840, height=(int)2160, framerate=(fraction)60/1 !  glupload ! fakesink >> out_4k.txt 2>&1

GST_TRACER:

The latencies I observed for the glupload element at 1920x1980 were around 1.7ms and for 3840x2160 around 1.9ms. 

PAD PROBE:

I wrote a small c program implementing the same Pipeline installing a padprobe at the sink/src pad of the glupload element to start/stop a timer there. In this case I measured an average of 0.8ms for 1920x1080 and 2.2ms for 3840x2160.

After reading the documentation, I´d have expected similar results.

Tracing

Tracing

Can you explain the difference? Is it a config problem? The tracing results do not make any sense to me.

My System: Win10, GStreamer 1.16

Thanks!

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mardi 17 septembre 2019 à 10:08 +0000, Andreas Wittmann a écrit :
> Hi,
>
> I tried to use the tracing infrastructure of GStreamer to determine the latency of pipeline elements. After some tests with unexpected results I stripped down my pipeline and set the following env. variables:
>
> set GST_DEBUG=GST_TRACER:7
> set GST_TRACERS=latency(flags=element)
>
> gst-launch-1.0 videotestsrc num-buffers=1024 ! video/x-raw, width=(int)1920, height=(int)1080, framerate=(fraction)60/1 !  glupload ! fakesink >> out_fhd.txt 2>&1

Local test:

gst-stats-1.0  out_fhd.txt
 
Element Latency Statistics:
        0x1f3c2f0.capsfilter0.src: mean=0:00:00.000008692 min=0:00:00.000006503 max=0:00:00.000046321
        0x1f30140.gluploadelement0.src: mean=0:00:00.000304460 min=0:00:00.000255618 max=0:00:00.001849361

>
> gst-launch-1.0 videotestsrc num-buffers=1024 ! video/x-raw, width=(int)3840, height=(int)2160, framerate=(fraction)60/1 !  glupload ! fakesink >> out_4k.txt 2>&1
>

gst-stats-1.0  out_fhd.txt

Element Latency Statistics:
        0xd522f0.capsfilter0.src: mean=0:00:00.000024256 min=0:00:00.000008727 max=0:00:00.000086363
        0xd46140.gluploadelement0.src: mean=0:00:00.001175554 min=0:00:00.000835500 max=0:00:00.008922071

>
> GST_TRACER:
> The latencies I observed for the glupload element at 1920x1980 were around 1.7ms and for 3840x2160 around 1.9ms.
>  
>
> PAD PROBE:
> I wrote a small c program implementing the same Pipeline installing a padprobe at the sink/src pad of the glupload element to start/stop a timer there. In this case I measured an average of 0.8ms for 1920x1080 and 2.2ms for 3840x2160.
>
> After reading the documentation, I´d have expected similar results.
>
> Tracing
>
> Tracing
>
>
> Can you explain the difference? Is it a config problem? The tracing results do not make any sense to me.
>
> My System: Win10, GStreamer 1.16
>
> Thanks!

So basically, on my PC (pretty much a random computer), I get 0.3ms for
FHD and 1.2ms for UHD. Which seams to make sense. You seam to have
computed the mean manually, are you sure you have not made any
manipulation error ?

(Note that I notice some variation/instability on 1.16, all this was
tested with git master. I'm pretty sure there is couple of fixes queued
for 1.16.1)

>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel