Recently we’ve been inundated with a lot of projects at my workplace that involve flash video, and I expect this trend to only increase as time goes on. This has led to a lot of discussions concerning the differences between streaming video and progressive download and there appears to be a lot of confusion about which is the “best” method.
Figure 1. ABC uses video streaming to deliver full episodes of select programs such as Lost.
I’ve noticed a general perception that streaming video is a magic bullet for delivering high quality video. This perception is incorrect as the benefits of streaming have absolutely nothing to do with the visual quality of the video. In fact, if you implement streaming smartly, the quality of the video will probably be worse for some users.
Chris Hock at Adobe presents a pretty thorough breakdown comparing the two methods of delivering video. His article does a great job of explaining the primary differences between the two methods and is well worth the read. However, there are a few details which I think are important which do not receive much attention. Let me start by summarizing the overall differences in the user experience between the two methods, which should help to shed some light on the video quality issue.
Anyone who’s viewed movie trailers on the Apple website with quicktime has essentially experienced progressive download. The video can start playing when a user arrives at the site. You will see a load bar on the bottom as the video loads. If the playhead beats out the load bar, the video will pause until enough of the video loads to allow the playhead to continue. A user can choose any quality which is offered (e.g., high, medium, low) no matter what bandwidth they have. High bandwidth users will see the videos almost instantly and have no issues watching the video straight through. Low bandwidth users can still choose the high quality video, but they will need to wait for a portion of the video to load before playing, and the video may pause during playback to allow it to continue loading. The important thing to note is that the video quality for the two users, low and high bandwidth, will be exactly the same. The low bandwidth user will simply hit points where they need to wait for loading.
Streaming video is slightly more complicated. If it is implemented correctly, there will be numerous versions of the flash video. Each one should be compressed differently and will target a key bandwidth profile. For example, there could be a small, heavily compressed version for dial-up users and a large, low compression version for broadband users (and perhaps a few versions in between these two). When a user attempts to view streaming video, flash will detect their bandwidth and stream the appropriate video for their connection speed. This means users on a low bandwidth connection will automatically receive a smaller, lower quality video. With streaming video, bandwidth becomes a limiting factor in the video quality. If you try to send high quality video to a low bandwidth user, the experience will be horrendous. In this scenario, the Flash player winds up in a play-pause-rebuffer play-pause-rebuffer cycle which makes the video unwatchable. On the positive side, users should receive a video quality appropriate to their bandwidth which will eliminate load times, which is one of the primary advantage of streaming.
Figure 2. NikeWomen Rockstar Workout uses progressive download to deliver near HD quality video.
The previously mentioned video breakdown article has a very useful table on the last page. This table is a quick overview comparing the differences between the two methods, and I have used this table as a starting point from which to clarify a few details. I have ignored those rows of the table where Adobe indicates that progressive download and streaming are identical, and posted comments concerning those rows where Adobe indicates there are differences.
Adobe indicates that startup time is quicker with streaming video. This may in fact be true. However, I have not found the startup times to be significantly different and I would not factor this into your decision making process.
Adobe’s table indicates that streaming video has superior seek and navigation abilities. This is mostly true, but doesn’t cover the whole story. Adobe’s main point is that progressive video can not seek video segments which have yet to be downloaded, while streaming video can, which is an important factor.
However, if a user is replaying content they’ve already viewed or is jumping forward to content which has already had time to download, progressive download will actually offer a superior user experience. Whenever a streaming video jumps to a different section, it needs to rebuffer. This means every jump to a different segment of streaming video can result in a pause in the video playback. Progressive download allows you to instantly jump to any segment of video which has loaded with no delays and to scrub back and forth across this content, this is not possible with streaming video.
Both streaming and progressive download have their particular advantages and you should base your decision on your needs. If your video is really long, and/or needs to be accessed non-sequentially, you should probably use streaming. If your video is meant to be watched in order, with users only jumping back to replay things they’ve already seen, your content will play just fine with progressive download.
Progressively downloaded videos are stored in the user’s cache. This gives progressive download the previously described superior seek ability once the content is cached. Because streaming video is not cached, any replay or seeking of a different segment will require the player to rebuffer.
With progressive download, you may experience minor performance issues while the browser writes the video to the cache. There can be occasional stuttering which will go away once the video has completely downloaded. This will only occur if viewing a large video on a fast internet connection on low performance machines. I only experienced this issue in our local testing environment where transfer speeds were ridiculously high. The problem cleared up once the video was served from a remote web server.
Felix has brought up a good point in the comments section. For publishers who want to maintain strict control over their content, streaming offers the advantage that it is extremely difficult to save the viewed content locally. With progressive download, a user can simply retrieve the video content from their cache or download it as a file directly from the web server. With streaming video, saving the content locally is much more difficult. The user would probably need to rely on a screen capture application such as Camtasia and would need a fairly high powered machine to do so successfully. For content providers like ABC who could lose revenue from users viewing content outside of their provided venue, streaming is a more appropriate delivery method.*
I can’t really speak to this. Our client’s hosting service was well equipped to handle both streaming and progressive download on a large scale, and we did not notice significant performance differences. Your mileage may vary based on your server infrastructure and I’ll leave this to the IT folks to debate.
I’m not really sure what Adobe means by this, I’m guessing it’s either in reference to the “Seek and Navigation” issue or the “Live Video” capabilites of the streaming server.
If you want live video, you need to stream.
If you need to support Flash 6, you need to stream. Otherwise, this is a non-issue.
There are a few additional differences not listed in the Adobe table which I think are important considerations when implementing a video solution.
Progressive download is easier to setup, and requires no special server side software. If you have access to a web server, you have access to progressive download. Streaming requires special software which needs to be installed on the server.
Streaming requires additional hosting costs, either as a result of purchasing and managing the server software or from additional fees which must be paid to your hosting provider.
My main point in writing this piece was not to argue which method was “better” but to help clarify the situations in which I think each method is the most appropriate. I think the additional costs and complexity associated with streaming video has given it a “premium” aura which has led people to believe it is the best solution for all cases. However, in most of the cases I’ve encountered, progressive download was actually preferable, and should generally be the first option most users should explore. There are special cases which can either only be handled with streaming video, or for which the benefits of streaming really shine. If you are not one of these special cases, you will not reap much benefit from streaming video.
* Added 5 May 2006 based on feedback in comments
** 6 May 2006 - There is another table provided by Adobe (scroll to bottom) which lists out nearly the same conclusions I’ve listed here..
Felix says:
Great summary! I agree that Prog. Download video is often better from a user perspective.
You didn’t mention the main reason content owners go with streaming video, that is the fact that it does not leave a copy of the video in the users cache. This is important for publishers who want to keep control over who can watch their content.
Also, it is possible to seek ahead using PD video, as discussed on this page: http://www.flashcomguru.com/index.cfm/2005/11/2/Streaming-flv-video-via-PHP-take-two Google Video currently uses this method.
Darren says:
Useful and down-to-earth explanation here. I spent 3 months writing up my final MSc project around this subject in 2005 - and of course it was all very quickly out of date!
I was interested to read what you say about web delivery. I use vital stream CDN to deliver flash video and have found that, just for flash, their progressive/download service generally performs better (starts quicker and less buffer) than the true streaming service.
However, i have recently encountered the stuttering issue and a google search landed me on this post. You say “This will only occur if viewing a large video on a fast internet connection on low performance machines”. I have several 7-10 min video clips (15-20MB .flv files encoded for delivery over a 300k connection) and have used several machines of varying specifications with connection speeds of between 1.5MB and 3MB and i constantly get this stuttering issue on them all. It certainly seems to be a cache issue though as once the video has downloaded(or part downloaded) the stutter disappears. If i clear the video out of cache and try again the stutter is back.
Since you wrote this article have you found any ways to address this issue? If ity is that standard desktops are fialing to write to cache as the delivery is flooding in (due to the fast connection and vitalstreams fast network/servers)then maybe i should switch to delivery from a standard webserver instead of paying for fast(er) delivery from Vitalstream??
Noel says:
Darren,
I only experienced the stuttering issue when testing on our local development machine. Once we pushed our work over to our external testing server, the stuttering cleared up.
The only noticeable difference between the two servers was the download speed, and it seemed clear from the overall performance of the machine that it was likely due to the volume of data. We do not have the capability to definitively confirm this (I would leave that to Adobe), but it seemed a reasonable explanation.
I haven’t spent any additional time on this issue because it cleared up once our work was in the wild. It’s interesting to hear that other people are encountering this problem as well, but unfortunately I don’t have any answers as to how to go about fixing it.
It may be that Vitalstream has a way to throttle down the download speed, but I can see how this could be counter to the point of using such a service. There might be other advantages to using a service like Vitalstream besides overall file download speed (network edge delivery?), but I’m not entirely familiar with their offering.
Dan says:
Have you had any experience with the ability to “jump” to any part of a progressive flv using servers such as lighttpd? The ability to skip around to the end is no longer a limitation of progressive flvs. I’m curious how much cheaper it would be from a bandwidth perspective. What’s the average cost for bandwidth for a streaming server(Akamai) versus regular bandwidth.
Noel says:
I have not used lighttpd, so I’m not in any position to comment about it.
Felix posted a link earlier for a PHP solution for skipping ahead with progressive video. However, the example on that site does not behave in a way that I would classify as progressive download, it seems more like a rough streaming server implementation.
Our client’s traffic is delivered through Akamai. As mentioned, we did not take advantage of their streaming service. The relationship with Akamai was managed through our client’s internal IT department, so I do not have any insight into the actual cost beyond being told that it would be much more expensive.
bpk says:
where exactly does a progressive download method stores videos?
Noel says:
bpk,
One of the big advantages of using progressive download is the simplicity of setting it up. Progressively downloaded videos can reside on your web server in the same manner as all of your other web files (e.g., HTML, JPGs).
bpk says:
sorry, i meant if a user is to view videos using progressive download, will they have the option to download it?
and can streaming media software be installed in a normal web server?
bpk says:
and can streaming be used on a local host?
Mathis says:
Very good summary, thank you.
One thing I missed: differences in the protocols. If you use streaming delivery you rely on RTMP, while progressive download can use simple HTTP. While RTMP can easily be blocked by protocol-sensitive firewalls, HTTP is usually allowed to pass.
bpk says:
sorry i have so many questions.
just need to clarify a few things for my project.
how exactly does nike implement the progressive download method where users cant download the file?
Nathan de Vries says:
@Mathis: You can tunnel RTMP over port 80 (HTTP) or 443 (HTTPS) if you’re not behind a stateful firewall. This will get around port-restricting firewall configurations.
With regards to jumping backwards and forwards within progressively downloaded FLV videos, it’s only possible to jump to what’s called a “key frame”.
Key frames describe the entirety of the information required to display the frame, as opposed to an intra-frame which just stores the differences between itself and the last frame (I’m simplifying things, of course). It’s not a simple matter of just increasing the number of key frames, however, because when you squeeze more data into your frames and maintain the same bitrate, you won’t be able to store as much in each frame.
This means that given that same bitrate, two videos - one with many key frames maximum seek-ability, and one with few key frames - will be clearly clearly distinguished by image quality.
Richie says:
I am having the stuttering video problem with the progressive download of flash video. It never stutters from my connection, which is a slower satellite, but from faster DSL and Cable connections it always does. I spoke to my server host and they say I need to upgrade to a dedicated server. Does this sound correct to anyone?
Richie says:
update: Changing the buffer time in the parameters of the FLVPlayback to 3 from default .01 and re-plublishing the swf seems to have solved the stutter problem.
Bonal Samreth says:
Excellent writeup.
If possible, what is the best method, without the use of a dedicated streaming service or server, to provide a 50 mb flash video off a website? I’ve done HTTP streaming with flv videos smaller than 3 mb and that performs just fine; with the larger size, it just hangs. I had good success using the Real Media format (40-50 mb) with HTTP streaming but would like to implement flash video with other contents.
rachmad budi hariono says:
haw a can download flash video streming
ecards says:
You wrote this in 2006 and it’s still very useful and relevant in 2008, thank you.
Surprisingly there are *tons* of places on the web that attempt to clarify this and most are out of date or less complete.
regards,
ltg
Monty says:
Is a six minute flash video with progressive download likely to take too long to begin playing, because the video is so long?
Noel says:
The length of the video shouldn’t affect the start time of the playback.
richard westin says:
What is the longest FLV file one can realistically put on a server to distribute streaming video of FLV files? I am interested in videos that may run several hours.
isabella219 says:
i know Moyea flash video server,it provides services of streaming Flash videos and audios between the server side and client side.
http://www.flvsoft.com/
marin says:
First, great article…like another poster said even if it’s 2008 now.
Second, I’m very surprised that with all the demand for watching a putting videos online there is still a lot of confusion and uncertainty.
There are 2 years now that I own an internet radio and with streaming audio we never had any real problems, except of the initial setup. but with streaming videos it is getting complicated.
Now we are putting on the site video animations that we make, but we’re having a lot of problems from the user part. First we used progressive download but then just for testing, we’re using streaming right now(i always think that real feedback is worth more than books), but we keep on getting emails from people that they cannot see the videos…or they can at home but not at their workplace…or they can with opera but not with IE(like always) but mostly I guess it’s a problem of firewalls. Things that were not an issue with progressive download.
The bottom line of this topic in my opinion, is that USERS MUST SEE THE VIDEOS. While everybody is trying to focus on bandwidth, dedicated servers, statistics and stuff…it’s worth nothing if the user cannot watch them. From my and our experience, comes out that the majority of users are at “monkey” level…they don’t even know how to disable a popup blocker.
So I think that the best choice would be keeping the users as a priority and start from that.
PS: as much as I love linux we had to switch to a windows media server since 90% of our users were in love with media player.
THANKS FOR THE ARTICLE AGAIN
Vino says:
Can someone please help me out with the following. I am doing a research on progressive download technology and would like some help.
Need to do research on progressive download technology in mobile devices
Can Progressive Download technology used in Mobile Media Player and how can it be done?
Thanks
Ulla says:
Wow, Vino: Exactly same question I have! Have you got any answers yet?
Vino says:
No luck yet.
Ulla, do you know the type of protocol used in general for progressive download technology?
jakeonfire says:
Vino, usually HTTP.
Tash says:
Hi,
I was wondering if you know of anyway that you can stop streaming video from being shared by copying the link of the webpage it can be found on?
I am looking at starting up a website involving videos that users have to pay to “download” or “stream” but want to minimise the opportunities for them to share the videos they have paid for with other people (ie emailing the link for the streaming file or uploading the downloaded file to free sites such as youtube). Is there a way of doing this?
Cheers