The latency of a video is the amount of delay that is incurred from reality to visible video playback.  For example, you are watching yourself on a security camera feed.  You wave your hand.  The latency of the video is how long it takes for you to see yourself wave that hand in the video.

Many factors contribute to the latency of a video:

• The time it takes to create the video in the first place and encode it
• The time it takes the video to be put onto the network (TCP and IP network buffers)
• The time it takes the video to be read, translated, and put back on the network for consumption (EvoStream Media Server role)
• The time it takes to receive the video, potentially buffer it, decode it and display it to the screen (the player)

Each of these latency factors may be influenced to have either higher or lower latency.  Some items that may influence each latency factor include:

• The amount of loss on the network
• The frame-rate of the video
• The configured receive or send buffer

EvoStream has run extensive tests to identify the latency not only of the EvoStream Media Server but also of common video sources and players.  Understanding the latency of all of these components is critical to the design of any low-latency live-streaming platform.

Latency Results

Through testing the various combinations of stream sources and players EvoStream has been able to identify the typical (average) latencies of the various tools.  For all of the various players and stream sources EvoStream has used the default settings and configurations.  This has been done to reflect the most common user experience while also reducing the number of variables at play in these latency tests. The only exception is Flowplayer, where the inbound buffer was set to zero (0).

The latency results, by component, are as follows:

There are a few values that immediately come into focus in the above chart:

• The extremely low amout of time added to the workflow by the EvoStream Media Server. The EMS processes a single frame at a time allowing it to remain highly efficient in its processing.
• VLC, when playing an RTMP stream, uses an enormous buffer, resulting in huge delays in both the playback of the stream and the initial startup of playback.
• The stock android player buffers RTSP and so creates a large amount of latency.
• The source of the stream matters and can greatly effect the overall latency of a workflow.

These results can also be viewed by comparing the calculated total latency of a streaming workflow with the actual observed latency of such a work flow.  This comparison can be found on the next page.

*All times in seconds.

Test Parameters

The tests were performed with the following settings:

Flowplayer buffer = 0

EMS maxRtmpOutBuffer = 524288

Raw Test Results

The following are the raw results from the various work flow tests.

This table is the results of testing direct playback from the Axis Security Camera.

Copyright © 2016 EvoStream Corporation all rights reserved.

All product names and brands are property of their respective owners. All company, product and service names used are for identification purposes only. Use of these names, and brands does not imply endorsement.