User level
The Adobe Flash Media Server family of products provides the rich media delivery platform of choice that reaches more people, securely and efficiently, than any other technology. From user-generated content to movies and television shows to corporate training, Flash Media Server (FMS) offers enterprise-level solutions to deliver content and communications.
To help you better understand the streaming functionality of FMS, this article explains the overall FMS server architecture and protocols. It also lists the supported media file types and discusses the differences between the various delivery methods available.

Flash media communication protocol: RTMP
Flash Media Server solutions have both a server-side and a client-side architecture. The client experience is deployed as a SWF or Adobe AIR file created in either Adobe Flash or Adobe Flex. Clients run within a web browser (Flash Player), mobile device (Flash Lite 3), or as a desktop application (Adobe AIR). A client could also be another Flash Media Server, Adobe ColdFusion 8, Adobe Flash Media Live Encoder, or licensed third-party technology that can stream or communicate with Flash Media Server. The server manages client connections and security, reads and writes to the server's file system, and performs other tasks.
The client is the initiator of the connection to the server. Once connected, the client can communicate with the server and with other connected clients. Clients connect to instances of applications; for example, a chat application may have many rooms. Each room is an instance of the chat application. Multiple instances of an application can be running simultaneously. Each application instance has its own unique name and provides unique resources to its connected clients.
Flash Media Server communicates with its clients using the Adobe patented, Real-Time Messaging Protocol (RTMP) over TCP that manages a two-way connection, allowing the server to send and receive video, audio, and data between client and server (see Figure 1). In FMS 3, you also have the option to utilize stronger stream security with encrypted RTMP (RTMPE). RTMPE is easy to deploy and faster than utilizing SSL for stream encryption. RTMPE is just one of the robust new security features in FMS 3. (This will be discussed more in the following sections.)
Flash media server client/server architecture
Figure 1. Flash media server client/server architecture
There are five configurations of RTMP with FMS 3:
● RTMP: This is the standard, unencrypted Real-Time Messaging Protocol. The default port is 1935; if a port is not specified, the client will attempt to connect to ports in the following order: 1935, 443, and then via RTMPT on port 80. Port 1935 is a registered IANA port.
● RTMPT: This protocol is RTMP "tunneled" over HTTP; this means that the RTMP data is encapsulated as valid HTTP data. The default port is 80.
● RTMPS: This protocol is RTMP sent over a secure socket layer (SSL). SSL is a protocol that enables secure TCP/IP connections. (FMS natively supports both incoming and outgoing SSL connections.) The default port is 443.
● RTMPE: This new protocol is an enhanced and encrypted version of RTMP. RTMPE is faster than SSL and does not require certificate management as SSL does. If you specify RTMPE without explicitly specifying a port, Flash Player scans ports just as it does with standard RTMP, in the following order: 1935, 443, 80, and 80 (RTMPTE) (supported with Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player).
● RTMPTE: Flash Media Server 3 introduces this enhanced version of the RTMP protocol which encrypts the communication channel, tunneling over HTTP. The default port is 80 (supported with Flash Player 9,0,115,0 minimum; Adobe AIR; Adobe Media Player). The key benefits over SSL (RTMPS) are performance, ease of implementation, and limited impact on server capacity.
Utilizing the appropriate RTMP type, FMS can send streams through all but the most restrictive firewalls, and protect rights-managed or sensitive content from piracy.

Supported file types
Flash Media Server 3 is completely backwards-compatible with Flash Player 6 or later, Adobe AIR, and Flash Lite 3 clients. Additional formats and features are supported with newer versions of Flash Player (see Table 1). FMS 3 continues support for FLV and MP3 media and AMF 0 for data messaging. Combined with Flash Player 9,0,115,0, FMS 3 now expands support for an industry-standard digital video format, MPEG-4.

Table 1. File formats supported by Flash Media Server 3

Format Type Container Flash Player minimum Usual codec pairing
Sorenson Spark Video FLV 6, 7, 8, 9+ Nellymoser / MP3
On2 VP6 Video FLV 8, 9+
Flash Lite 3
Nellymoser / MP4
H.264* Video MPEG-4: MP4, M4V, F4V, 3GPP 9,0,115,0+ AAC+ / MP3
Nellymoser Audio FLV 6+ Spark / On2
MP3 Audio MP3 6+
Flash Lite 3
Spark / On2
AAC+ / HE-AAC / AAC v1 / AAC v2 Audio MPEG-4: MP4, M4V, F4V, 3GPP 9,0,115,0+ H.264
AMF 0 Data   6, 7, 8, 9+
Flash Lite 3
AMF 3 Data   8, 9+  

H.264 playback in Flash Player supports most popular profiles including Base, Main, and HiP. The F4V format will be a new format moving forward that is a subset of MPEG-4 ISO 14496-10 and AAC+ (ISO 14496-3). For more information on H.264/AAC support, see the Flash Player 9 Update FAQ.
To use H.264/AAC in Flash without any ActionScript, the updated FLVPlayback component will be required and is available as an update to Flash CS3 Professional. This update will also be required to use enhanced RTMP (RTMPE). Without the FLVPlayback component, developers will use ActionScript 1.0, 2.0, or 3.0 to create experiences with H.264.
Streaming vs. HTTP delivery
When determining a method of delivery for video over the Internet in the Adobe Flash Player, you have three choices:
  • Embedded video
  • Progressive download
  • Streaming
Embedded video is rarely used except in very specialized applications with low-quality, short video clips, so I'll just discuss streaming vs. progressive here.
In both progressive and streaming delivery, the video content is kept external to the SWF file. To deploy to the web, the SWF file and the video file would both be uploaded to a server.
Keeping the video external and separate offers a number of benefits over the embedded video method, including:
  • Easy to update and accommodate dynamic content: It's relatively easy to add or change content independent of the video player and without the need to republish the SWF file.
  • Small SWF file size: Your SWF file can remain very small for fast page loads; then the video can be delivered when the user requests it.
  • Better performance: Because the FLV and SWF files are separate, the viewer will have a better playback experience.
Note: Although the focus in this section is on the delivery of video files, the same methods can be used to deliver audio files. In other words, audio files can also be embedded, progressively downloaded, or streamed.
Progressive download video delivery
Since Flash MX 2004, progressive download has been supported for video delivery. This method allows developers to load external video files into a Flash or Flex interface and play them back during runtime. This can be accomplished using ActionScript commands with the Video object or playback components, or by setting parameters for the playback components in the authoring environment (see Figure 2).
Parameters set for an FLVPlayback component to STREAM an external video file into a SWF
Figure 2. Parameters set for an FLVPlayback component to STREAM an external video file into a SWF
When the video is played, the video file first begins to download to the viewer's hard drive, then playback starts. The video will begin to play when enough of it has downloaded to the viewer's hard drive. The file is served from a standard web server through an HTTP request, just like a normal web page or any other downloadable document.
In comparison to streaming video, there's really only one consistent benefit to progressive download—you don't need a streaming server to deliver the video. Progressive download video can be served from any normal web server.
While this can be convenient and potentially cost-effective, the following potential issues should be noted:
  • There are limited seek and navigation capabilities
  • Viewers can access and repurpose content
Progressive download is a perfect use for hobbyists or websites that have low traffic requirements, don't mind if their content is cached on the viewer's computer, and only need to deliver shorter length videos (under 10 minutes). Customers who need advanced features and control over their video delivery, and/or those who need to display video to larger audiences (e.g. several hundred simultaneous viewers), need to track and report usage or viewing statistics for the video, or want to offer the best interactive playback experience, will need to stream their video. Streaming delivery also consumes less bandwidth than progressive delivery, because only the portion of the video that is watched is actually delivered.
Streaming video delivery
When you use streaming delivery, as is the case with progressive download, the video files are kept external to the other content. Developers can use ActionScript commands (and parameter settings with media components) to load external video files into a SWF and play them back at runtime. In fact, the ActionScript code needed for streaming is almost identical to that for progressive download.
This is where the similarities between progressive download and streaming delivery end. In the case of streaming video, each client opens a persistent connection to the streaming server, and the server streams the video bits to the client. Those bits are displayed by the viewer and then immediately discarded.
This tight connection between the server and the client, and the server's ability to precisely control and deliver any portion of a stream as requested, enables the developer to take advantage of some advanced capabilities. These include the following:
  • Determining the client bandwidth and serving a stream with an appropriate bitrate.
  • Measuring and tracking the stream's quality of delivery and switching to a lower (or higher) bitrate stream if needed—if network congestion increases, for example.
  • Automatically generating thumbnails or play short previews of your video clip without having to create separate image or video clips, and without downloading the entire video in the background.
  • Automatically creating "chapters" (with appropriate thumbnails) that can be used for navigation of longer videos, without having to break the video up into smaller files.
  • The ability to seamlessly switch mid-stream from one camera angle, or one stream to another.
  • The ability to "edit" video clips together to create one continuous video for playback. For example, playing the first 10 seconds of clip 1, followed by the content between the 30- and 40-second marks of clip 2, followed by the last 20 seconds of clip 3.
  • The ability to webcast live or recorded events where all viewers see the same thing at the same time.
If progressive download is a "dumb" method of video delivery with very little control—it's basically a simple HTTP download call—then streaming is a very "smart" method of media delivery that enables publishers to control every aspect of the video experience.
Why streaming is better
The advantages of streaming video from Flash Media Server are numerous:
  • Fast start: Streaming video is the fastest way to start playing any video on the web.
  • Advanced video control: Features such as bandwidth detection, quality-of-service monitoring, automatic thumbnail creation, server-side playlists, and more.
  • Efficient use of network resources: Customers who pay for their video hosting or bandwidth by the amount that is transferred will benefit from streaming video, since only the bits that the client actually views are transferred.
  • Secure, protected media delivery: Because the media data is not saved to the client's cache when streamed, viewers can't retrieve the video or audio file from their temporary Internet files folder. There are also additional security features in FMS 3 that prevent stream ripping and other risks to your file's security. Refer to the article, Scaling and securing streaming media applications with Flash Media Server 3, for more details.
  • Minimal use of client resources: Resources such as memory and disk space are significantly reduced with streaming, because the clients do not need to download and store the entire file.
  • Tracking, reporting, and logging capabilities: Because progressive download is just a download of a file, you can't easily log specific relevant statistics such as how long the video was viewed; if the user navigated forward, backward, or paused the video; how many times the viewer played the video; if the viewer left the web page before the video completed playing, etc. Streaming enables you to easily capture this important data.
  • Full seek and navigation: Viewers can immediately seek to any point in the video and have it start playing immediately from that point. This makes streaming a great solution for longer-playing videos or applications such as video blogging, classroom lectures, and conference sessions, where you may want to jump into the video at a specific point rather than requiring the viewer to watch it from the beginning.
  • Deep interactivity: The precise control found in streaming enables developers to create extensive interaction in their video applications. For example, the ability to switch camera angles, have one video spawn another video, or seamlessly switch to alternate endings are all enabled by streaming.
  • Live video: Streaming provides the ability to deliver live video and audio from any connected webcam or DV camera, and even directly from some video cards, natively in Flash Player.
  • Video capture and record (FMIS only): In addition to live streaming, Flash Media Server also gives you the ability to record video either in conjunction with the live stream (e.g. for archiving an event) or on its own (e.g. video messaging).
  • Multiuser capabilities (FMIS only): In addition to live one-to-many streaming, Flash Media Server also enables multiuser streaming of audio, video, and data for the creation of video communication applications.
While streaming may be perceived as being more difficult than progressive download, they're actually extremely similar—they both use the same components and the same ActionScript commands. Streaming just gives the developer more power to create rich, interactive video applications.
The only potential downside to streaming is that it requires special server software. Just as a robust data application would require you to install an application server in addition to your web server, robust media delivery applications require a streaming server in addition to the web server.
Customers with high-volume streaming needs, popular content, or critical uptime requirements who don't want to build their own infrastructure can get the benefits of streaming video in Flash Player by utilizing a Flash Video Streaming Service (FVSS). These Adobe partners offer load-balanced, redundant deployment of FMS over a reliable content delivery network.
When to choose streaming
Streaming with Flash Media Server should be used in any situation where you want or need to do the following:
  • Deliver long files (10 minutes or longer) or high-bitrate files (high-definition)
  • Perform bandwidth detection, delivering the best quality for available hardware
  • Use quality-of-service monitoring
  • Support real-time tracking
  • Provide real-time data sharing and interactivity to your video experiences
  • Stream live video and/or audio
  • Record video and/or audio
  • Serve more streams with less bandwidth
If your website or blog relies heavily on video, audio, or real-time data sharing for delivering your message, you will want to present it in the best possible manner by utilizing the features of Flash Media Server.
Where to go from here
Be sure to read the following articles to learn more about streaming video:
For a summary of the topics presented in this article, the table on the next page compares the three video delivery techniques in Flash.

Video delivery techniques in Flash
  Embedded video Progressive download Streaming delivery
Encoding Video and audio are encoded on import into Flash using the Sorenson Spark or VP6-E codec. Alternately, FLV files (encoded elsewhere) can be imported and placed on the Flash Timeline (re-encoding is not necessary). Video files are encoded in either the built-in or standalone version of Flash Video Encoder, through Flash Video Exporter and a third-party non-linear editing or encoding product, or using a standalone video encoding application such as Sorenson Squeeze or On2 Flix. Same as progressive delivery. In addition, you can capture and record live video feeds from client-side webcams or DV cameras, or using Flash Media Live Encoder, and control live encoding variables such as bitrate, FPS, and video playback size programmatically.
File size SWF files contain both the video and audio streams as well as the Flash interface, resulting in a single, substantially larger file size. SWF and video files are kept separate, resulting in a smaller SWF file size. Same as progressive delivery.
Start time Large SWF files often require users to wait a long time before seeing any video, resulting in a negative user experience. Starts relatively quickly, after enough of the video has downloaded to begin playback. Immediate. The fastest way to go from initial load to actually playing the video.
Timeline access When embedded in the Flash Timeline, video appears on individual frames and can be treated like any other object on the Stage. Video is played back only at runtime. Individual frames are not visible on the Stage. Timeline events can be triggered at selected times during video playback using ActionScript. Same as progressive delivery.
Publishing Each time the SWF is published or tested the entire video file is republished. Changes to video files require manually re-importing the files into the Timeline. Video files are only referenced at runtime. Publishing to the SWF format is much faster than the embedded video approach. Video files can be updated or modified without recompiling the SWF file. Same as progressive video. You can dynamically pull video files from virtual locations, such as your storage area network (SAN) or a Flash Video Streaming Service or other content delivery network (CDN).
Frame rate Video frame rate and SWF movie frame rate must be the same. The video file can have a different frame rate than the SWF file. Same as progressive delivery. Live video capture has programmable control over frame rate.
ActionScript access Video playback and control is achieved by manipulating the movie's playback on the Timeline. The NetStream class can be used to load, play, and pause external FLV files.Seek can also be performed on the portion of the video that has been downloaded. Same as progressive delivery. Server-side ActionScript can also be used to provide additional functionality such as synchronization of streams, server-side playlists, smart delivery adjusted to client connection speed, and more.
Components No video-specific components. Media components (Flash 8 Professional and Flash CS3 Professional) can be used to set up and display external video and audio files together with transport controls (play, pause, seek, etc.). Same as progressive video. Also, you can use Flash Media Server communication components for streaming live and multiway video.
Seek and navigation ability Requires the entire SWF file to be downloaded before user can seek or navigate the video. User can only seek to portions of the video that have been downloaded. Viewer can seek anywhere at any time.
Web delivery The entire SWF file must be downloaded to the client and loaded into memory in order to play back video. Video files are progressively downloaded, cached, and then played from the local disk. The entire video clip need not fit in memory. Video files are streamed from Flash Media Server, displayed on the client's screen, and then discarded from memory in a play-as-you-go method.
Performance Audio and video synch is limited. Sync between audio and video will suffer after approximately 120 seconds of video. Total file duration is limited to available RAM on the playback system. Improved performance over embedded SWF video, with bigger and longer video and reliable audio synchronization. Provides best image quality, which is limited only by the amount of available hard drive space on the playback system. Improved efficiency from a web delivery perspective, with optimal bitrate delivery on an as-needed basis to as many customers as necessary.
Control over the video stream None None Full control over what gets delivered to the clients and when. Advanced access control via server-side ActionScript.
Live video support None None Yes
Compatibility Flash Player 6 and later Flash Player 7 and later Flash Player 6 and later