I’ve had countless conversations with content producers and website owners who don’t know how their sites deliver videos to their customers. They just know that, for the most part, their tech teams make it work. Internet media delivery is complex and plagued with multiple competing standards, technologies, methodologies, and points of view so it’s no wonder that a non-technical person has trouble wrapping his head around it. It even took me some time to maneuver my way around all the moving parts when I started developing enterprise-level media delivery software more than four years ago.
Surprisingly, there is very little coherent, current and straightforward literature on the Internet that describes the variety of delivery methods available and the pros and cons of each. This article will explain the different delivery methods and how and when they can be used.
Delivering a training video over a corporate intranet where video quality is not the foremost concern is a much different scenario than delivering an entertainment video over the Internet for multiple devices for the best viewing experience.
HTTP DOWNLOAD AND PLAY
HTTP (hypertext transfer protocol) enables the modern day Internet to function. It’s basically the language that web browsers use to talk to web servers in order to send and receive data and content, including web pages and attachments like PDF documents. In the early days of the Internet, back when the majority of us were connecting via dial-up, most videos were delivered by means of simple HTTP download and play. That is, the user would download the entire video to his or her local hard drive before being able to watch it. At the time, this was the most feasible way to deliver video because slow transfer speeds of dial-up connections couldn’t keep up with the rate at which the video played. Today, download and play is used mainly to allow users to download and keep a video they’ve purchased. For instance, some membership-based sites offer HD videos as download-only because their large file sizes makes other delivery methods problematic.
Pros:
- Simple HTTP delivery
- Can deliver videos of any size, encoding, and quality regardless of connection speed (so long as they’re willing to wait for it)
Cons:
- Users have to wait for the entire video to download before they can watch it
- If the user doesn’t watch the entire video, bandwidth was wasted
- The file is downloaded to the user’s hard drive making it easy to pirate
PROGRESSIVE DOWNLOAD
Progressive downloading is the ability to start watching a video before it’s completely downloaded. As long as it is being downloaded faster than the player is playing it, the user is able to watch the entire video without any buffering. If the video isn’t being downloaded quickly enough, the video plays a little, then buffers, then plays, then buffers, etc. (We’ve all experienced this.) Progressive downloading actually started with JPEG images. Remember back in the days of dial-up when you would click to view an image and watch it load from the top down? That is a progressive download – the ability to view the media, in this case images, before it’s entirely downloaded. Once connection speeds were fast enough to make progressive download possible for video, Apple was the first to add it to the Quicktime player. The process also involved moving key metadata from the end of the file to the beginning to so the player would have access to it right away.
Though progressive download was a step in the right direction, it wastes a lot of bandwidth. The amount of video downloaded often is more than the amount watched at any given time. Web servers tend to send video to the player as quickly as they can, which makes the connection’s transfer rate faster than the speed at which the video is played. Say, for instance, a user has a connection that allows him or her to download a video two times faster than is needed to watch it. If he or she stops the video after one minute, an entire minute’s worth of content – and the bandwidth spent to download it – goes to waste. This bandwidth waste adds up over time and can be extremely costly, especially for busy sites that push a lot of video content. (You can tell when a video is being delivered using progressive download if it continues to download after you press pause.)
YouTube used to be a good example of this and delivered videos via pseudo streaming, which is a variation of progressive download. Upon pausing a YouTube video, the user could see it continue to download. The online video sharing giant has since changed its technology (for its desktop player only, as of the date of this publication) and now if you pause a video, it won’t continue to download past a certain buffer point.
Progressive download also introduced the annoying issue of not being able to fast-forward a video to a point that has not yet been downloaded, and the user had to patiently wait.
Pros:
- Simple HTTP delivery
- Users can start watching videos before the entire video is downloaded
Cons:
- Wasted bandwidth if the user doesn’t watch all downloaded content
- User can’t seek to a point in the video that has not been downloaded yet
- The file is downloaded to the user’s hard drive making it easy to share
PSEUDO STREAMING
The term Pseudo Streaming refers to a variation of progressive download that enables fast-forwarding to any point in the video regardless of how much of the video has been downloaded. When the user seeks to a new point in the video, the player makes a new HTTP download request to the server asking to download the file starting at a specific position in the file. In order for Pseudo Streaming to work, video files have to be encoded properly and have the proper metadata, and the site must use a player that supports it. In addition, to Pseudo Stream flash videos the web server must have a specialized plugin installed.
Pros:
- Simple HTTP delivery
- Users can start watching videos before the entire video is downloaded
- Users can seek to any point in the video regardless of how much of the video is downloaded
Cons:
- Wasted bandwidth if the user doesn’t watch all downloaded content
- The user can/is still downloading the file to the hard drive making it easy to pirate
- May need specialized server plugins depending on the type of files being delivered
STREAMING / TRUE STREAMING
Streaming – also known as True Streaming – refers to a group of technologies that enable video delivery by means other than HTTP download and require specialized streaming server software. The most popular streaming solutions are flash streaming, which uses RTMP (real time messaging protocol), and Windows streaming which uses the RTP/RTSP (real time transfer protocol).
These streaming protocols differ greatly from HTTP in that they are stateful connections, which means the player and server are constantly communicating back and forth in the course of a single connection. HTTP is a stateless protocol in that once the player requests a file, the server sends it back and closes the connection.
Since streaming servers are in communication with the users’ players, they are able to deliver video content at the rate the player is consuming it, and they inherently handle seeking to any point in the video. In addition, the video content is not downloaded to the user’s hard drive and is instead consumed directly by the player, making it much harder to copy and share the content. Streaming servers also allow live content streaming, which can’t be done via the previously mentioned methods, and have the ability to switch between different bitrates on the fly to adapt to the user’s network and computing conditions.
Many of the drawbacks of streaming, however, come from the aforementioned differences and benefits. The different streaming protocols don’t communicate over port 80 – the port web browsers use to communicate with web servers – which makes them susceptible to being blocked by firewalls. (This isn’t as much of an issue nowadays, since many offer ways to stream via port 80, but it’s worth mentioning.) The protocols themselves are heavier than HTTP so they add a bit of bandwidth bloat, and more processing is done on the server end which can cause problems when scaling to large numbers of users. Many of the streaming servers are also proprietary and necessitate the purchase of a license to use.
Pros:
- Content is delivered at the rate needed to play it, eliminating wasted bandwidth n Some Streaming servers support adaptive bitrate switching
- Streaming inherently supports quick starting of the video and seeking throughout the video
- The video is not downloaded to the user’s hard drive making it harder to pirate content
- Streaming servers enable the delivery of live content
Cons:
- The various streaming protocols don’t use port 80 which makes them susceptible to firewalls
- Streaming protocols tend to be heavier than HTTP, which can cause bandwidth bloat
- Puts more stress on the server which may make scaling to large numbers of users more difficult and costly
- Many of the streaming servers available are proprietary and require licenses
HTTP ADAPTIVE STREAMING
HTTP Adaptive Streaming (or HTTP Adaptive Bitrate Streaming) is a fairly new technology that is gaining ground in a big way. It can be used for live or on-demand content, and several of the largest video delivery sites on the Internet already use this technology, including: Netflix, Hulu, Amazon, and most recently YouTube. There are several different implementations of HTTP Adaptive Streaming, including Apple’s HLS (HTTP Live Streaming), Microsoft’s Smooth Streaming, and Adobe’s HDS (HTTP Dynamic Streaming).
While there are differences among them, they all conceptually work in the same way. As the name suggests, video content is delivered via HTTP similar to progressive downloads and pseudo streaming; however there’s a big difference in how the video files are downloaded by the player. The encoded video content is segmented into a series of small chunks, each usually a few seconds in duration.
Some solutions have the chunks packaged into a single video file, while others have separate physical files for each chunk (most recent versions use a single file). In addition, a manifest file is created at the time of segmenting, which describes how the file is chunked and how to access each chunk.
The player reads the manifest file and issues HTTP requests for the chunks it needs at any given moment in order to play the video. This means that the player is constantly downloading small pieces of the video as it needs them, instead of wastefully downloading everything in one go.
This technology also enables the player to change the quality of the video on the fly to cope with changing network and computing conditions, hence the word “adaptive” in its name.
Here’s how this works: Multiple versions of the same video are encoded at different bitrates (different quality levels) and then segmented in the exact same way. This means any given chunk in one file is the same segment of video as the corresponding chunk in another file.
For example, if you had two files encoded at different bitrates and segmented into chunks, the 100th chunk of video for each file would be the same small segment of video, just at a different quality level. In this scenario, the manifest file would contain information about both videos, and so the player is aware that it has two different videos to choose from at different bitrates.
The players monitor things like network connection speed and CPU usage and have built-in logic to request chunks from the various files described in the manifest as conditions change.
So, if a player detects that the network connection speed suddenly drops or that the CPU usage on the local machine is too high, it will start requesting chunks from a file with a lower bitrate to reduce stress on the network or CPU. This decreases the viewing quality for the user but keeps the video playing smoothly. As conditions improve, it will request chunks at a higher bitrate, thus improving the viewing quality for the user.
Some of the downsides of HTTP Adaptive Streaming include the necessity to re-encode videos creating multiple versions of each at different bitrates, which requires added storage. In addition, it can be difficult and complex to determine how many bitrates at what viewing size you need to support. Also, depending on the implementation, special server software may be required, though two of the three mentioned above are free. And, of course, a player that supports HTTP Streaming is necessary.
Pros:
- Simple HTTP Delivery
- Only downloads enough of the video to keep the buffer full (i.e. conserves bandwidth)
- Inherently supports seeking throughout the video
- Can be used for live content
- Is able to react to changing network and computing conditions, giving the user a better viewing experience by avoiding buffering and play interruptions
Cons:
- Adaptive bitrate switching requires multiple copies of the same video taking up hard drive space
- Can be difficult and complex to determine the bitrate combinations needed
- A player that supports HTTP Streaming is required, and depending on the implementation, special server software may be required
There are a lot of different ways to deliver video over the web, each having its own benefits, drawbacks, challenges and costs.
This article barely scratches the surface and no matter which of the above methods you choose, you will run across a number of issues not mentioned here. When deciding which method to use, however, it’s important to keep your goals in mind. Different scenarios call for different solutions.
Delivering a training video over a corporate intranet where video quality is not the foremost concern is a much different scenario than delivering an entertainment video over the Internet for multiple devices for the best viewing experience.
It’s important to look at your scenario and see how your problem is being solved by others in the industry. For instance, when the likes of Netflix, Hulu, Amazon and Youtube all choose a specific technology, that’s a significant endorsement in my book.
Sean Green is Red Apple Media’s president of media services. A professional software architect/developer with more than 15 years of design, development and management experience. Green joined CCSI as director of development and, in late 2006, left to form Hyper-Trends LLC, a software development consulting firm. In four years Green grew the business to include several U.S. developers and a team of 12-plus developers in India. In 2012 he sold his share to form Loopback Solutions and joined the Red Apple Media development team. His email address is sean@redapplemedia.com
