treaming video is a very fashionable buzz phrase these days thanks to the pervasiveness of Internet video (which is, in turn, thanks, largely, to Flash). However, it’s also a widely misused phrase (including when discussing Flash) because the video in question often isn’t streaming at all. There are, in fact, two ways of delivering Flash video?each with its pros and cons. In this article I’ll help you prepare for video delivery by giving you a quick primer on the two most common delivery options.

To reap the full benefit of this article, it’s important to fully parse the difference between actual streaming and a technique called progressive download?an economical advancement over older media downloading options (but which still isn’t streaming).

Progressive Download
Any time you play a Flash video (an FLV) from a local source?perhaps a CD-ROM or kiosk?you are almost certainly using a progressive download approach. In fact, the majority of video used in Flash features progressive download FLVs.

In at least one respect a progressive download is no different from a standard download: The asset is downloaded to your computer (typically to your browser’s cache) for playback. The major difference between the two download types is that a progressive download starts displaying the file during the download process, rather than waiting for the download to complete.

You may be familiar, for example, with progressive JPEGs. This format displays the image almost immediately upon the start of the download, and displays an increasing degree of clarity until the process is finished?usually in three to five stages. The large version of Figure 1 (click the thumbnail to view) shows a progressive JPEG almost completely downloaded. Approximately two-thirds of the way down the image, you can see the remnants of the previous display pass at medium clarity. Only a small portion of the download remains as the last third of the final display pass appears.

Figure 1. Click to view a simulation of a progressive JPEG.

Progressive download FLV files function much the same way. After a buffer period (which is usually a few seconds for shorter videos, and can be user-defined), the video begins to play. During playback, the file continues to download in the background. Aided by the short buffer period, as long as the download pace stays ahead of the playback pace the video will play uninterrupted.

It’s easy, and economical, to use video this way because no special software is needed. A standard web server can make the video available in the same way it does for HTML pages or graphics like the JPEG above. On the downside, the user experience depends largely on the speed of the connection. With slow or faltering connections the playback will recover the buffer and catch up to the download position, which stops playback temporarily. Additionally, since the FLV is downloaded entirely to the user’s machine, content remains in the hands of the user for better or worse.

Streaming
By contrast, true streaming video is delivered by a dedicated server, such as Adobe’s Flash Media Server 2, or LightTPD?both of which I’ll discuss briefly in this article. The server sends the video instantly, and in real time, to the client. As a result, the user need not wait for a buffer to pre-fetch a portion of the video. Furthermore, rather than wait for the video to fully download before navigating through it, a user can immediately jump to any part of a streaming video?including portions that haven’t yet been seen.

Because streaming video is only delivered to users as needed, in small increments, the format is ideal for large numbers of users. Because it doesn’t necessarily transfer the entire file, streaming video reduces the load on the server, whereas progressive download videos are delivered, in their entirety, to every user that can successfully request the file.

Streaming through a dedicated server such as Flash Media Server is an alternative way of delivering FLV video?one in which the FLV files are not cached on the user’s machine. As such, streaming video is preferred for controlled viewing situations such as rights management (pay per view, subscription), version control, etc. It’s also superior for long videos and, where the server supports the feature, live content.

Table 1. Feature Matrix: Progressive Downloads vs. Streaming

	Progressive Download	Streaming
Dedicated server required		*
Local content easier to deliver	*
Easy to create without additional setup	*
Fast start		*
Delay user-defined, typically relative to length of clip	*
Long clips easier to deliver		*
Immediate scrubbing of video possible		*
Video remains on server (more secure)		*
Video downloaded to user’s machine	*
Optimal for server load from many users		*

Client-Side Connection
As you can see, both progressive download and streaming video have their purposes. How does this choice affect your client-side player? Fortunately, scripting your own playback is identical in both methods, save for one line of code. Therefore it makes sense to learn both methods at once. In a future article I’ll discuss how to script a more complete player.

The first step is to create an instance of a video object in your Flash file. This is analogous to turning your TV on. In the upper-right corner of the Library panel in the Flash IDE, use the Library menu to create a new video (see Figure 2). Name it myVideo and select ActionScript-controlled as the only enabled option in the Video Properties dialog (see Figure 3). Drag the video object to the stage and give it an instance name of myVideo. Now you’re ready for the ActionScript.

Figure 2. To script your own video playback, you must first create a video object.

Figure 3. Rather than embed or attach a pre-existing video, allow dynamic asset assignment by making your video object ActionScript-controlled.

The second step is to open a pipeline to the video source by establishing a NetConnection. This is a bit like subscribing to a video-on-demand service. Later you’ll pick which video to watch but, for streaming servers, you need to connect first. Begin by creating the connection object:

var myConnection:NetConnection = new NetConnection();

Using the object you created, connect to the video source with the connect method. This is the most important line of this sample code, when choosing between streaming and progressive download assets. Using Adobe’s Flash Media Server 2 as the server example, you will connect to an RTMP (Real Time Messaging Protocol) stream:

myConnection.connect("rtmp://fmsserver/app");

However, when scripting for progressive download assets, you must tell Flash that you will not be seeking to connect to a server. In this case, use null as the connect parameter instead:

myConnection.connect(null);

The remainder of the connection script is identical for both streaming and progressive download assets. Continue by creating a NetStream object to act in cooperation with your connection. This allows you to pick the video you want to watch.

var myStream:NetStream = new NetStream(myConnection);

Finally, attach the NetStream object to your on-stage video window and play the video of your choice.

myVideo.attachVideo(myStream);myStream.play("video.flv");

While you may want to script additional controller elements, such as a play/pause button, a scrubber, and a volume button, you can now automatically play a video from either local or server addresses. As far as progressive download sources go, you’re essentially finished. When using streaming assets, you will probably want to embellish the server negotiation a bit, which I’ll discuss in a moment. First, however, what are your server options?

Flash Media Server 2
As part of the Flash platform, Adobe’s feature-rich Flash Media Server 2 (formerly Flash Communication Server or “FlashCom”) supports many Flash features, including several not directly related to video. Due to space constraints, I’ll briefly introduce you to FMS here; if there is enough demand, I’ll write a more in-depth look at the application in a future article.

FMS is a dedicated streaming software package that can run on Windows and Linux operating systems. Flash clients written to work with the server establish a persistent connection to FMS for reduced latency and high-performance video streaming. Like most servers, it can accommodate multiple processes, and offers all the benefits of streaming I discussed previously. In addition, it can stream live video sources, and record video input, from a web cam, for example.

FMS also provides a rather robust server-side scripting environment (ActionScript) that allows you to develop server applications boasting a variety of features. It can provide bandwidth detection to direct users to a pre-existing source that is optimized for the detected connection speed, playlist management, ad-insertion, and multiple camera angles or synchronized tracks. It even supports multi-directional, multi-user streaming for video chat, video messaging, and video conferencing applications.

Finally, in addition to the enhanced security of streaming files (such as access control and no client caching of assets) Flash Media Server can deliver assets over SSL and its unique transfer protocol (Adobe’s RTMP, discussed previously) also reduces stream hijacking.

To communicate intelligently with FMS, you can add a variety of supported ActionScript. FMS even comes with its own set of components for rapid application development. A simple example of enhancing your client to work with FMS expands on the previous sample code. By checking the status of your existing connection, you can decode to play your video, or respond with messages indicating a busy server or closed connection.

myConnection.onStatus = function(srvrData) {    if (srvrData.code == "NetConnection.Connect.Success") {    	    // successful connection        var myStream:NetStream = new NetStream(myConnection);        myVideo.attachVideo(myStream);        myStream.play("video.flv");    } else if (srvrData.code == "NetConnection.Connect.Closed") {        // connection closed by user or server        trace("Connection closed.");    } else if (srvrData.code == "NetConnection.Connect.Rejected") {        // connection rejected and killed by server        trace("Server busy. Try again later.");        delete myConnection.onStatus;    } };

All of this robust support comes at a hefty price tag. The server costs $4,500 and the lack of support for anything but Windows and Linux may cause you to look elsewhere. Fortunately, you can let others do the serving for you. Authorized vendors offer the Flash Video Streaming Service (FVSS) which transfers the burden of server purchase and maintenance to paid FMS professionals. Depending on your needs, long-term service may approach and even surpass the expense of owning your own server, but it’s worth investigating for those who are just getting started (see the ‘ Resources‘ sidebar).

What if you don’t need all the rich features that FMS offers? What if you only want to stream FLVs as economically as possible? Is free economical enough? Take a look at the two following basic FLV streaming alternatives

LightTPD
A very exciting, free, open source alternative to FMS is LightTPD. “Lighty,” as it is affectionately known, takes its name from “Light Footprint + HTTP Daemon,” meaning a tiny HTTP server. As its name implies, Lighty can serve much more than FLV files. It is an impressive web server that features load management, CGI and FastCGI support, PHP, Ruby, Python, Perl, URL-rewriting, and more, and is available for Windows, Linux, Mac OS X, and other platforms.

As of version 1.1.4.1, however, Lighty features two optional server modules that are ideal for streaming FLVs. The first, mod_flv_streaming, is specifically dedicated to FLV streaming. This added module enables Lighty to deliver small packets of FLV information to the client with the same “instant on,” interactive punch provided by FMS2. With this alone, you can provide a rewarding playback experience with fast responsive video that can be immediately scrubbed.

If you then add the mod_secdownload module, you can control the security of your streams to prevent deep linking from unauthorized users. This module allows you to encrypt temporary access to a URL that times out at a predetermined time.

Due to space constraints, I’ll leave it to you to use the related resources links to install and use Lighty. Be sure to configure the FLV streaming module and optional mod_secdownload module.

To take advantage of streaming FLVs with Lighty, you’ll need a compatible player configured to work with the server. Think of this as a component created for this purpose, but one which can be dynamically controlled through the URL in the player’s host page. You’ll need to encode your FLV files with metadata, which I’ll discuss at the end of this article.

A nice simple player was created by Stefan Richter (with props to Lee Brimelow) for his PHP FLV streaming solution (discussed in the next section). Lighty’s creator, Jan Kneschke, with the help of Fabian Topfstedt, adapted this player for Lighty.

PHP and ColdFusion Alternatives
If you don’t want to run your own server, even the tiny Lighty server, you can also accomplish this modified type of streaming using server-side scripting middleware. Briefly, a server script sends portions of an FLV when requested, rather than buffering the lead of an FLV and downloading the entire file.

Stefan Richter, a.k.a. FlashComGuru, got me interested in this last winter with his PHP solution. It’s very easy to use and will work on any server with PHP support. It also comes complete with a sample player along with the PHP code. Richter cites Brian Bailey’s blogging on the subject and the chattyfig FlashComm list for getting the ball rolling, which is another testament to the great energy out there in the Flash community.

Subsequently, Steve Savage developed a ColdFusion solution based on Richter’s effort and blogging from Christian Cantrell?more community efforts bearing fruit.

While not as robust as the streaming features provided by Flash Media Server 2, these implementations allow you to fetch portions of an FLV when requested, dramatically improving the responsiveness of the videos and vastly decreasing the load placed on the server. Best of all, they are free. (If you use any of these solutions, consider a donation or a note of thanks to the developers!)

Metadata
The FLV serving solutions discussed in this article require that the FLV files be encoded with metadata. Essentially, the server-side solutions need to be able to send FLV data from the point requested by the client, and in efficient increments. This information is stored in metadata, in the FLV file itself, in the form of keyframe time and position values.

Modern video encoders add this information during the encoding process. Additional tools, including Burak’s great FLV Metadata Injector and Norman Timmler’s flvtool2, can inject the metadata into preexisting FLV files. This information is discussed in detail, including sample source files, in my previous DevX article, “Flash Video: Don’t Forget the Metadata.”

It should also be noted that new FLV streaming alternatives are being developed that may not rely on metadata. One example is XProjects’s xAsset PHP module. It is still in beta, I have not tested it, and it’s unclear whether or not it is free. Metadata is a good thing and, with modern encoders doing this work for you, it’s not difficult to add. However, you may wish to learn more about xAsset and other solutions that may exist if you have a large library of older FLV files.

What’s Next
The next installment of this video series will expand on the ActionScript in this article. In addition to connecting to your choice of streaming or progressive download assets, you will be able to script a feature-rich video controller.

Please let me know if you found this overview helpful, if you have any interest in additional coverage of the Flash Media Server, or if you have any questions about the alternatives discussed herein. Finally, as usual, let me know if you put this information to work for you. I’d like to see the results!