Back to Top

How to set up a reliable video streaming architecture

The bulk of network packets on the internet are now for audio/video applications. This article gives some background information on the growing use of video, the standards, hosting and infrastructure requirements.

Look over the shoulder of a person with his notebook or sliding his fingers over her smart phone and it is very likely that a video is being watched. If not, it's very likely the screen will have a link to a video. Many of us watch hours of movies or TV programs on the Internet every day. It is hard to imagine that we could be watching more video content but that is the prediction for the coming years. A report in 2015 by Cisco claims that 80% of all Internet traffic will be audio/video. A more recent report titled "The Zetabyte Era" has more detailed figures.

This is all the more surprising because video over the Internet was once deemed a distant dream. Please note that when I mention video in this article it includes audio channels as well; a movie without sound would not be of much use. Video requires a lot more data traffic than textual content and, more importantly, there are time considerations that are strict. Audio/video data have to arrive as a constant stream over the network for optimum performance. Text data that arrives 20 milliseconds late will have no material impact; that same delay in the case of video may make it unwatchable. Too much data over a short timespan and routers can get overloaded; too litle data will result in a blank screen with the ominous "Buffering..." error message.

When Tim Berners-Lee setup the first web server all content was textual. In fact, even static images were a later addition. The designers of the web and other data transfer protocols, however, had the foresight to prepare the groundwork for other types of media such as audio and video. In the heyday of Napster and MP3 files, audio and video could be transferred over the Internet but the entire contents had to be downloaded before it could be watched or listened to. Streaming media (ie without having to do an initial download) took a few more years before it became commonplace.

Now services such as Netflix and Hulu make it possible to watch full-length movies in a comfortable manner. Even social media purveyors such as Facebook and Twitter have multimedia content in the form of live streaming or on-demand clips. For those that enjoy sports there are Internet-based channels that offer high-resolution live streams. All this is entering the fabric of our lives and becoming common-place. To consume these services just require a suitable computing device (desktop, notebook, tablet, smart phone, etc) with a browser. However, to offer the services the infrastructure necessary is not trivial to put together on your own.

What is necessary for a hosted video streaming service

On-demand audio/video requires reliable storage for starters. Good network connectivity, high bandwidth, low jitter and reasonable latency characteristics place demands on the servers and network equipment that service providers need to have. Operating this requires a managed data center. On top of this, security demands that threats from a variety of nefarious sources need to be thwarted or, at least, managed. The DDOS (Distributed Denial of Service) attack at the beginning of October 2016 from unprotected IoT devices on the Internet indicate what may become common in the future. A hosted streaming server that is managed well makes the best sense. One that is run by an organization that has the means to defend itself.

Let's see what is necessary for a hosted video streaming service. The days of video players that are browser plugins are coming to an end. The problem with them is that plug-ins offer an attack surface on a browser. When one counts the number of Flash vulnerabilities that have been exploited and then fixed at a later stage one wonders how many tens of thousands of machines have been compromised as a result. The W3C decided to make built-in video players as part of the HTML5 web standard. Since then H.264 players have been available in most browsers. However, the standard is still evolving and not all players that are still being used incorporate the latest standards. The HTML5 video player is capable of decoding HLS (HTTP Live Streaming, Apple's streaming protocol) as well as MPEG-DASH (vendor-neutral standard; MPEG is the Moving Picture Experts Group and DASH stands for Dynamic Adaptive Streaming over HTTP). The important thing to note here is that both these technologies are based on HTTP, the workhorse of the web. At the server end, HLS and MPEG-DASH can be generated by web servers either natively or through a plug-in (Editor's note: a plugin on a server is far less of a menace compared to one on a desktop because servers are, with few exceptions, managed better). The server uses either a file or a live stream as input for the HLS or MPEG-DASH stream.

That covers both ends of the service but there is a small matter about the middle. How can one reduce network delay and/or bandwidth? This is where caching servers can come in. A single streaming server can get overloaded if there is a sufficiently large number of browser clients. To lighten the load on the server a caching server - possibly located much closer to the client - can improve the whole experience by reducing the latency and the jitter. Before the advent of HTTP streaming the commonly used protocol was RTP/RTSP. Jitter was a big issue there; it is less of a problem with HTTP streams. RTSP, however, had one big advantage for enterprises: multicasting. As of now there is nothing to replace that and no technologies are in sight.

This is the first part of a series of three articles about video hosting in the cloud.

Read the scond part of the series:
Video hosting in the cloud: More on Codecs and Streaming»

About the author:

Raju Varghese is a consultant at a large Swiss financial firm. Though he started with computer hardware he quickly moved to software when it was still done on punched cards. Before the web he worked on systems and network software; now anything related to the web and multimedia grabs his interest. Raju is a senior member of the IEEE.

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <h2> <h3> <h4> <h5> <h6> <!--break--> <p> <div> <img>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.