One of Red5’s goals was to bring a Flash server to the Flash masses, and in doing so, we delivered something that does the sexy stuff you’d expect from a streaming server but also has a ton of power in a Java server, and what that brings to the equation is extensibility. Just think about it: Red5 now gives Flash developers an open door to whatever they can attach to a Java server. Imagine being able to talk to hardware devices you normally can’t, like MIDI devices! Red5 makes this now possible.
In this topic, I’ll cover the simple sexy stuff that everyone loves to try, and all you’ll need is the Flash 8 IDE (or greater) and a running installation of Red5. Then, I’ll show you a nice MIDI example with a guitar-teaching tool in which you’ll look at the server side for the first time, where you can connect with hardware on a computer that is MIDI capable. And finally, you’ll look at a Flex 2/3 example to finish things up. The Eclipse setup is especially nice because of the debugging capabilities that it gives you with Red5. At the time of the writing of this topic, this is not possible with Flash Media Server. So, developing your server-side applications becomes far easier because you can use debug tools you’re accustomed to when building applications.
Simple samples
The simple samples ship with Red5’s installer, and you’ll find them in the SWF folder wherever you installed Red5. We’ve kept them “simple” because of user requests primarily. We found that giving examples in Flash FLA files were far easier for people to appreciate immediately, so we’ve provided seven samples for your Flash enjoyment. All samples are ActionScript 2/Flash 8 compatible to reach the largest audience possible, but they can be ported to Action Script 3 very easily if required. Since there is overlap in some of the samples, as far as ActionScript concepts and code are concerned, I’ll be covering only some of the samples here.
Red5 supports both AMF 1 and AMF 3. AMF stands for Action Message Format, and you can find out more about it at http://osflash.org/documentation/amf. In short,
AMF allows you to pass primitive Flash objects, such as arrays and objects, from server to SWF, from SWF to server, and from SWF to SWF.
Before we dive in, it’s good to note that the Flash client-side API remains the same as what you’d use with any Flash streaming server technologies, such as Flash Media Server. So, there’s already tons of documentation and support for developing applications on the client side. All of the samples I’ll cover in this topic use the same NetConnection object to connect to the locally installed and running Red5 server and the same oflaDemo application:
Why the name of laDemo? Open Source Flash (OFLA) was an online virtual conference held in the fall of 2005 where I first showed video broadcasting and recording. The name of the app that I used for this demo was named after the conference, and it has stuck ever since.
Exploring SimpleBallDemo
SimpleBallDemo is the classic demo that shows you the value and use of shared objects and shows you how to synchronize data across Flash clients with a “push” ability. When the shared object on the server is updated, all the clients are notified with the new values associated with that shared object.
What is a shared object? Well, if you’re an ActionScripter, then you’re familiar with what an object is. Now imagine that object being maintained and available on the server side that all clients have access to read from and write to. When a client changes a value on the shared object, the server notifies and pushes the latest changes to the client. So, that’s why it’s called a shared object. Let’s move on.
What’s the difference between the SharedObject that I use to store data on the client’s machine (the one that acts like a cookie for Flash) and this SharedObject that is used in Red5? Great question! The SharedObject that we use with Red5 is often referred to as a remote SharedObject, because it is stored remotely on the server instead of on the client’s machine. They are both actually the same class; the difference is just in how you use them.
SimpleBallDemo allows you to open two SWFs (swfl and swf2, respectively) and then drag the Red5 logo around on swfl to see it move around on swf2. The idea is that you’ll see that when you move the swfl logo, the coordinates are saved to the shared object, and the server pushes those changes to swf2. swf2 gets notified and then moves the logo to the same X/Y coordinate location. This is one of the first demos we created when Red5 first supported SharedObject.
Let’s take a look at the code. Note that it’s very simple; in fact, the comments should explain everything that’s going on here:
By playing with this example, you can quickly see how you can use remote shared objects for so many useful things. How about a text-based chat application or a multiuser game? Later in this topic, I will show you a Flex example that uses the remote SharedObject for a chat application as well as a Flash-based one. Stay tuned!
Shared objects are an easy way to get started sharing data between users connected to the same Red5 server. A popular use of this is for avatar systems where walking, location, friends lists, and chat are big parts of the application. You can accomplish these types of things, in most cases, without even touching a shred of Java code on the server side. These sample applications are the basis for these types of features!
Exploring SimpleBroadcaster and SimpleRecorder
SimpleBroadcaster is your first endeavor into the video features of Red5. You can do three things with video and Red5 out of the box:
■ Stream video
■ Record video
■ Broadcast live video
SimpleBroadcaster is a simple “broadcaster” for live video streams. You can imagine that this has tons of uses, but probably the most notable are video conferencing and video chat applications. Red5 gives you the ability to broadcast your video camera stream to any client that connects and requests your stream. By the way, this just in … that rocks!
Let’s take a look at the code, shall we?
Now, again, if you’re familiar with ActionScript and the NetConnection/NetStream objects, this will be familiar to you and extremely straightforward. But even if this is all new to you, it should still be easy to follow. Take a look at the broadcastClick() method; this is where the magic happens. The NetStream object is where you attach your Camera and Microphone objects. As soon as you call NetStream.publish(), the input from these devices is sent to your Red5 server and made available as a “live” streaming broadcast.
Asyou look at the NetStream.publish(name:String[, type:String]) call, you can easily make out what the arguments mean. The first is the name of your stream and is a String value type. This will be the name, or key, your clients will use to subscribe to your stream. The second argument is the type of stream you’re publishing and is an optional String value. As if it couldn’t get any better, to record your stream, you need to change only the second argument in the NetStream.publish() method to record, and Red5 will record your stream: ns.publish("red5BroadcastDemo", "record");.
Valid values for the type are record, live, and append. record saves an FLV copy of your session, while live (the default value) simply broadcasts your stream to the connected clients. append would be used to do just that—add to a currently recorded stream.
Adobe has really made getting your camera and microphone data very easy with access to static objects called Camera and Microphone:
Armed with connections to those devices and Red5, you can create some of the most sophisticated video applications on the Web!
Exploring SimpleSubscriber
Now that you’ve gone and broadcast a live stream, you’d probably like someone to see it, yes? The SimpleSubscriber demo shows how to do just that, and it’s probably just as simple as you’re assuming it should be. It makes a NetStream.publish call and passes red5BroadcastDemo as the stream name to which it wants to subscribe.
The important part of the code for this demo is the subscribeClick() method:
As you can see, it’s very easy to subscribe to a live stream on Red5. The NetStream object gives you a play() method that allows you to pass the name of the stream. While the NetStream object is hooked up to a video object, you’ll be able to see the live stream broadcast.
Now, I should probably discuss video quality at this point. You’ll see that the broadcaster’s quality looks great—that’s because it’s uncompressed video captured at your computer. You can take control of the quality of video and audio you send, but as always, it’s a balancing act of quality vs. performance and lag. I won’t go into too much detail about the uses of these properties and best practices, but I will cover what each does in some detail here.
The following is the code for the broadcaster since that’s where the quality is controlled from. You’ll notice a method at the very bottom of the broadcaster code called setupCameraMic.
First, look at Camera.setMode() and its four arguments:
■ Width: int: The default is 160. This is the requested capture width of video.
■ Height : int: The default is 120. This is the requested capture height of video.
■ fps ( frames per second ): Number: The default is 15. This is the requested rate, measured per second, that you want the camera to capture video. I have it at 30 in the demo, which is very optimistic! You should start out with the default, and if you feel you really need to raise it, then make the adjustment. Otherwise, you’re better off letting Flash Player manage this with the favorArea setting. Again, this really depends on your application’s requirements.
■ favorArea:Boolean: The default is true. If the camera of the broadcasting client doesn’t support the specified width, height, and frames per second (fps), then these settings are manipulated to whatever the camera will support. Otherwise, when this is set to true, the width and height will be maintained at the expense of dropping the frame rate. If set to false, the frame rate will be favored.
All three of these parameters are very important and can have a huge impact on your application’s performance. A bigger resolution means more data, as does a higher frame rate. You have to find a balance that suits your application and gives you the quality you want at the bandwidth you can afford.
Next, Camera.setQuality() has two arguments:
■ bandwidth:int: The default is 16384. This is the bytes per second the application will allow in terms of bandwidth. A setting of 0 means Flash Player will maintain the bandwidth necessary to achieve the quality you want.
■ quality: int: The default is 0. A setting between 1 and 100 will determine the amount of compression to apply to each frame that is captured. A setting of 0 means that the quality can vary based on the bandwidth requirement.
With Camera.setQuality, I set bandwidth to 0 and quality to 70. I’m telling Flash Player to maintain quality and use whatever bandwidth is necessary to do so. This might be what you’d do for an application that runs on a LAN only or locally to the user’s computer if you want high-quality recordings or broadcasts.
The last one is Microphone.setRate(), which lets you pass an int value of 5, 8, 11, 22, or 44, which is in KHz. The default value is 8KHz if your sound card supports it. Otherwise, it’s bumped up to 11KHz by Flash Player. For most situations where speech is the type of sound passed, 8KHz or 11KHz will do just fine. If you require more fidelity, then try 22KHz or 44KHz, but as always, this means more bandwidth.
For more information on other methods and properties of the Camera and Microphone objects, refer to the Flash or Flex help files.
