The latency for an end-to-end stream using mpegts is ~40% larger.
The power consumption is ~5% greater.
I tried all the various controls (max performance, etc), w/o managing to achieve the same performance as the omx software.
R32.3.1
Hi,
Please share the steps of profiling latency. We will have teams try to reproduce it. Also is it seen in nvv4l2h264enc-omxh264enc comparison? Comparing v4l2 h264 to omxh264 looks more reasonable.
The measured latency always starts high (as much as 280ms) and drops over 10-20 seconds to ~180ms.
The nvv4l2 software has somewhat higher starting latency than the omx software, with a smaller final latency.
My original measurement was defective, in that I had not waited for nvv4l2 test to settle.
My apologies for any confusion.
The improving latency over time was referenced in https://devtalk.nvidia.com/default/topic/1067350/jetson-tx2/asymmetrical-and-variable-h-264-end-to-end-latency/post/5406425/
I have not been able to resolve that issue. (setting max clocks and ensuring SPS/PPS is generated had no effect)
That post also describes the test setup.
Hi,
We think the latency is from UDP protocol. You may check if there is properties you can tune to reduce it. We don’t make any modification to gstreamer native elements like udpsink, udpsrc.
gstreamer offers many elements and we can simply build a usecase such as RTSP, video playback, video transcoding. However, it may be with slightly higher latency. And we offer lower level tegra_multiemdia_api as another alternative. It is low level but you have to build some functions such as h264parse, qtmux, udpsink, by yourself.