Understanding the different types of On-Demand streaming
Years of video are streamed every day. Yes, literally years worth of video are watched by the world each and every day over the Internet. From the perspective of a viewer, it’s all really easy. But if you’re interested in streaming your own content then there are a few things you need to understand before you get too far.
One of those things is what online streaming actually is, and the different options you have. For the most part, “streaming” is considered delivering data (video or audio) from one place to another over a network. Technically though, that’s a squishy definition. You’ll see why later in the blog.
Currently there are three different ways to “stream”:
- Progressive download
- Streaming protocols
- Adaptive streaming
Which one you want to use depends on what you are trying to do, and who you want to view the videos.
Originally, “streamed” audio and video were delivered to a viewer over HTTP much like other website content such as images (this method is often called HTTP Streaming). The video would be downloaded to a computer then saved temporarily on a hard drive. Playback started once enough of the file had been downloaded to begin playing. The rest of the video would be downloaded in the background during playback.
From the viewer’s perspective, the video just played and they didn’t have to wait for it to completely download. The process was much faster than having to wait for the entire video to download before watching. But also from the viewer’s perspective, there would be an annoying wait before the video would begin. And also you’re not able to skip ahead on the video if it hadn’t downloaded yet.
I remember watching YouTube videos and waiting for the play bar to completely fill up before I would press play. If I didn’t, then the playback inevitably caught up with the download and the video would stop. But that was many years ago when there was no such thing as true high speed broadband Internet. It’s important to know though, that progressive download still works this way. Viewers with really poor Internet connections will have to wait, and may experience pausing of the video while the download catches up. They also can’t skip around in the video.
Also videos streamed this way are only at a single bitrate. There is one video file that is delivered to everyone regardless of their connection. However, once the file is downloaded everyone should be able to view the video in whatever bitrate it was encoded (unless they don’t have a device capable of it in terms of computing power). And because the whole video is downloaded, the content provider pays for the entire bandwidth used even if only a portion of the video is watched.
Another downside to this type of streaming, from a content creator’s point of view, is that the video is actually downloaded onto the viewer’s machine. This makes this method inherently insecure because viewers can make a copy of the video (if they know how, and there is always someone that knows how).
The upside to progressive downloading is that it doesn’t take any special software or servers to use this method. Since it uses standard HTTP over TCP it’s just like most other website content. And there have been many adaptations to make progressive downloads function better for those who want to skip around the video and to restrict how much of the file is downloaded while still using HTTP. Many of those changes (including throttling) do offer something close to a true streaming experience.
And now you’ll see why the definition of streaming is technically a bit squishy. There are protocols designed specifically for streaming that use a different mechanism than progressive downloads. The protocols are Real Time Messaging Protocol (RTMP) and Real Time Streaming Protocol (RTSP). And this is where the technical details come into play. Media delivered using RTMP is streamed in chunks, whereas media using progressive download is sent (downloaded) via HTTP. It may seem like a small difference but there are some large differences when it comes to creating the content.
For one, this type of streaming requires the use of a streaming server. The server does the work of sending the video file over the Internet to the end user. The advantage this method has is the video is never stored on the viewer’s computer. It’s transferred in chunks as a video player requests them. Once the chunk is played, the player discards the information. This prevents copying of the information off the hard drive (there are other ways to copy streaming content, but this form of streaming is more secure than progressive download).
Another advantage is the viewer can skip around the video. The player simply sends a request to the streaming server and sends the appropriate chunks for the timestamp the viewer requested. It can also achieve much faster transfer rates, and thus fast play times because it uses UDP rather than TCP (and there are arguments on both sides why that is a good thing and why it isn’t).
So there are many benefits to using a streaming protocol, but they do require obtaining, configuring and use of a server. These can be actual pieces of hardware you need to buy and maintain, or they could be software solutions hosted by streaming providers.
The streaming video though, is usually provided at a single bitrate, though many players offer the viewer the chance to change the bitrate – assuming the content owner provides a variety of bitrates to the server.
Adaptive bitrate streaming
The latest methodology for streaming takes the next logical step by using the best of both methods already discussed. Video can be delivered over HTTP, but it can also be streamed over UDP. Both can use various bitrates.
The basic concept is that the bitrate of the streamed content changes depending on current local network conditions and computing resources. Here’s how it works:
- A video creator uploads the files encoded for a variety of bitrates (to support conditions for HD viewing down to very low bitrates for poor connections).
- The viewer’s video player monitors network and computing conditions to determine the best bitrate the viewer can see without problems. It then sends a request to the server for the right bitrate. Exactly how this is done varies depending on players, servers, and protocols but generally they will assess the state of things every 5-10 seconds.
- The viewer sits back and enjoys the video with the highest possible quality given their current conditions, which may change over the course of a single video.
There really isn’t much of a downside to adaptive streaming other than the time and preparation to create the various bitrate files and the supporting data the players need. There are encoders designed for multi bitrate streaming to make it easier. It’s becoming the standard for most major streaming platforms and technology owners like Apple (HLS Live Streaming), Adobe (HTTP Dynamic Streaming) and Microsoft (Smooth Streaming). Also the MPEG-DASH standard by the MPEG group is already supported by a number of players and streaming providers.
Which should you use?
As I stated in the beginning, which type of streaming you use depends entirely on what you want to do and who is watching your videos.
If you’re only streaming to desktop users, and copyright security isn’t a concern then perhaps using simple progressive download will be fine. No servers, protocols (other than HTTP like the rest of your website), monitoring or control needed.
If you’re streaming to all sorts of devices, or if security is a major concern then you’ll want to use one of the other two streaming methods. Which one will work best for you depends again on your particular situation. Though the move toward adaptive streaming is gaining momentum. The ability to monitor and adjust the video bitrates as people move about in various network conditions (especially on mobiles) offers tremendous benefits to both the viewer and the content creator (who presumably wants the viewer to actually see the video and not give up in frustration).
Which type of streaming do you use and why do you use it? Please share with us in the comments.