Video Delivery in HTTP

As Internet becomes faster and faster, videos become important content of many websites. There’re many methods to publish video on Internet. This blog focuses on technologies around HTTP.

There’re 3 ways to deliver video content in HTTP, progressive download and play, HTTP Pseudostreaming, and Dynamic Adaptive Streaming over HTTP.

0. Why HTTP?

When people choose their video delivery method, HTTP offers a few advantages,

• HTTP doesn’t require a dedicated media server like RTSP/RTP/RTCP and RTMP/RTMPT/RTMPS streaming technologies require. Web Servers (Some of HTTP method requires Plug-in/server-side scripting to support)
• HTTP network packets can reach almost any devices that connected to internet, while many other protocols (e.g. RTMP on port 1935) might be blocked by firewalls.
• HTTP is supported by existing server and caching infrastructure.
• HTTP is stateless, it doesn’t require a consistent one-to-one connection between client and server when video is deliveried and played. So the number of clients a server can serve is higher than connection-oriented method. In other words, HTTP scales better.

1. Progressive Download and Play

This is the most basic method, supported by almost all web servers. (Apache, lighthttpd, IIS, etc.) The basic principle is to download the entire video file and play the file. If the video file is long, the client can download and play the downloaded part at the same time.

The main advantages of this method are,

• Easy to configure (from publisher’s POV)
• Video play can be stopped and buffered (from user’s POV)

The main disadvantages of this method are,

• Entire video is downloaded to the client, unless user close the browser page. It wastes a lot of bandwidth sometimes. Suppose a user watches the first 4 minutes of an one-hour long video, but the entire video is downloaded if the network is fast enough to download in 5 minutes or the user keeps the page open after watching. (From the publisher’s POV and user’s POV when user pay by usage)
• Entire video is downloaded to client, the content is not protected. (From publisher’s POV)
• Video is only seekable for the downloaded part. In other words, if a user want to watch 40~45 minutes in a one-hour long video, he/she needs to wait the video to download the first 40 minutes. (From the user’s POV)

If you watch a unseekable video on a website, and the video can be found on your browser’s cache, most likely the website is using HTTP Progressive download and play.

2. HTTP Pseudostreaming (Pseudo-streaming)

HTTP Pseudo-streaming is, as its name suggests, not real streaming. It is based on progressive download method, but it mimic Video on Demand (VOD) streaming.

It’s not supported on web servers by default, but extensions and plug-ins can be added to Apache, Tomcat, IIS, or lighttpd to support pseudo-streaming.

Besides the advantages metioned for HTTP progressive download and play method, HTTP pseduo-streaming adds the seekable feature to the video. Also as the video is seekable, the skipped part is not downloaded, so it reduces the bandwidth waste at some cases.

If you watch a seekable video delivered through HTTP on a website, and the video can be found on your browser’s cache, then the website is using HTTP Pseudo-streaming to deliver the content to you. As an example, Youtube actually uses this technique with lighthttpd web servers.

3. Dynamic Adaptive Streaming over HTTP (DASH)

This is the latest technology. The basic idea is to divide a video into many small parts and deliver them over HTTP. Those small parts are then combined at the client side and played out. This method supports both video on demand and live streaming.

There are several different implementations of this method with different names, all based on the basic idea mentioned above,

• HTTP Live Streaming (Apple)
• Smooth Streaming (Microsoft)
• HTTP Dynamic Streaming (Adobe)
• Adaptive Bitrate (Octoshape)

The advantages of DASH are,

• not dependent on specifized streaming servers or proprietary transfer protocols
• Better protection for streaming content as the video clip/stream are divided into small chunks

The disadvantages of DASH are,

• Requires client support. e.g. Adobe Flash Player only supports HTTP Dynamic Streaming after 10.1)
• Different implementations are not compatible completely (There’re standardization work on-going and the comptability is on the way…)
• The Live Streaming has longer delay compared with traditional Live streaming technologies (e.g. RTP, RTMP)
• The Live Streaming quality adaption is not as fast as traditional Live streaming technologies as the quality switch can usually only occurs at streamlet boundaries. If the streamlet is 5 seconds, then the quality adaption usually occurs every 5 seconds.

For examples, some video streaming to iPhone Safari are actually using HTTP Live Streaming.