Adobe MAX Day 1: HTTP Delivery, Flash Player 10.1, Bit Encryption, and More

In Los Angeles today, Adobe will make a series of announcements regarding the "umbrella" of the Flash delivery ecosystem. Three major announcements, all of which will be released in 2010, deal with the ability to deliver content to Adobe's ubiquitous Flash Player.

Flash Player 10.1 Beta
During the keynote, which takes place at 9:30 a.m. Pacific Time, Adobe will unveil a beta of Flash Player 10.1, will finalize some of the features of RTMFP, the real-time peer-to-peer protocol first demonstrated at last year's San Francisco and Milan MAX conferences, as well as the ability to receive HTTP content.

There's been much discussion over the past year about the fate of Flash Lite, Adobe's mobile-only, trimmed-down version of the Flash Player. While we don't yet have confirmation, it appears that Flash Lite will be superseded by this newer version of Flash Player, with the idea that Flash Player can now scale from mobile to embedded devices (set-top boxes) to the desktop.

What we do know is that Flash 10.1 is set to support mobile-centric features such as accelerometer awareness and multiple touch computing. According to a press release, Adobe says its goal with Flash Player 10.1 on a mobile device is to improve rendering and lower memory consumption, while also conserving battery life.

For those who have been waiting for Flash Lite for the Android, Adobe is saying it will make a test version of Flash Player 10.1 for Android and Symbian in early 2010, following the beta release of the desktop version in late 2009. Versions of the beta for Windows Mobile and Palm webOS should also be available within the same timeframe.

If Research in Motion (RIM) integrates Flash, which Adobe has said is in the works, the major gap in the whole mobile computing scenario will be the iPhone, which currently does not allow support for either Flash Lite or Flash Player.

Several weeks ago, Adobe representatives set up a conference call to talk about HTTP delivery and digital rights management (DRM) for content. Currently, Adobe delivers Flash video via RTMP, a proprietary delivery transport protocol. Adobe also offers an encrypted transport protocol, RTMP-E, but does not have a current solution to encrypt the bits once they are delivered.

This combination of a proprietary protocol and lack of bit encryption has been an ongoing concern to premium content owners, and several content delivery networks (CDNs) have made announcements of their own Flash video delivery solutions (Akamai being the most recent in its announcement last week of the Akamai HD Network).

To quickly address these concerns, Adobe is moving on three fronts: First, it is moving to open source RTMP; second, it is offering an HTTP solution; and, third, it is offering a basic DRM solution for bit encryption.

Code-named Zeri, the Adobe version of HTTP technologies will not require the use of Flash Media Server (FMS) which - in the current 3.5 version - does not support HTTP delivery. To use Adobe's Flash bit-encryption DRM solution, however, will require the use of Flash Access 2.0 software.

Flash Access is the rebranding of Flash Media Rights Management Server (FMRMS) and will itself launch in late 2009 or early 2010. As Flash Player 10.1 will be required to support HTTP delivery and bit-encryption DRM, the total solution will not be available until sometime in the first half of 2010. Flash Access will also support SWF file verification and output protection. As mentioned in a previous article, Adobe has chosen to bring the Flash Access technology to market quickly, so the DRM is an internally-developed solution. Adobe says future versions of Flash Access may allow for plugging in additional third-party content encryption solutions.

But what about FMS? We asked that question on the recent conference call and were told that features added to the HTTP delivery solution will find their way in to a later version of Flash Media Server, although an availability date was not provided. Asked for details on these features, we were provided with the following information.

"HTTP solutions will support both live and on-demand content," an Adobe spokesperson said, "with DVR and enhanced seek capabilities, at multiple bitrates, using adaptive bitrate delivery. As we supports all codecs supported by Flash (i.e. VP6/H264), there is no need to re-encode content."

In addition, as Adobe supports the standards-based MP4 file format, the company says it can implement the new HTTP solution across multiple CDNs with no need for customization, and that it will support all protocols including RTMP, HTTP and RTMFP.

So what exactly is this RTMFP, Adobe's newest protocol and addition to the acronym soup? We'll discuss this in more detail in an article later this week, after Adobe's Matthew Kaufman and Michael Thornburgh present a panel on RTMFP late Monday afternoon, but from the details given at last year's Adobe MAX in Milan, RTMFP is geared toward multiple users needing live, real‐time communications for communications. Thornburgh last year demonstrated the ability to drive multiple instances of an RTMFP client on a single device, with each one rebroadcasting the other's live content in a synchronized peer-to-peer solution.

Given the fact that RTMFP moves content between clients, rather than from client to server and then back down to another client, the addition of the protocol calls for an update to the Flash Player. Version 10 of the Flash Player had rudimentary support, but Flash Player 10.1 is expected to have more robust support for RTMFP. One of the most surprising features of RTMFP is the fact that it uses UDP to send packet contents, rather than relying on TCP. The primary reason is that UDP is a more efficient way to send packets, without requiring reporting on the delivery of each packet. In a normal delivery scenario, this would be problematic, but the peer-to-peer nature of RTMFP at some level guarantees the delivery of packets, in much the same way as a satellite IP delivery can rely upon forward error correction (FEC) algorithm to deliver content even if interruptions in service occur.

In other words, the fact that multiple clients are rebroadcasting one another is enough to "blanket" the receiving player. The protocol also contains something called rapid connection restore, which quickly re-establishes connections after brief outages; while this is similar to FEC, it works best in wireless connections where temporary dropouts can occur. Even more interesting is the fact that RTMFP also support the ability for sessions to continue even if a new IP address is assigned to a client device, which opens the possibility for roaming from tower to tower on a data network, even if temporary outages force a change in IP address.

Adobe MAX continues at the Los Angeles Convention Center until October 7, 2009.

Streaming Covers
for qualified subscribers
Subscribe Now Current Issue Past Issues