This post is also available in: Russian

Version-to-version, fans of any software product expect innovations or even dramatic improvements from their favorite package. No doubt this applies to content delivery servers. Well, what users expect from a streaming server today? They want it “to be quick, safe, easy and stream to all devices at once”. In fact, those were the criteria used by Adobe in developing the new version of Flash Media Server 4.5. In this post, we’ll review the main innovations and improvements of the new media server announced a few hours before. You can read the press release here.

First of all, the new product is now supporting 64-bit platforms only. However in the current environment this is not so critical, as not just good software is key to success, but also excellent hardware platform. Still, this is the only “con” of the product. Now let’s look at how Adobe is meeting our expectations. In the new version, Adobe has focused on multi-platform capabilities, especially for mobile and tablet devices. New platforms and classes of devices emerge at enviable regularity, and this cannot be neglected. Users want to get content anytime, anywhere and immediately. In the morning, start watching a movie on your home TV, then continue on your tablet PC on the subway; finally, during the lunch break, see it through on your desktop PC.

Obviously, one of the main innovations is the support of Apple HTTP Live Streaming (HLS). Adobe has implemented HLS support for both Live and VOD content. To deliver content, adaptive bitrate is used. Optionally, the content can also be encrypted with AES-128.

What is the benefit to the users? Now Flash Media Server 4.5 can deliver video to all Apple iOS devices (iPad/iPhone/iPod).

What is the benefit to service developers? Their marketers, for instance, can safely boast of supporting iOS based devices, attracting a larger audience. The engineers of content delivery system have no need to support a bestiary of different media servers or multiple methods of content delivery to i-devices. Since the data is delivered via HTTP, content caching has also become much simpler.

It is also noteworthy that you have no need to prepare content for HLS delivery. As a source, mp4/flv file is used. To encode it, codecs supported by relevant playback devices are used. A playlist (* m3u8) is also generated dynamically.

In online cinema services, content preparation is often an issue. Obviously, this involves certain hardware capacity. Also, it requires additional service redundancy. Further, content protection is needed. This creates another architectural link that also needs redundancy. This results in multiple points of failure throughout the solution, involving additional resources and operating expenses. Adobe took a major step toward streamlining content preparation, not neglecting content protection and enabling delivery to multiple platforms. The new approach can reduce the cost of value-added service creation and make the platform less complex and more stable. However, we should keep in mind that this would not assume times less hardware resources. The average load on content delivery servers will certainly increase. Nevertheless, if you have an efficient caching system, this would not be highly noticeable. Moreover, by expanding the pool of edge delivery servers you can significantly improve the overall system fault-tolerance.

Another new and nice feature is packing content for HTTP Dynamic Streaming (HDS) on the fly. This simplifies content preparation for HDS delivery, completely eliminating pre-packing with f4fpackager. All-in-all, this eliminates a whole link in the content preparation and delivery infrastructure.

These two features combined can eliminate the issue of missing manifests. Previously, when a manifest was lost, it was necessary to re-pack content. Now no such problem exists. FMS 4.5 contains a small application called Adaptive Bitrate File Generator. It helps you create playlists and manifest files for multi-bitrate streaming. Such files are called adaptive bitrate manifests.
What is this for? First of all, it allows you to create a manifest containing bitrate, codec and, optionally, the source which is different for each stream.

The most trivial use of this feature is certainly adaptive streaming and bitrate switching. Having studied the options for input and output data, you can easily build a similar system for your service. This system will generate manifests on the fly and provide them to users.

In this context, one question remains. How should we protect content?
The answer is simple: all the same, on the fly. For this end, HDS/HLS Just In Time modules support on-the-fly content encryption. HDS provides 2 protection options.

The first is the classic option based on Flash Access (FAXS). Actually, in the module settings, we specify mostly the same settings used to encrypt content with f4fpackager.

The second option involves embedding the license in the video stream. By default, FMS provides 2 built-in policies: Unlimited play and 24-hour expired.

Unlimited play – this is an anonymous policy that always allows content playback.

24-hour expired policy is used by default. This policy is also anonymous, but it permits content playback for only 24 hours after the content has been packed.

What does this functionality give us? In emergency situations, e.g. on failure of FA license servers we face a choice: either we can distribute unprotected content (but this could entail severe penalties from major copyright holders) or stop the service until FA is recovered (although this may affect service reputation). This feature allows us to encrypt content in emergency situations (FA failure) and prevent user access to FA. Since the 24-hour policy offers content playback only during the following day, it is no doubt that after FA is installed, the consumers will continue to use the content license. Therefore, you can temporarily switch to a backup content delivery model, while maintaining service efficiency and content protection at a proper level.

Let’s now discuss content encryption with HLS.

It’s all much easier. We have one key, with which we encrypt content on the fly and deliver it to user. The user downloads the key via HTTP and decrypts the content. This is not quite safe, but however that’s all HTTP LS offers. It is for you to decide how to safely deliver the key to the user.

Among additional features, please note a new feature in the embedded livepkgr application. Just to remind you, livepkgr is an application coming with FMS. It allows you to pack Live content on the fly and deliver it via HDS/HLS with an RTMP stream as a source. The application receives several RTMP streams (with different names), groups them as specified in its configuration file and outputs the streams as event groups via HDS/HLS. In the new version, you can generate two streams for the same event, where the second stream is audio-only. In fact, we can now embed an audio track into our live event. That’s what VOD is lacking badly, but hopefully Adobe will come up with something in this area in the near future.

Another interesting innovation is Flash Media Gateway (graduating from the Adobe Labs). It is a brand-new Adobe’s product. It functions as a SIP gateway between Flash player and SIP server (for instance, Asterisk). This offers great opportunities to integrate your applications and increase their interactivity. The most trivial example is a direct SIP call from the Flash application. Unfortunately, this application is currently Windows-only.

Well, that’s perhaps all about the key technical changes and innovations. Finally, let’s mention changes in licensing policy. Now Flash Media Server is licensed per server and not per processor as it was before.

Wishing you success in your content delivery and Web broadcasting projects!