Anyone who regularly visits Macromedia's Web site has inevitably seen the Red Bull Copilot and Volvo V50 Web sites. These elegantly crafted applications are perfect examples to make the case for Flash video: they combine the rich user experience of a Flash application seamlessly with high quality streaming video.

Macromedia purports Flash video to be a technology that is "outside the box," implying that it can be integrated gracefully with a Web site or Flash application without a stale, uninspired video player surrounding it. Aside from the other major benefits of video in Flash, such as Flash's massive install base and cross-platform compatibility, this point should be well taken. I've used the phrase "Outside the Box" prominently in the title of this article because I believe that this development represents a sea change in the way we deliver media to our users: dynamic, interactive multimedia applications are now possible in a major way. As developers, we get to think in new and exciting ways about how we use Flash and how we deliver media.

On the other hand, although Flash video is definitively "outside the box," it is not necessarily "out of the box," so this article's goal is to familiarize you with the tools and skills you'll need to start developing applications to deliver video with Flash.

About this Article
If you're an intermediate to advanced Flash developer who wants to get his or her feet wet in Flash Communication Server technology, this article is for you. We'll create a simple video player that highlights the key concepts in client-server applications with FlashComm. For the sake of clarity and brevity, I've kept the code minimal. In a more real-world video player, we would want to add features such as dynamic parameters, a resizing video window, a bandwidth tester and multiple bitrate FLVs, and skinning. As we develop the video player, we will create all of the code and assets from scratch and we won't use pre-built components. This will enhance our understanding of how this technology works while also affording us a truly custom application.

Flash Communication Server: Making It All Work
Flash Communication Server MX is Macromedia's application and streaming server, and it's the technology that makes streaming video to a Flash application possible. Much like a Web or FTP server, FlashComm lives on a Windows or Linux box and hosts server applications which communicate with client applications. FlashComm applications are written in Actionscript for Communications, a language which is syntactically equivalent to Actionscript 1.0.

FlashComm and Flash Player communicate through the Real Time Messaging Protocol (RTMP), Macromedia's proprietary protocol for communications. RTMP is used to send audio, video, and data information between the server and client. RTMP, which transmits packets using TCP/IP, is very effective for transferring data as well as streaming audio and video. By default, FlashComm operates on port 1935, but can be configured to run on other ports as well. To skirt the issue of firewalls, the client and server can also communicate using HTTP-tunneling (known as RTMPT), which means that data is cleverly disguised as regular web traffic and sent through port 80, making FlashComm a viable technology for enterprise deployments.

FlashComm isn't just for on-demand video. The rich server side scripting language allows you to develop extremely advanced multi-user applications. Flash Player can encode live video from a Web camera and stream it to the server, which opens up a world of possibilities. Video chat programs, live events, and multi-user games are just a few examples of applications that can be developed with FlashComm. At Stream57, for example, we develop applications for e-learning, live events, video conferencing, and marketing.

Installing Flash Communication Server
To get the full impact of this article, you should have access to a Flash Communication Server to develop on. Although I wouldn't recommend purchasing it straight off (a professional license costs almost $5,000), I do recommend downloading the developer edition for free from Macromedia's Web site. You can download either a Windows or Linux version for your workstation or development machine; make sure to install the updater as well. I run FlashComm on my laptop alongside an IIS Web server without any issues. After installing, take note of two important directories:

The script files for your applications will always go in the "applications" directory, which is usually located at: C:\Program Files\Macromedia\Flash Communication Server MX\applications

FlashComm's XML configuration files go in the "conf" directory, which is usually located at: C:\Program Files\Macromedia\Flash Communication Server MX\conf.

There will also be a Start menu folder for FlashComm, which contains the documentation and administration applications.

The Low-Down on Flash Video
Flash video is a unique format which uses a video codec from Sorenson called "Spark." Flash video lives in FLV files, which can be created using a tool such as Macromedia Video Exporter (in conjunction with a video editing application) or Sorenson Squeeze. To get started with Flash video, you may want to install one of these tools and create some FLVs to stream from your server.

Writing the Server Side Code
First, create a new folder in the FlashComm applications directory called "videoplayer." Within this folder, create a document in a text editor called "main.asc." This will be the main script that makes the videoplayer application run. See Listing 1 for the main.asc code.

Every time a client connects to this application, application.onConnect is called with a reference to the client object passed as a parameter. This basic script for our server side application accepts new connections from client applications and affords us a small amount of security by requiring that the connecting application supply a password.

The application we've created is named "videoplayer" because that is the name of the directory we placed it in. We can also have multiple instances of applications running at the same time that use the same code but do not share properties or streams.

Start up the Communication App Inspector, which can be found in your Start menu. Normally, an application loads on the server only when a client requests it, so we'll start this one manually to make sure it's working correctly. After logging in with the credentials you entered during installation, type "videoplayer/myvideos" into the App/Inst text box and press "load." The "myvideos" instance of the application is loaded. Click on "videoplayer/myvideos" in the Active Application Instances window and press "View Detail." Press "Reload App" to see the output when the application starts. Among other things, you should see "videoplayer application started," which is our trace output from line 2.

Now, let's put some video on the server. You can create an FLV from another video using your editing application and Flash Video Exporter or Sorenson Squeeze, or you can download the sample FLV for this tutorial from www.flashalchemy.com/mxdj. Name your video "myvideo.flv" and place it in the "applications/videoplayer/streams/myvideos" directory (you'll have to create the "streams" and "myvideos" directories yourself.) All video files are housed in the "streams" folder and we place ours in the "myvideo" folder so it's available to the "myvideo" instance of the application.

Writing the Client Side Code
First, we'll create a simple video player that connects to the server and plays the video stream. Create a new document in Flash and size it to 240x180. Select "New Video" from the Library panel options menu (see Figure 1). Drag the new video object from your library to the stage and size it to 240x180. Name this video instance "videoPlayback."

Add the code in Listing 2 to the actions on the first frame of your document. Publish the movie, and you should see the video play within a second or two. The first line of this code creates a new NetConnection object, and the following line connects to the server. The first parameter of the connect call is the URI of the server, which is broken up as protocol://host//appname/appinstance. In our case we're connecting to localhost since we're working on a development machine, but normally you would put the hostname of your production server here.

The NetStream object is what makes the video play, and is instantiated with a reference to the NetConnection object as the only parameter. After we create the NetStream, we call the play method with the name of our FLV as a parameter (the .flv extension is always omitted when playing streams.)

This all seems simple enough, so let's move on and take a look at how a slightly more advanced video player is constructed. You should download the source files for the VideoPlayer application from www.flashalchemy.com/mxdj before continuing.

Examining the VideoPlayer Application
The client side code for the VideoPlayer application is written in ActionScript 2.0, so you'll need Flash MX 2004 or Flash MX 2004 Professional to work with it.

The VideoPlayer application comprises several files. The main VideoPlayer.fla file contains the graphical assets and embedded video object, as well as a line of code that instantiates the VideoPlayer class. The VideoPlayer.as file holds the VideoPlayer class, which does most of the work for the application. Additionally, there is a file called VideoController.as, which controls the user interface elements of the application (such as the slider and play button.) For the purpose of this tutorial, we'll treat the VideoController class as a black box, but you can take a look at the class file if you're curious to see how it works.

Listing 3 shows the connectToServer() method of the VideoPlayer class, which is called from the class constructor. You'll notice that this is a bit more complex than our simple video player; this is because we need to know exactly what's happening as we connect to the server. By overriding the onStatus method of the NetConnection object, we can get valuable information about our connection. The code property of the onStatus information object supplies us with a textual code that represents the status of the connection. In most cases, we hope to get "NetConnection.Connect.Success," which indicates that our connection was successful, but a real-world player should handle errors as well. For a full list of status codes, see the "Client-Side Information Objects" section of the FlashComm documentation.

Listing 4 shows a snippet of the initNetStream() method, which is called after the NetConnection succeeds. You'll see here that we are relying heavily on information object dispatched from the server to control our application. Also take note of the setBufferTime call: this method allows us to control how much media is buffered by the Flash Player before the video playback begins. In our simplified application we set the buffer time to 1 second and hope for the best, but in a production ready application we might fine tune buffering in consideration of users with slow or erratic Internet connections.

More Client-Server Interaction
The bulk of the code in the VideoPlayer application has to do with controlling playback with the VideoController, which allows seeking as well as pausing. Seeking, however, is not as easy at it may seem. To seek to specific points in the video using the slider bar, we'll need to know how long the video we're playing is. We'll also need this information to move the slider handle along as the video playback progresses. However, there is no reliable way to determine the length of the media we're playing without getting some information from the server. To make this work, we'll need to ask the server how long the stream is and wait for a response. This is called a "remote method," and is one of the most important concepts in creating rich client server Flash applications.

For this, we'll need to revisit our main.asc file. Listing 5 shows the new code we'll be adding to main.asc to allow clients to request the length of a stream. Since we're not working in ActionScript 2.0 on the server side, we need to regress to the old days of prototyped classes. Here, we're extending the Client class to have an additional method called "getStreamLength." We get the stream's length by employing the length method of the Stream class, and then return this to the client. The getStreamLength method is now available on any client object that exists in this application, and can be called remotely.

Back on the client side there's still a little more work to do. Listing 6 shows another snippet of the initNetStream() method of our VideoPlayer class, which calls getStreamLength by using the call method of the NetConnection class. The first parameter of the call is the name of the method we want to use. The second parameter is our result object; since this call is asynchronous (doesn't return immediately), Flash needs to know what to do with that result when it is received. The onResult method of our result object will be called with our result as a parameter. In our case, we take the result (which is the length of the stream in seconds) and store it for later use.

Using the VideoPlayer
Now that we've added the appropriate server side code, we can take a look at our VideoPlayer application. Because we changed the main.asc file, you may need to restart the server side application using the Communication App Inspector. If you run the player in the Flash authoring environment, you'll see some useful information in the output window.

I highly recommend examining the rest of the code that comprises the VideoPlayer application to see how it works. If you're feeling daring, you might add some extra features; making the server URI and media name dynamic would be a good start.

Resources
All of the files referenced in the article can be downloaded from: www.flashalchemy.com/mxdj.

Listed below are several resources you may find helpful if you want to learn more about Flash Communication Server. If you need a pre-built, customizable video player, I recommend Giacomo "Peldi" Guilizzoni's open source FLVPlayer, which is also listed below.

• Figure 1
• Figure 2
• Source Code