First Look: Flash Media Server 4

What's New in FMS 4

Adobe's Flash Media Servers have undergone a radical set of changes in the past few revisions. FMS version 2 offered numerous iterations. But Adobe slimmed down the product line to just two for FMS 3: FMSS and FMIS.

The price points between FMS 2 and FMS 3 also dropped, in part due to competition, to a base $995 for FMSS and $4,995 for FMIS. In FMS 4, the price points are the same for the two lower-end servers. But Adobe adds a third server, FMES, at a cost significantly higher than FMIS-though Adobe declined to say publicly exactly what that price is.

So what do you get for all that extra money? In a word, multicast. But this is not just traditional IP multicasting, which is also available in version 4 of FMIS, but a combination of IP multicasting and what Adobe is calling application multicasting.
Adobe calls this combination Fusion, while others call it peer-to-peer multicasting. Regardless of what it's called, it's a key element of FMES.

Other features available in FMIS and FMES include the integration of HTTP streaming, for both live and on-demand content delivery, and Fast Switching.

HTTP Dynamic Streaming
Those who have followed the advent of HTTP streaming delivery for on-demand content will remember Adobe launched a stand-alone HTTP streaming solution, Project Zeri, a few months ago. Tied in with its adaptive bitrate segmenting solution, Adobe Dynamic Streaming, and the advent of Adobe's stand-alone content protection server (Flash Access 2.0), the premise of Project Zeri was to allow progressive downloads to act like streaming delivery via the use of already prevalent HTTP caches and web accelerators.

"We built in support for all Flash codecs," Kevin Towes, Adobe's Flash Media senior product manager, noted at the release of Project Zeri late last year, "including H.264, VP6, H.263, HE-AAC, VP6, MP3, and all metadata that exists within the formats or live stream. Project Zeri will allow you to stream all the same content regardless if it is live or on-demand with no ... change to your live encoding technology."

The advent of FMS 4 allows for live streaming via HTTP, where the Project Zeri prerelease version had only allowed on-demand content to be segmented into adaptive bitrate segments. In addition, FMS 4 will support both data pipe encryption (via RTMP-E) as well as persistent bit-level encryption, when coupled with the Flash Access 2.0 server.

Fast Switching
Working hand in hand with HTTP streaming and Adobe Dynamic Streaming, FMS 4 introduces the concept of fast switching.
Fast Switching was originally scheduled for FMS 3.5.3. But it was delayed until the advent of FMS 4, in part because the launch of Flash Player 10.1 was required to support Fast Switching on the client's machine. Fast Switching uses newer features within Flash Player 10.1 and FMS 4 to reduce the switching time between adaptive bitrate segments. As users no longer need to wait for the buffer to play through, the decreased switching time means that an end user's Flash Player can more rapidly adjust to changing network conditions, increasing and decreasing quality in a more timely manner, while maintaining an uninterrupted playback experience.

RTMFP or Fusion
Real-Time Media Flow Protocol is a big deal, not just for Adobe but also for the enterprise users at which Adobe is targeting the FMES.

First, let's look at the RTMFP technology and then at possible implementations, including a brief discussion of a prerelease test done by a Fortune 100 organization.

Available in Flash Player 10.1 and AIR 2.0 applications, RTMFP is Adobe's foray into User Datagram Protocol (UDP) transmission of content.

Unlike the more widely used Transmission Control Protocol (TCP) that Adobe's RTMP and many other streaming protocols are based on, UDP is designed to hammer home content with lower latencies.

If TCP and UDP were to star in a good cop/bad cop comedy, TCP would be the kinder, gentler character that serves as a foil to UDP's gruff and overbearing demeanor.

TCP works with other protocols to guarantee the delivery of data, conferring to guarantee that its content has arrived all in one piece, with the option of sending follow-up packets if a few packets went missing along the way. As such, TCP is ideal for data delivery when it comes to data that doesn't need to scale or isn't time-sensitive.

UDP, on the other hand, doesn't play as well with other protocols. And its "take no prisoners" approach means that it gets the content delivered, no matter what other types of content are clogging up the pipe. Still, for wide-ranging or scalable implementations-especially those that require two-way communication-UDP is more effective that TCP.