Blog

Low Latency Streaming on AWS Cloud

The EvoStream Media Server (EMS) is a highly efficient and scalable Live Streaming Media Server. Using the EMS on Amazon EC2 Instances through the Amazon Marketplace gives you unrivaled flexibility, scalability, and value through not only the highly competitive pricing of both the EMS and Amazon but also through the ease at which massive concurrent streaming can be achieved. You’ll find yourself saving money and spending far less time in building, growing and maintaining your streaming platform.

The most often used word used to describe the EMS is “FAST”:

  • FAST in terms of CPU and memory usage: Can handle at LEAST 400% the number of streams as conventional Java-based software when run on identical hardware.
  • FAST in terms of deployment: Integrate with the EMS over HTTP with JSON. Use any technology you wish: JavaScript, PHP, Perl, etc. EvoStream even provides FREE PHP examples of common integration topics
  • FAST in terms of stream latency: Deliver sub-second end-to-end to your viewers with RTSP, RMTP and MPEG-TS. When we say real time, we mean REAL-TIME!

The Efficiency of the EMS is a critical cost-saving driver for platform operators. Doing more with fewer EC2 instances not only reduces instance up-time costs but it also reduces the amount of time and resources that are required to maintain such a platform. The EMS is 400% more efficient than conventional Java based solutions. This means that each EC2 instance running the EMS can handle the load of 4 conventional instances! The EMS can even be run on Micro instances. Use fewer instances, use smaller instances, save money, save time.

Integration with the EMS could not be simpler. The EMS provides a full Runtime API designed to be used with any server-side code. Send HTTP posts to the EMS to issue commands like pulling streams, pushing streams, generating security aliases, querying usage and much, much more. On the flip side, get automatically notified via HTTP and JSON when critical events happen: Stream is lost, new stream is present, DASH chunk completed and again, much, much more. These dual mechanism provide simple, flexible, and incredibly powerful ways to integrate using traditional RESTful server-side programming!

The low latency streaming of the EMS makes it ideal for many different types of devices and deployment models. EvoStream is often used by Action Sport camera and Wearables vendors for streaming live in Consumer, Prosumer and Enterprise applications. Whether the stream is being sent from a dirt-bike rider to a fan in the stands, or the EMS is enabling real-time-chat between a wearable operator and a back-end expert, low-latency is absolutely critical. The EMS is also deployed in many Security Camera NVR Systems providing real-time viewing of cameras across the internet (with NAT reach-back!).

The bottom line: Scale your business with EvoStream and the Amazon EC2 Marketplace while saving both time, resources AND money!

Introduction

This white paper discusses the benefits of running the EvoStream Media Server (EMS) on Amazon EC2 instances through the Amazon Marketplace. The EMS provides highly efficient Media Servers that can easily be scaled through automated Amazon Marketplace integration. Enjoy the benefits of a low latency, high-throughput and simply integrated Live Streaming Media Server with Amazon EC2!

Efficiency

Efficiency is the core competency of the EvoStream Media Server. In video streaming there are essentially two layers involved: 1) the compressed video and audio payload 2) the packetization and network wrapper of that payload. EvoStream is able to operate on both layers independently and have architected different solutions for each layer, streamlining each.

From a packetization perspective, live streaming comes in two general flavors:

  • True live streaming. Very low latency, connection based
  • HTTP based streaming. High latency, Adaptive Bitrate, simple http file download based

Each streaming type has advantages and disadvantages and is supported in different ways by different players. EvoStream tends to be deployed more often in low latency scenarios but it is highly efficient in delivering both kinds of streams. Below you will find the breakdown of how EvoStream behaves on a variety of AWS instances.

Efficiency Results Overview

RTMP/True Live HLS/HTTP Based
Instance Type CPU Max Bandwidth Max CPU Max Bandwidth Max
C3.8xLarge 11% 8.5 Gbps 12.5% 10.8 Gbps
C4.2xLarge 60% 6.8 Gbps 21% 7.0 Gbps
M3.Medium 62% 3.5 Gbps 11% 3.5 Gbps

Results Discussion

The three AWS instance types used in these tests were selected due to their varying network capacities. These tests show that the EMS will make use of the entire available bandwidth of each instance type well before reaching any CPU limitations. In all of these tests, the number of clients (simulated players) exceeds the capabilities of the particular instance. This is done to clearly show the limitations of the instance type, the resilience of the EMS, and the graceful recovery from network saturation. While at over-capacity, the EMS will continue to respond to connection requests and will attempt to serve each client connection as much as possible. Upon reduction of load the EMS continues operation recovers as should be expected for an enterprise grade media server.

The tests results show a couple of interesting traits:

  • The RTMP tests consistently showed higher CPU usage than HLS due each RTMP stream maintaining an active TCP connection. Each of those connections is receiving it’s own transmuxed live RTMP feed. For HLS the content is created once and stored on disk in 10 second “chunks”. Each client then downloads a copy of each chunk via HTTP.
  • The HLS tests consistently show marginally higher bandwidth utilization. This is due to two factors: the bitrate variability of H.264 and consistent download speeds over HTTP. RTMP is a true-live stream, and so each frame is sent out in real-time. This results in the bandwidth of the RTMP stream varying as the H.264 stream itself varies (often due to motion or frequent scene changes in the video). This variability in the stream is magnified when you have thousands of streams playing the same video. HLS by contrast is defined by the download of data files. The download speeds are consistent and dictated by the TCP connection between the two peers. The detailed test results below show RTMP bandwidth spikes far beyond the trend-line max reported above as well as the HLS maximums, but when taken on average, the variability results in lower average bandwidth for RTMP vs HLS.

Memory usage is not included in the test results, as memory usage never exceeded 15% in any of the tests.

C3.8xlarge Instance Type Details

Test Setup

Stream: 4.1 Mbps Bitrate, H.264/AAC, 1280×720, 24fps

50 steps, 50 new streams per step, 20 between steps

This implies a maximum stream count of 50 X 50 = 2500 streams

Once 50 steps are reached, the test symmetrically steps back down

RTMP Results

aws C3.8xlarge rtmp streaming cpu

aws C3.8xlarge rtmp streaming bandwidth

HLS

aws C3.8xlarge hls streaming cpu

aws C3.8xlarge hls streaming bandwidth

c4.2xlarge Instance Type Details

Stream: 4.1 Mbps Bitrate, H.264/AAC, 1280×720, 24fps

26 steps, 50 new streams per step, 20 between steps

RTMP

aws c4.2xlarge rtmp streaming cpu

aws c4.2xlarge rtmp streaming bandwidth

HLS

aws c4.2xlarge hls streaming cpu

aws c4.2xlarge hls streaming bandwidth

m3.medium Instance Type Details

Stream: 4.1 Mbps Bitrate, H.264/AAC, 1280×720, 24fps

26 steps, 50 new streams per step, 20 between steps

RTMP

aws m3.medium rtmp streaming cpu

aws m3.medium rtmp streaming bandwidth

HLS

aws m3.medium hls streaming cpu

aws m3.medium hls streaming bandwidth

Efficiency Summary

First let’s recap the results from the above graphs:

RTMP/True Live HLS/HTTP Based
Instance Type CPU Max Bandwidth Max CPU Max Bandwidth Max
C3.8xLarge 11% 8.5 Gbps 12.5% 10.8 Gbps
C4.2xLarge 60% 6.8 Gbps 21% 7.0 Gbps
M3.Medium 62% 3.5 Gbps 11% 3.5 Gbps

The efficiency of EvoStream immediately allows you to realize more scale with fewer servers, reducing your AWS rental costs. In addition to this cost savings, you also can do your capacity planning assuming linear and PREDICTABLE usage estimates per server.

  • Reduce costs and complexity by realizing the same capacity with fewer servers
  • By assuming that any server running the EMS can utilize the full networking capacity of the server, your capacity planning becomes trivial.
  • Knowing that the EMS will behave gracefully at max capacity and beyond allows you time to react appropriately to surges in demand

The EvoStream efficiency of course reduces costs in terms of server usage, but also significantly reduces the complexity of your deployments. If you can handle your volume with 10 servers instead of 40 it means you only need one tier of edge servers and perhaps a redundant origin. We’ll discuss ease of deployment in more detail next.

Ease of Deployment

RESTful Interactions

The EMS has been designed for quick integration into any cloud or web based infrastructure. Through our HTTP based API and Event Notification System all integration logic can be fully passive keeping your code clean and simple. For example, take a simple custom load balancing scheme:

Scenario: You have a collection of edge AWS instances you wish to distribute client connections between, adding additional instances if needed to support client demand.

Solution: A simple database table and a web script, written in your developer’s language of choice.

Passively listen for ouStreamCreated and outStreamClosed events

Update your DB

On each client connection, choose the server with the fewest client connections

Done.

To scale simply fire up a new AMI with the EMS pre-configured. On start, the EMS will send a serverStarted. Listen for this event in your web script to dynamically add the new server to the list of server candidates.

That’s it!

Let’s take another example of uploading an MPEG-DASH stream to one of your Amazon S3 buckets for storage and further distribution, possibly through Amazon CloudFront.

Scenario: An EMS server generating an MPEG-DASH stream, currently serving it directly to HTML5 video players. You wish to increase distribution and leverage your Amazon S3 bucket to do so.

Solution: Leverage the scripts provided by EvoStream (open source, written in PHP).

Listen for the DashChunkClosed event

Push chunk and manifest to S3 Bucket.

These are just two examples but illustrate the ease of which the EMS can be extended and integrated into your workflow. Simpler development and faster integration means:

  • Quicker to market
  • Reduced development costs
  • Easier and cheaper maintenance and upgrades

The EMS on AWS allows you to scale up and down your infrastructure dynamically to meet client and viewer needs in real time. It has the flexibility to scale to handle your bursts in traffic and remain resilient in the face of overloading. Do more with less and get back to running your business!

Low Latency

Video streaming in the market today has diverging needs between scalability and low latency. The solutions available today provide one or the other, but both seems to be elusive. The efficiency of the EvoStream Media Server, however, does just that, providing extremely low latency while giving you the scalability you need to support your growing customer base.

To achieve it’s low latency impact, the EMS is entirely driven by the network. Bytes come in, bytes go out, it’s as simple as that. The EMS will process only one frame at a time. This means that it introduces less latency on higher frame-rate videos! For example, for a 30 frames-per-second stream the EMS adds 33 Milliseconds. For a 60 fps stream, the EMS only adds 17 Milliseconds (1 second/ 60 frames per second).

Low latency streaming often requires different architectures and work flows than more traditional streaming scenarios. For industries such as Security/Surveillance, action sport cameras, wearables, and augmented reality, there tends to be a 1-1, or possibly 1-(a few), relationship between the stream originator and the player. This is in contrast to broadcasters who do massive distribution of each stream: 1-n (aka, a lot). These 1-1 streaming paradigms require massively parallel architectures to handle the matching of client to stream. The EMS is uniquely architectured to provide the parallelization needed to make your architecture both resilient and cost effective to promote and accelerate the growth of your business.

CONCLUSION

The EvoStream Media Server is Fast in every sense of the word: efficient, easy to integrate, non-latent.

  • Efficient: Stream more with less servers. Reduce your server usage, simplify your architecture, and capacity plan with confidence
  • Easy Integration: Get to market fast, reduce your development costs and add features with ease
  • Low Latency: Live chat, peer reviews, broadcast within live events. Unlock the potential of TRUE live streaming.

The EvoStream Media Server on the Amazon Marketplace brings you the ultimate platform for building and scaling a truly dynamic and robust LIVE streaming platform.

Any questions? Please get in touch!

The EvoStream Team.

Copyright © 2016 EvoStream Corporation all rights reserved.

Leave a Reply