Configure Flash Media Server for optimum performance

Choppy video. No one likes it. To stream video smoothly, start by tuning Flash Media Server for your situation. Are you streaming on-demand (recorded) or live video? If you’re streaming live, which is more important to you, scale (reaching as many people as possible) or latency (the time elapsed between the live event and when the viewer sees the live event)?

In the Configuration and Administration Guide, FMS engineers provide tuning recommendations for on-demand and live streaming:

Progressive download is dead. Long live on-demand HTTP dynamic streaming. Stream FLV/F4V/MP4 files to Flash over HTTP.

When you view content on YouTube, you don’t have to wait for the content to download to skip ahead to the end of the file. Progressive download is dead, this is on-demand HTTP streaming.

Use Adobe HTTP Dynamic Streaming to serve on-demand video over HTTP on your web site.

  1. Download the File Packager
  2. Download the Apache HTTP Origin Module
  3. Install the HTTP Origin Module to Apache HTTP Server 2.2
  4. Use the File Packager off-line tool to package an FLV, F4V, or MP4 file for HTTP streaming.
  5. Copy the packaged files to the Apache webroot folder.
  6. Play the files in Flash Media Playback or OSMF Sample Player for HTTP Dynamic Streaming.

These are the high-level steps, for the nitty-gritty, check out the On-demand HTTP Dynamic Streaming tutorial.

To stream live media over HTTP to Flash/AIR, use Flash Media Server. Check out the Live HTTP Dynamic Streaming tutorial in the FMS Developer’s Guide.

H/W accelerate your video performance: Flash Player 10.2 StageVideo docs are live

Does your Flash Player application feature a video player? And if so, are you looking for a way to improve the video performance?

For several releases, Flash Player has supported GPU hardware acceleration for decoding H.264 videos. However, the rest of the rendering process still required the CPU. Flash Player 10.2 brings hardware acceleration support full circle by introducing the StageVideo API. Stage video lets you apply hardware acceleration to the entire video decoding and rendering process, thus freeing up CPU and memory resources.

A StageVideo API has previously been available only to AIR 2.5 for TV application developers, and through the Flash 10.1 Beta for Google TV. The StageVideo API in Flash Player 10.2 expands on these existing classes. It adds events for handling behavior in a browser context.

To learn how your application can take advantage of this new feature, see the following documentation:

Remote control input handling in AIR for TV apps

And here’s yet another design consideration for AIR for TV applications.  (This and other tips will be incorporated soon into Adobe online documentation).

Users typically interact with your AIR for TV application using a remote control. The good news is that the way you handle remote control key input is the same way you handle key input from a keyboard on a desktop application. Specifically, handle the event KeyboardEvent.KEY_DOWN.

The keys on the remote control map to ActionScript constants. For example, the keys on the directional keypad on a remote control map as follows:

Remote control’s directional keypad key
ActionScript 3.0 constant
Up Keyboard.UP
Down Keyboard.DOWN
Left Keyboard.LEFT
Right Keyboard.RIGHT
OK or Select Keyboard.ENTER

AIR 2.5 added many other Keyboard constants to support remote control input. For a complete list, see the Keyboard class in the ActionScript 3.0 Reference for the Adobe Flash Platform.

To ensure your application works on as many devices as possible, Adobe recommends the following:

  • Use only the directional keypad keys, if possible.

    Different remote control devices have different sets of keys. However, they typically always have the directional keypad keys.

    For example, a remote control for a Blu-ray player does not typically have a “channel up” and “channel down” key. Even keys for play, pause, and stop are not on all remote controls.

  • Use the Menu and Info keys if the application needs more than the directional keypad keys.

    The Menu and Info keys are the next most common keys on remote controls.

  • Consider the frequent usage of universal remote controls.

    Even if you are creating an application for a particular device, realize that many users do not use the remote control that comes with the device. Instead, they use a universal remote control. Also, users do not always program their universal remote control to match all the keys on the device’s remote control. Therefore, using only the most common keys is advisable.

  • Make sure that the user can always escape a situation using one of the directional keypad keys.

    Sometimes your application has a good reason to use a key that is not one of the most common keys on remote controls. Providing an escape route with one of the directional keypad keys makes your application behave gracefully on all devices.

  • Do not require mouse input.

    Obviously, a television doesn’t have a mouse. However, if you are converting desktop applications to run on televisions, make sure that you modify the application to not expect mouse input. These modifications include changes to event handling and changes to instructions to the user. For example, don’t overlook changing an application’s startup screen if it displays text that says “Click to start”.

For more information on key input handling, see Capturing keyboard input in the ActionScript 3.0 Developer’s Guide. Continue reading…

When to set Stage properties

Speaking of setting AIR for TV Stage properties (which I was speaking of in my last blog entry) ….

I was looking at some sample AIR for TV applications written by a member of the AIR for TV engineering team, and was reminded of something interesting. He sets the stage properties in an event handler that handles the ADDED_TO_STAGE event.

Specifically, in the constructor for his main document class, he writes:

addEventListener(Event.ADDED_TO_STAGE, onStage);

Then in his onStage() event handler, he writes:

private function onStage(evt:Event):void
{
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;
//remove event listener
removeEventListener(Event.ADDED_TO_STAGE, onStage);
// And more initializations follow
}

It’s tempting, and seemingly logical, to put the Stage property initializations in the constructor of the main document class. But you should wait until you receive the ADDED_TO_STAGE event.  It is possible in some circumstances for the constructor of the main document class  to execute before the object has been added to the stage.  If that occurs, accessing the object’s stage property results in an exception.

For a display object that is not the main document class, this behavior is more obvious. You create a display object, and then you add it to the stage. Therefore, the object’s constructor always executes before you add the object to the stage.  So setting Stage properties in the constructor is certain to fail in these cases.  So that’s another good reason to always wait to access the stage property of any display object until after you’ve received the ADDED_TO_STAGE event.

This programming tip is not specific, by the way, to AIR for TV applications, but applies to any Flash Player or AIR app.

AIR for TV Stage property settings

In my last blog entry discussing a TV’s safe viewing area, I mentioned the Stage.stageWidth and Stage.stageHeight properties of a full-screen application on a TV with a 1080p screen resolution.  Let’s look a little more at how to set these and other Stage properties with regard to AIR for TV apps.

Stage.stageWidth and Stage.stageHeight

If you are writing a full-screen AIR for TV application for a specific device, go ahead and  hard-code Stage.stageWidth and Stage.stageHeight to the device’s screen resolution. However, to write a full-screen application that runs on multiple devices, use the Capabilities.screenResolutionX and Capabilities.screenResolutionY properties to set your Stage dimensions. For example:

stage.stageWidth = Capabilities.screenResolutionX;
stage.stageHeight = Capabilities.screenResolutionY;

Stage scale mode

Set Stage.scaleMode to StageScaleMode.NO_SCALE, and listen for stage resize events.

stage.scaleMode = StageScaleMode.NO_SCALE;
stage.addEventListener(Event.RESIZE, layoutHandler);

This scale mode setting results in the following:

  • When the application’s window changes size, the stage contents maintain their defined size. The runtime performs no automatic layout or scaling. Also, the runtime dispatches the Stage class’s resize event. Therefore, you have full control over how to adjust the application’s contents when the application begins and when the application window resizes.
  • You can use the stageWidth and stageHeight properties of the Stage class to determine the actual pixel dimensions of the application’s window. Therefore, in full-screen applications, these properties correspond to the screenResolutionX and screenResolutionY properties of the Capabilities class.

Stage alignment

Set Stage.align to StageAlign.TOP_LEFT:

stage.align = StageAlign.TOP_LEFT;

This alignment places the 0,0 coordinate in the upper-left corner of the screen, which is convenient for content placement using ActionScript. Therefore, this alignment works nicely with StageScaleMode.NO_SCALE, since your application is in charge of layout.

Stage display state

Set Stage.displayState in a full-screen AIR for TV application to StageDisplayState.FULL_SCREEN_INTERACTIVE:

stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;

This value sets the AIR application to expand the stage over the entire screen, with user input allowed.

Stage quality

You can set the Stage.quality property for an AIR for TV application to StageQuality.Best or StageQuality.High, specifying the rendering quality for all Stage objects. For example:

stage.quality = StageQuality.High;

AIR for TV applications and the “safe viewing area” (aka “title safe area”)

Here’s another design consideration for AIR for TV applications.  (This and other tips will be incorporated soon into Adobe online documentation).

When designing your user interface for an AIR for TV app, be sure to consider the safe viewing area. The safe viewing area on a TV is the area of the screen that the end-user can actually see. This area is also known as the title safe area. Overscan is the portion of the actual image area that falls outside the safe viewing area. The safe viewing area can vary depending on the device. This concept originated with analog televisions in which the television’s physical design sometimes hid the edges of the displayed image. However, it still often applies today.

Adobe recommends an inset of 7.5% on each edge of the screen. For example, on a TV with a screen resolution of 1080p, a full-screen AIR application has a Stage.stageWidth of 1920 and Stage.stageHeight of 1080. The following figure shows the safe viewing area of the stage using 7.5%:

I’ll leave it to you to do the math for 7.5% for other screen resolutions such as 540p and 720p (stage dimensions of 960 x 540 and 1280 x 720, respectively).

Because of the safe viewing area, design your full-screen AIR for TV application as follows:

  • Use the entire stage dimensions for backgrounds, such as background images or background colors.
  • Use only the safe viewing area for critical application elements such as text, graphics, video, and user interface items such as buttons.

Depending on the device on which your application runs, the safe viewing area sometimes doesn’t apply. But to be sure your critical application elements are never hidden, always design to accommodate the safe viewing area.

Filesystem access in an AIR for TV app

If you are writing or planning to write apps for AIR 2.5 for TV, you’ve probably already been looking at the documents and tutorials on http://www.adobe.com/devnet/devices/flash_platform_tv.html.

More docs are in the works, but in the meantime I thought I’d use this blog to present some of that content.

AIR for TV apps can access the device’s filesystem, but on a “living room” device it is critically important that an app cannot access the device’s system files or the files of other applications installed on the device. Users of TVs and associated devices do not expect or tolerate any device failures — they are watching TV, after all.

Therefore, an AIR for TV application has a limited view of the device’s filesystem. Using ActionScript 3.0, your app can access only the following directories (and their subdirectories). But realize that these names are not the actual directory names on the device. This extra layer protects AIR for TV  applications from maliciously or inadvertently accessing local files that do not belong to them.

  • /app/ is the read-only application directory for the running AIR application.
  • /app-storage/ is the read-write application storage directory for the running AIR application.
  • /home/ is the read-write user directory.
  • /tmp/ is the read-write temporary directory for the running AIR application.
  • /volumes/ is the read-only directory containing zero or more read-write subdirectories that represent mounted volumes.

If an app tries to access any other directory, the runtime throws an exception that the ActionScript code can catch.

As with AIR applications targeting other devices, it’s a best practice to use the following File class properties rather than a directory name:

  • File.applicationDirectory maps to the application’s application-specific directory.  The File.nativePath value of File.applicationDirectory  is /app/ in AIR for TV.
  • File.applicationStorageDirectory maps to an application-specific directory within a user-specific directory.  Its File.nativePath value is /app-storage/ in AIR for TV.
  • File.desktopDirectory maps to an application-specific directory within a user-specific directory.  Its File.nativePath value is /home/ in AIR for TV.
  • File.userDirectory maps to an application-specific directory within a user-specific directory. Its File.nativePath value is /home/ in AIR for TV.
  • File.documentsDirectory maps to an application-specific directory within a user-specific directory. Its File.nativePath value is /home/ in AIR for TV.

Note that File.desktopDirectory, File.userDirectory, and File.documentsDirectory all map to the same directory, which has the File.nativePath value  /home/.

Also consider the behavior of the following methods on AIR for TV devices:

  • File.createTempDirectory() creates a directory with the File.nativePath value /tmp/. AIR for TV maps /tmp/ to a temporary directory on the device. AIR for TV deletes this directory and its contents when the AIR application exits.
  • File.createTempFile() creates a file in the /tmp/ directory.
  • File.getRootDirectories()returns an array with one File object. The File object’s nativePath property has the value /. This root directory contains the directories app, app-storage, home and tmp.
  • StorageVolumeInfo.storageVolumeInfo.getStorageVolumes() returns a Vector of StorageVolume objects. Each StorageVolume object’s rootDirectory property is a File object. The File object’s nativePath value begins with /volumes/. All applications and users have access to the /volumes/ directory.

Stream with the big fish: Flash Media Server is available on Amazon Web Services

Flash Media Enterprise Server 4 is now available on Amazon Web Services:

Use Flash Media Server on Amazon Web Services to create social media games, multicast live events, and deliver streaming video like the pros (think Hulu and mlb.com) for pennies on the hour with no fear of success–when your business takes off, you can stand on the shoulders of Amazon as your grow. You’ll never have to buy or maintain any hardware or software. Ahhhh. Sounds relaxing, right? You pay only the Amazon Web Services $5 monthly charge and pennies an hour for bandwidth and machine time. For more information about pricing and benefits, see the FMS on AWS product page at adobe.com.

The FMS on AWS documentation walks you through setting up an Amazon Web Services account, ordering and launching Flash Media Server, and verifying that the server is running. It also includes the following tutorials:

And yes, you can build P2P apps with FMS on AWS. Start with the Multicast streaming tutorial, then check out Tom Krcha’s P2P game-building tutorials at  flashrealtime.com.

Enjoy!

The StageVideo article for you

If you are developing applications for AIR 2.5 for TV or for Flash Player 10.1 Beta for GoogleTV, be sure to visit this Adobe Developer Connection article to learn about using the StageVideo class:

Delivering video and content for the Flash Platform on TV

But if you are developing applications for Flash Player 10.2 Beta, see this article instead:

Getting started with stage video

The main difference is in the events that get dispatched. Flash Player 10.2 Beta provides the StageVideoAvailabilityEvent, the StageVideoEvent, and the VideoEvent.
AIR 2.5 for TV and Flash Player 10.1 Beta for GoogleTV dispatch only the StageVideoEvent.