One of the most frequently asked questions about delivering video online is – “What’s the difference between streaming video and progressive download?” As a user clicking a video link on a website, you will not often know which delivery method is being used, unless you do some poking around. Although the end result may look the same to the end user, streaming and progressive download are very different delivery methods, each with their own strengths and weaknesses.
Delivering a file via HTTP:
Delivery of a file over HTTP is normally referred to as ‘progressive download’ or ‘http streaming’. In reality, it is not streaming at all but a very simple bulk download of a video file to the end user’s computer. A temporary copy of the video file is then stored on the local computer so that the viewer can watch the file over and over without having to download the file each time.
Let’s assume you have a video file encoded at 500kbps. The server delivering the file does not know or care that your video file is encoded at 500kbps; it simply pushes data to the host machine as quickly as it can. This can sometimes give the illusion that the file is being streamed because playback can start as soon as enough of the file is available on the local machine. This obviously restricts the users from skipping to parts of the file that have not yet been downloaded.
If the bandwidth available to the machine downloading the file is smaller than the encoded bit-rate there may be a wait before the file will start to play. For example, on a 56kbps dial-up modem, trying to play a file that is encoded at 500kbps you may have to wait a fairly long time before enough of the file has been downloaded for it to start playing. On a 500kbps internet connect, or faster, playback should start almost immediately and the file should download faster than it will play, meaning that playback will not have to stop because not enough data has been downloaded.
HTTP(Hypertext transport protocol) operates over TCP(Transport control protocol) which controls the actual transport of the packets over the network. TCP is optimized for guarantee of delivery, regardless of file format or size. If a packet is skipped during the transfer of a file, it will request a resend of that packet. Resend requests take time and bandwidth and could increase the load on the server. TCP is not designed for efficient real time delivery or careful bandwidth control, but for accurate and reliable delivery of every bit.
Delivering from a streaming server:
Effectively, a streaming server is a piece of software which deals with video requests. Unlike a standard web server delivering a video file over HTTP (progressive download), a streaming server opens a conversation with the local machine. There are two sides to this conversation, one is for transferring the video and the other is for control messages between the media player and the server. These control messages include commands such as ‘play’, ‘pause’, ‘stop’ and ‘seek’.
If you have a 56kbps connection, you will not be able to receive a stream encoded at 500kbps; you will have to settle for a lower quality video encoded for 56kbps connections. Streaming does however have many advantages.
- You can begin video playback at any point of the video, or skip through the video as you see fit. This is very convenient for users.
- It makes a lot more efficient use of bandwidth as you are only using bandwidth for part of the video that are actually watched as opposed to HTTP delivery where the whole file gets delivered.
- The video file is not stored on the viewer’s computer – the video data is played and then discarded by the media player. This lets you maintain more control over your content.
Streaming servers use a specific set of protocols to deliver streams, such as RTSP(Real time streaming protocol), RTMP(Real time messaging protocol) and MMS(Microsoft media services). These protocols are all more suited to delivering video streams because they are more focussed with continuous delivery than they are with 100% accuracy. Unlike TCP, they do not send resend requests for missing packets but instead continue with the rest of the video file. The idea is that it is better to have a momentary glitch in audio or video than for the playback to stop altogether and wait for the missing data.
A very nice video to understand it in more details:
In conclusion, both streaming and progressive download have their own benefits and limitations. If you are trying to reach viewers with slower connections and need the quality to be high, progressive download would be your best option. On the other hand, if you know that your viewers will all have a fast enough connection to view your stream, you might save on bandwidth by streaming the video. Without knowing who your video will be served to, progressive download will always be a safer option because no matter what connection they have, they will be able to view your video. For live streaming, a streaming server has to be used. This cannot be done over HTTP.