Use gst-shark (a GStreamer-based tool) to verify
performance and understand the element that is causing performance drops.
To check the instantaneous latencies, run the following command:
GST_DEBUG="GST_TRACER:7" GST_TRACERS="latency" GST_DEBUG_FILE=/run/server.txt
gst-launch-1.0 v4l2src io-mode=4 device=/dev/video0 ! video/x-raw, width=3840,
height=2160, format=NV12, framerate=60/1 ! omxh265enc qp-mode=auto gop-mode=low-delay-p
gop-length=60 periodicity-idr=60 b-frames=0 target-bitrate=60000 num-slices=8
control-rate=low-latency prefetch-buffer=TRUE low-bandwidth=false filler-data=0
cpb-size=1000 initial-delay=500 ! video/x-h265, alignment=nal ! queue max-size-buffers=0
! rtph265pay ! udpsink host=192.168.25.89 port=5004 buffer-size=60000000
max-bitrate=120000000 max-lateness=-1 qos-dscp=60 async=false The latency tracer module gives instantaneous latencies that may not be the same as
the reported latencies. The latencies may be higher if the inner pipeline (element !
element) takes more time, or lower if the inner pipeline is running faster, but the
GStreamer framework waits until the running time equals the reported latency.
Check for the time (in nanosecond for latency) marked in bold in the following logs. The initial few readings may be high due to initialization time, but become stable after initialization is complete. For example, the following logs shows ~12 ms of latency for stream-out pipeline.
0:00:21.633532492 20066 0x558abfb8a0 TRACE GST_TRACER :0:: latency,
src-element-id=(string)0x558abea190, src-element=(string)v4l2src0, src=(string)src,
sink-element-id=(string)0x558ac2b9e0, sink-element=(string)udpsink0,
sink=(string)sink, time=(guint64)12399379, ts=(guint64)21633482297;