The primary function of a streaming media server, used for the purpose of live video streaming, is to receive encoded live video stream from a remote streaming machine, and to deliver it to numerous clients on the Internet.

During the past few years live streaming has become increasingly cheaper and accessible to video production companies. Media server software license costs have been going down to the point where you can easily rent a server instance from Amazon Web Services and a Wowza Media Server license for just a day.

If you want to produce a live video streaming, also called a live “webcast”, of an event, the general requirements are the following:

• Filming equipment - depending on the size of the event you want to cover, you would need a number of cameras, outputing live video through HD-SDI, HDMI, IEEE 1934 (also known as FireWire and i.Link), or another interface.

• Capture equipment - hardware equipment that receives feed from the cameras and inputs it live in the streaming machine. Companies such as Matrox and Blackmagic have a number of products suitable for all types of productions.

• Streaming machine - hardware that is used to encode the live video feed and send it to the streaming server or CDN (content delivery network). This could be a PC, MacBook Pro, or specialized encoding hardware.

• Streaming media server - one or more streaming servers delivering video feed to all of the clients. This could be a dedicated server, a cloud server, a cluster on Amazon EC2, or else. Alternatively you could use a CDN such as Akamai, Qbrick or other.

There are a number of streaming media servers available on the market. The most prominent of them are Adobe Media Server and Wowza Media Server. There are also open source solutions such as Red5 Media Server. For general purpose live video streaming, all servers provide pretty much the same functionality. The differences come mainly when you need to produce a professional high-end airing. We have chosen Wowza Media Server for our streaming media server provider when producing live webcasts.

When you don’t anticipate more than a few hundred simultaneous viewers for your event, one large Amazon EC2 instance, running a pre-configured Wowza Media Server AMI is usually enough. Nevertheless it is always a good idea to start at least two instances, so that you have a primary as well as a backup streaming server. In case something happens with the primary streaming server, you could quickly move to streaming and utilizing the backup one.

When you need a bulletproof architecture for a more professional production, it is adviseable to setup an edge-origin architecture with a load balancer. Wowza provides functionality out of the box for this use case. However you would need to configure and secure the instance before using it.

Single server configuration

When using a single server instance, it is responsible for receiving the live video feed from the streaming machine as well as for serving the stream to numerous clients. For example, if you are streaming a 1mbps stream and expect 100 simultaneous clients, the streaming server must have a bandwidth of 1mbps + 100 * 1mbps, totalling at more than 100mbps.

If you decide to use only a single instance, make sure you calculate the total bandwidth required. Here are a few links to posts that discuss the difference between bandwidth limits for Amazon EC2 instances:

• AWS, Bandwidth and content delivery

• Bandwidth limits for Amazon EC2

Amazon EC2 provides pre-configured Wowza instances, ready for live video streaming out of the box. Additional plugins and add-ons are available as well, such as live stream recorder, secure publishing plugin, DVR functionality, and more. All of these could be configured after the instance has been started, before the live event commences.

Wowza offers a through documenation as well as a number of articles detailing the configurations for each particular use case.

Edge-origin architecture

When using an edge-origin architecture, you would start at least two server instances, with the possibility to add more during the event. One of the servers (the “origin”) is designated to receiving the video stream and passing it to the “edges”. It could also be configured to act as a load balancer, listening to the “edges” for availability data. The second server (the “edge”) is designated to serve clients with the live video stream, which it is to receive from the “origin”. The “edge” server also acts as a load balancer sender, periodically sending availability data to the load balancer listener (which, as explained, could be the “origin” server itself). With such an architecture the load on the “origin” is reduced, with the “edge” being responsible for serving the clients. During a live event, you could add more “edge” servers, distributing the clients between each of them, and thus reducing the load on the individual instances.

Resources

• Wowza Edge-Origin Configurator - A bunch of scripts that could help you automate the configuration of an edge-origin architecture on Amazon EC2 using a Wowza AMI.

• Wowza Articles - A hugh forum featuring a number of articles and tutorials on how to setup the Wowza Media Server.

Notice: The hardware encoder is not present in the two diagrams above. There are a number of ways to receive a live video feed into a streaming machine that is to encoding and send a video stream to a server. This is not within the scope of this post.