Back to Basics: HTTP Streaming
"Back to Basics" is a new StreamingMedia.com column that will feature articles from various authors attempting to clarify and analyze common—and sometimes commonly misunderstood—topics in the online video industry. Got an idea for a topic you'd like to see written about, or that you'd like to write about yourself? Email editor Eric Schumacher-Rasmussen at erics@streamingmedia.com.
One topic of conversation at Streaming Media Europe was the subject of streaming through firewalls. A number of companies discussed the concept, especially around Flash and the significant Silverlight plug-in deployments that have occurred during major political and sporting events this summer.
HTTP streaming invariably came up in the conversation, but there were quite a few claims that didn't seem to be quite right, so I started digging into this complex topic and came up with information that might be valuable to helping Streaming Media readers understand what's meant by HTTP streaming.
Downloads and Progressive Downloads via HTTP
First of all, let's look at the claims about HTTP streaming from a web server. Some content delivery network (CDN) vendors use the term "HTTP streaming" to apply to their HTTP video file downloads or HTTP progressive downloads. Do a Google search for HTTP streaming and you'll come up with numerous instances where HTTP streaming is used for delivery from a web server.
Adding a video file to a web page is fairly simple and good for sites with modest traffic, so potential CDN customers might ask why they should go to the trouble of paying for a CDN service. After all, delivering a progressive download via HTTP is as simple as creating a file such as a Windows Media (wmv or wma); uploading the file to a web server; creating an HTML reference file with an HTTP link to the file; and publishing the link. The file will begin playing as it is downloaded (cached to the client machine) in either a stand-alone player or an embedded player.
For those customers who understand the limitations of HTTP progressive download, and have minimal traffic, a CDN might not be the right answer. Some CDNs, though, offer basic HTTP progressive download delivery services, without calling them HTTP streaming, and charge less for this service than true streaming delivery. This allows potential customers to easily migrate to start simply on a CDN and embrace more sophisticated techniques over time.
True HTTP Streaming with Windows Media Services
So now that we've looked at HTTP progressive downloads, what about HTTP streaming? Since streaming in its truest form is delivery without caching, can an enterprise or a site with significant traffic deliver streams via HTTP?
Yes, although true HTTP streaming requires a complex network of video servers.
HTTP streaming via Windows Media Services is straightforward, including live streaming, using the Windows Media HTTP Streaming Protocol. In explaining the HTTP Streaming Protocol, Microsoft notes the best use for this type of delivery. Besides the ability to push video streaming content through port 80, which is open on many firewalls to allow traditional web traffic that is delivered via HTTP, the Microsoft HTTP Streaming Protocol "is suitable for streaming delivery at a fixed rate or at a data rate correlating closely to rate at which the video will be displayed by the receiver."
This protocol, like other streaming protocols, also allows back-channel communications between the server and the client, allowing the client player to send feedback to the server to change the transmission rate to a secondary stream, which is referred to as "intelligent streaming" or "adaptive streaming."
In addition, on Windows Media files, HTTP streaming can also be used to send commands like fast-forward, rewind, pause, or location seek (also called click-byte or range request). These terms are referred to as "trick mode" requests. It's true that some CDNs using HTTP progressive downloads have done enhancements to their service to simulate these "trick modes" to mimic the seeking capabilities, but these are often proprietary and won’t work with all available players. In addition, it is possible to use HTTP to send controls, while the stream itself is sent by UDP, although Microsoft recommends alternate ways to handle this.
HTTP Streaming with Flash
What about Flash? When someone refers to Flash HTTP streaming they actually mean HTTP tunneling. The Flash server protocol is RTMP, which is designed to be delivered on TCP, rather than the UDP delivery of the more traditional RTSP steaming protocol. Given RTMP's ability to deliver via TCP, Adobe integrated RTMP tunneling via HTTP, which works for both for live or on-demand, although the tunneling causes a bit of extra delay that might not be acceptable in all situations.
In summary, ignoring the equally big issue of protocol rollover to HTTP (which I'll cover in a future article), pay careful attention to services that called HTTP streaming. It took a decent amount of research and talking to others to understand the differences. Don't be afraid to ask a potential CDN partner questions about their service, and ask that the CDN provide someone who can explain their HTTP streaming in simple, consistent terms, not marketing speak.