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 can differ from the
reported latencies. The latencies are 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 are 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;