HTTP Dynamic Streaming with Flash Access protection

Adobe HTTP Dynamic Streaming was developed by Adobe to deliver content to users via HTTP, enabling dynamic switching of video content quality depending on the bandwidth available to the user. It is especially effective when it works together with Adobe Flash Accesss 2.0 to protect valuable assets. This guide gives you step-by-step instructions to get your Flash media video platform up and running.

Here are the main features of HTTP Dynamic Streaming content delivery when used with Flash Access 2.0:

• License management for content playback: no worries about content caching on users' computers.
• HTTP-based delivery of content means there's no need to use other data protocols (such as RTMP or RTMPE). A powerful Content Delivery Network (CDN) provider infrastructure will work for your video delivery.
• Flexible content management during playback means you do not need to download the content completely to start viewing it. Content fragments are cached on the hard drive as playback proceeds.
• Content encryption enables secure HTTP streaming using HTTP port 80.
• Content protection in network storage means content is always encrypted, both during storage and during playback. The content is decrypted block by block from memory cache.
• Support for multi-bitrate streaming "links" encoding of content at different bitrates, enabling quick quality switching upon playback.
• Content protection for streaming to external devices prevents exporting video via the analog ports (S-Video, Component Video) and digital ports (HDMI, DVI, UDI).

These features meet the requirements of most major video content rightsholders, thus enabling you to maintain a broad choice of content at your online resources.

The solution to protect the content and distribute it using Flash Access is intended for the protection of content in multimedia projects using HTTP Dynamic Streaming technology (see Figure 1).

The solution consist of four main modules (content stages):

• Content preparation for web publishing
• Content delivery
• Content protection (licensing)
• Content playback

Content preparation (File Packager for video on demand)

Content preparation includes encoding and encryption using the File Packager tool, which supports the FLV (VP6/MP3) and F4V (H.264/AAC) file formats.

The policies applied at content playback can be managed by the license server, so you can apply the simplest (anonymous) policy of content encryption for HTTP Dynamic Streaming.

For a detailed description, please refer to the section "Content preparation" in this tutorial.

Content delivery (HTTP delivery)

The content encryption process creates three types of files:

• F4Fencrypted content (fragmented) includes all the necessary information to play back the content. An F4F file contains a number of video fragments individually addressable by their own URL.
• F4Ma manifest file contains the content description, DRM description, and license server URL. This is the file that the SWF-based video player will reference to play back the video.
• F4Xindex file includes a description of the fragments for quick navigation.

For caching the video fragments, a CDN or Nginx server can be used.

License server

Adobe Flash Access Server for Protected Streaming is a license server issuing licenses to users and managing content delivery policies. For a detailed description, please refer to the section, "Configuring the Flash Access Server for Protected Streaming".

Playback

To play back the test content, you can use the freely available OSMF player. You'll find a detailed description in the section, "OSMF video player".

Additional tools and modules

To get things working (see the complete picture in Figure 1), you will have to use some additional tools and modules, as follows.

File Packager (f4fpackager) is an Adobe console application that does the following:

• Creates the fragmented video file (F4F)
• Generates the manifest file (F4M)
• Applies the policy (applicable policy file is indicated in the settings)

For a detailed description, please refer to the section, "Content preparation".

For video content encoding, a symmetric block encryption algorithm (Advanced Encryption Standard) is used with a block size of 128 bits and a 128-bit key. This is an encryption standard providing high storage security and content delivery in CDNs.

HTTP Origin Module for Apache handles requests for content fragments. It is included in all versions of Flash Media Server 4, or it can be downloaded from the Adobe website.

A detailed description of content delivery process is given in the section, "HTTP Origin Module operation."

Open Source Media Framework is a reliable and flexible ActionScript framework for rapid development of SWF-based video players. The OSMF sample player (see Figure 2) is designed for HTTP Dynamic Streaming. A detailed description of the player is given in the section, "OSMF video player".

To prepare content for HTTP streaming, you need to use the File Packager, which provides the following:

• Fragmentation (fragmented content preparation)
• Encryption and the association of the file with a policy

Content fragmentation in Windows

To enable content fragmentation in Windows:

1. Open a console window using the command line.
2. Navigate to the directory hosting File Packager (f4fpackager.exe).
3. Enter the following command with parameters:

After the encoding is complete, you get the following files: sampleSeg1.f4f, sample.f4x, and sample.f4m.

Content fragmentation in Linux

To enable content fragmentation in Linux:

1. Open a terminal window.
2. Set LD_LIBRARY_PATH to specify the directory with the File Packager libraries.
3. In the console, type the command and parameters:

After encoding, you get the following files: sampleSeg1.f4f, sample.f4x, and sample.f4m.

Fragmentation of content at several bit rates

This includes encoding of content at several bit rates: for example, 150 kbps, 700 kbps, and 1500 kbps. In this example, three files are encoded at different bitrates: sample1_150kbps.f4v, sample1_700kbps.f4v, and sample1_1500kbps.f4v. In Flash Media Server, these files are located in the directory rootinstall\applications\vod\media.

1. Copy these files into the File Packager directory (for Flash Media Interactive Server 4, File Packager is located in the rootinstall\tools\f4fpackager directory).
2. Open a console window using the command line.
3. Change the directory to rootinstall\tools\f4fpackager.
4. Type the following command with parameters:

After the encoding is complete, you get the following files: sample1_150kbpsSeg1.f4f, sample1_150kbps.f4x, and sample1_150kbps.f4m.

5. Repeat encoding for the second file:

After the encoding is complete, you get the following files: sample1_700kbpsSeg1.f4f, sample1_700kbps.f4x, and sample1_700kbps.f4m.

In addition to details on the current encoding (sample1_700kbps.f4m), the manifest file sample1_700kbps.f4m also contains information about the first encoding (sample1_150kbps.f4m).

6. Repeat encoding for the third file:

After the encoding is complete, you get the following files: sample1_1500kbpsSeg1.f4f, sample1_1500kbps.f4x and sample1_1500kbps.f4m.

In addition to details on the current encoding, the manifest file sample1_1500kbps.f4m contains information about the first encoding (sample1_150kbps.f4m) and the second encoding (sample1_700kbps.f4m). If you encode with multiple bit rates, the information from the first manifest file is copied to the second manifest file, from the second to the third, and so on.

7. To play back multi-bitrate content, open the OSMF player. In the URL field, specify the path to sample1_1500kbps.f4m.

The latest manifest file includes the most up-to-date information on all three files encoded and their different bit rates.

Content encryption

File Packager is designed not only to encode but also to encrypt content. Setting a large number of parameters is much easier using a configuration file:

1. Locate the configuration file f4fpackager_config.xml. By default, f4fpackager_config.xml is located in the same directory as File Packager. Rename it for ease of use. Open it in a text editor.
2. Enter the following settings, changing the bold values to match your scenario:

3. Save the configuration file.
4. Open a console window with the command line.
5. Execute the command:

Here's a description of the parameters:

• input-file is the path to the source video file.
• content-id is a content identifier you select. It's used with the common-key parameter to generate the content encryption key. Keep the same content-id and common-key settings for an entire set of content to make sure that users can decrypt your content set with a single license.
• common-key is a unique 128-bit key (created by the OpenSSL utility) that's used with the content-id to create the encryption key.
• license-server-url is a URL of the Flash Access for Protected Streaming license server. It grants the user license.
• license-server-cert is an encoded license server certificate. It is obtained from Adobe as a result of licensing and never changes.
• transport-cert is an encoded transport certificate (.der). It is obtained from Adobe as a result of licensing and never changes.
• packager-credential is a mandate for encryption of content (. pfx). It is obtained from Adobe as a result of licensing and never changes.
• credential-pwd is a password. It is obtained from Adobe as a result of licensing and never changes.
• policy-file is a policy (. pol). The policy file can be created using the java API or a utility that comes with Flash Access (AdobePolicyManager.jar).

All parameters should contain relative or absolute file paths for the files. For more information on File Packager, see these resources:

• File Packager Reference: This Adobe reference provides a detailed description of the File Packager program and its parameters.
• Protecting Content (PDF): This white paper provides a detailed description of the policy creating process.

Description of files with encoded content

The manifest file (F4M) includes the following:

• Bit rate
• Metadata
• Content protection (DRM) data

Here is an example of the manifest file for content playback:

Here is an example of the manifest file for multi-bitrate content playback:

The content file (F4F) contains fragments of the encrypted content. You'll find more information about F4F files in the white paper, HTTP Dynamic Streaming on the Adobe Flash Platform (PDF).

When your video library is ready to be delivered through HTTP Dynamic Streaming, you are ready to configure your server's HTTP infrastructure. Content delivery is enabled by two main modules:

• HTTP Origin Module: Adobe plug-in for Apache used to retrieve fragments of encrypted video content
• HTTP Cache Module: Any caching HTTP web server you prefer (optional)

HTTP provides a variety of popular tools for load balancing, caching, and efficient content delivery that are applicable to standard web content.

Comparison of delivery methods

Table 1 compares various content delivery methods and their parameters, delineating the benefits of HTTP Dynamic Streaming.

Table 1. Comparing content delivery methods

* Live latency for RTMP may vary depending on network infrastructure and buffer settings.
** Live latency for HTTP Dynamic Streaming may vary depending on encoding, fragmentation, and buffer settings.

One of the most impressive benefits of HTTP Dynamic Streaming is that a user with a very slow Internet connection can pause the playback and wait until the video content is fully downloaded. This way, even users with a narrowband Internet connection can watch high-quality videos without interruption.

You'll find more information about the characteristics of HTTP Dynamic Streaming in the Adobe white paper, HTTP Dynamic Streaming on the Adobe Flash Platform (PDF).

HTTP Origin Module operation

To play back content in an OSMF player, you should specify the URL of the manifest file (F4M). Here is how it works:

1. The OSMF client sends an HTTP request to the Web server; for example, http://www.example.com/media/http_dynamic_Streaming.f4m.
2. The Apache web server sends the request to the HTTP Origin Module.
3. The HTTP Origin Module returns the manifest file (F4M) to the client.
4. The client receives the manifest file (F4M) and uses the bootstrap data to translate the encoding time to the segment # / fragment # format.
5. The client sends a second HTTP request to the Apache Web server and requests a specific content fragment (F4F); for example, http://www.example.com/media/http_dynamic_StreamingSeg1-Frag1.
6. The Apache web server receives the request and transmits it to the HTTP Origin Module.
7. The HTTP Origin Module, using the index file (F4X), defines the offset (in bytes) of the file (F4F) and sends the appropriate Segment1 and Fragment1 to the client; for example, http://www.example.com/media/http_dynamic_StreamingSeg1.f4f.

The fragmented structure of the content (F4F) is shown in Figure 3.

8. The client receives the fragment and plays it back.

Example of fragmented content delivery

As the content is delivered to the user via HTTP, the delivery process can be analyzed using Firefox with the FireBug plugin installed (see Figure 4).

Setting up and configuring Flash Media Server for HTTP Dynamic Streaming

To create an HTTP Dynamic Streaming application, do the following:

1. Install Flash Media Interactive Server 4 or later. This version of the Flash Media Server includes all the required packages, including Apache HTTP Server and HTTP Origin Module.

Setting up the Flash Media Interactive Server 4 for HTTP Dynamic Streaming is described in the white paper, HTTP Dynamic Streaming on the Adobe Flash Platform (PDF). For more general information on FMS setup and configuration, see the Flash Media Server 4.0 Help.

2. Prepare the encoded content (for details, see the section, "Content preparation") and copy it to the directory:

• Windows: C:\Program Files\Adobe\Flash Media Server 4\webroot\vod
• Linux: /opt/adobe/fms/webroot/vod

3. Install the OSMF player. Copy the OSMF player (including the directories \scripts, \images, and \assets) to the root directory:

• Windows: C:\Program Files\Adobe\Flash Media Server 4\webroot
• Linux: /opt/adobe/fms/webroot

Note: If the webroot directory already has the "images" directory, copy the files from the OSMF player's \images directory to webroot\images.

For more details, see the section, "OSMF video player".

4. Open a Web browser and enter the address of the OSMF player. By default, it is http://localhost/OSMFPlayer.html.

Note: The OSMF player requires Flash Player 10.1 or later.

5. Click Eject and enter the address: http://localhost/vod/sample1_1500kbps.f4m
6. Begin to play back the content.

For multi-bitrate streaming, press Q. Press Q– and Q+ to change the content playback bitrate.

To manage digital rights and user access to protected content, Adobe provides Flash Access Server for Protected Streaming. This server issues user licenses to protected content.

Configuring the Flash Access server for protected streaming

Because the policies applied on content playback can be customized by the license server, you can encrypt the content by the simplest (anonymous) policy of content protection.

Flash Access Server for Protected Streaming ignores the policy in the encrypted file itself. Instead, content access parameters and limitations need to be defined on the server side in these configuration files:

• flashaccess-global.xml: global configuration file
• flashaccess-tenant.xml: tenant's configuration file

Directory structure

In the owner's global configuration file, you can specify a full path to flashaccess-tenant.xml or a path relative to the tenant's directory (LicenseServer.ConfigRoot/flashaccessserver/tenants/tenantname).

Tenant's configuration file:

The tenant's configuration file, flashaccess-tenant.xml, provides settings that control access to the tenant's content:

• Transport credential is the transport credentials (certificate and private key). It is provided by Adobe.
• License server credential is the mandate of the server (certificate and private key). It is provided by Adobe.
• Custom authorizers is optional. A custom class to handle authentication when requesting the license.
• List of authorized packagers is optional. Specifies certificates identifying entities authorized to package content for this license server.
• Usage rules:
  • License caching is optional. It determines how long the license will be cached on the user device. By default, caching is disabled. When you enable caching, you need to set the caching end date or define the number of seconds to cache the license. To disable caching, set the cache interval to 0.

    Note: All licenses issued by Flash Access Server for Protected Streaming are valid for no more than 24 hours (86,400 seconds).

  • Output protection is to enable secure output to external devices via the analog or digital ports.
  • AIR and SWF application restrictions is optional. It specifies a list of SWF and AIR applications allowed to view the content.
  • DRM and runtime module restrictions is optional. It defines the minimum level of security. It includes a list of legacy applications that are not allowed to play back the content.

Global configuration file:

The most important settings, such as caching and logging, are configured in the global configuration file, flashaccess-global.xml:

• <Caching>: cache management parameters; for example,

  <Caching refreshDelaySeconds ="..." numTenants ="..."/>

  refreshDelaySeconds determines update frequency. Small interval can affect server performance.
  numTenants is number of tenants of the server.

• <Logging>: specifies the logging level; for example,
  

  <Logging level ="..." rollingFrequency =""/>
level determines the level of logging. If it is set to "DEBUG", it saves quite a lot of messages to the log file. For optimum performance, Adobe recommends setting the value to "WARN". However, there is a risk of losing important information, such as licensing audit data. For minimal logging, set the value to "INFO".
  rollingFrequency specifies how frequently the log files are changed. You can set the value to " MINUTELY ", " HOURLY ", "TWICE- DAILY ", " DAILY ", " WEEKLY ", " MONTHLY ", or " NEVER ".

With Flash Access Server for Protected Streaming, a specific policy is used when playing back the content (the parameters are set in the Flash Access configuration files by default):

• Anonymous access
• License is valid for 24 hours
• License is not cached to the user's computer
• Multiple licenses are ignored
• Restriction on content playback
• User's settings ignored

Logging

Log files are created by Flash Access Server for Protected Streaming and are located in a directory defined as LicenseServer.LogRoot.

Note: If the current log file is deleted or moved on server startup, the server will not create a new log file and the data might be lost in the future.

Directory structure:

Global log file

The global log file flashaccess-global.log is located in a directory defined as LicenseServer.LogRoot. This log file contains messages from the Flash Access SDK and messages generated by the server initialization.

Partition log file

The flashaccess-partition.log configuration file is located in the LicenseServer.LogRoot/flashaccesserver directory. This log file includes messages on requested licenses.

Tenant log file

The configuration file flashaccess-tenant.log islocated in LicenseServer.LogRoot/flashaccesserver/tenants/tenantname.

This log file includes information on each requested license.

Using a custom authentication mechanism implies inserting a special token (AuthenticationToken) into the license request:

1. The user's video player requests a license to play content. The request contains an authentication token.
2. The license server (Flash Access Server for Protected Streaming) receives the request including the token.
3. The license server processes the token, usually with an external web service close to the one that generated the token. That is, working in pair with the token-generating web service—one generates it, the other verifies it.
4. The license server determines whether the token is correct or not.
5. The license server sends a license to the user's video player (or not).

Custom authentication for protected streaming

To enable custom authentication in Flash Access Server for Protected Streaming, you should:

1. Create a policy with a Custom authentication type. Such policies can be created with the Flash Access SDK.
2. Encrypt a file with the policy you've created. (See the "Content encryption" section for step-by-step instructions.)
3. Enable authentication in the configuration file flashaccess-tenant.xml (in the LicenseServer.ConfigRoot/flashaccessserver/tenants/tenantname directory) using a processing class, such as SampleAuthorizer .

For more information, see the white paper, Protecting Content (PDF).

4. Create an authentication processing class in your development environment. See the next section.
5. Insert the class into your authentication package; for instance, auth.jar. Your authentication package should be placed in the LicenseServer.ConfigRoot/flashaccessserver/libs directory.
6. Restart License Server.

Custom authentication class implementation

To implement a custom authentication class, follow these steps:

1. Open your development environment.
2. Create a project. Give it a name, such as HttpDSAuthorizer.
3. Create a class named SampleAuthorizer in the package com.adobe.flashaccess.server.license.extension.auth (see Figure 5).

4. Implement authentication logic in the SampleAuthorizer class:

To play the video content in your application, you should create a Flash Access compliant video player for secure content playback based on OSMF 1.5 (see Figure 6). The source code for the player is given in this article.

During initialization of the video player, create a new instance of the MediaPlayerSprite class. For its mediaPlayer property, set the DRMEvent.DRM_STATE_CHANGE event handler. This means that on DRMEvent , the onDRMStateChangeHandler method is called to analyze the event:

The addMedia method is used to add a new stream to play. This method creates an instance of the URLResource class, and the content URL (for example, http://server_url/content.f4m) is passed to the class constructor. Next, create a new MediaFactory object and an instance of the F4MElement class whose constructor accepts your URLResource, and an instance of the F4MLoader class whose constructor receives the MediaFactory object:

The onDRMStateChangeHandler method is invoked whenever a DRMEvent is raised by the mediaPlayer property of the MediaPlayerSprite class. This method loops through all the events of this type and initiates certain actions when it finds a match. For example, when the RMState.AUTHENTICATION_NEEDED event is raised, this indicates that authentication is required. In this case, authentication is performed as follows:

_mediaPlayerSprite.mediaPlayer.authenticate ("test", "test")

where test is a username and password, respectively.

It should be noted that the authentication function can be implemented so that the username and password play an entirely different role (for example, as web session identifiers):

By using these methods, you can play back DRM content in SWF-based video players.

If you need to pass a token for authentication, you should use the new API in the DRMManager class. The method setAuthenticationToken (serverUrl: String , domain: String , token: ByteArray ): void let you pass any token you have.

For more information, see the ActionScript 3.0 Reference documentation for the DRMManager class.

This tutorial has given you an introduction to using Flash Access to protect content served with HTTP Dynamic Streaming, including building a Flash Access compliant OSMF-based media player.

The resources referenced in this tutorial can provide you with more in-depth knowledge and guidance:

• File Packager reference
• HTTP Dynamic Streaming
• Protecting Content (PDF)
• HTTP Dynamic Streaming on the Adobe Flash Platform (PDF)
• Flash Media Server 4 (Help)
• Flash Access SDK
• ActionScript 3 Reference documentation for the DRMManager class
• Using digital rights management (Help)

Also check out the DENIVIP blog, where we publish useful Flash Platform related content, such as the post, Flash Media Server: URLs tokenization.