rtph264depay has a queue setting as well as rtspsrc. Setting rtspsrc latency to zero the video frames are not very smooth.

+

Increasing the value to around 30 causes the video is smooth and appears low-latency (not yet tested with camera / screenshot). udpsrc likely has a similar parameter. Also the introducing queue elements adds some latency (hopefully configurable).

+

+

+

[[Category:DM36x]] [[Category:LeopardBoard]] [[Category:GStreamer]]

[[Category:DM36x]] [[Category:LeopardBoard]] [[Category:GStreamer]]

Revision as of 16:26, 30 October 2012

A simple test to get a feel for the amount of system latency when RTP network streaming live video from a LeopardBoard 365 to a PC. A website that displays a running stop watch (http://stopwatch.onlineclock.net) is captured by the target hardware camera, streamed over the network using RTP and displayed on the PC. The windows on the PC are arranged in such a manner that both the stop watch web page and the live video screen are visible. The PrintScreen feature is used to grab a snapshot of both screens at the same time. The difference between the time on the stopwatch and the time displayed on the live video screen shows the approximate system latency.

PC receiving video only pipeline

Before starting PC video playback, you may have to adjust the caps parameters to udpsrc in the gst-launch command below. Look around 40 lines down from the output of the target hardware gst-launch video transmit command for a line similar to:

Optimization ideas

rtph264depay has a queue setting as well as rtspsrc. Setting rtspsrc latency to zero the video frames are not very smooth.
Increasing the value to around 30 causes the video is smooth and appears low-latency (not yet tested with camera / screenshot). udpsrc likely has a similar parameter. Also the introducing queue elements adds some latency (hopefully configurable).