HTTP Dynamic Streaming with Flash Access protection

- Requirements

Prerequisite knowledge
You should be generally familiar with principles of streaming video on the web and encoding video for Flash.

User level

Required products
Adobe Access
Flash Media Server (Download trial)
Open Source Media Framework

Sample files (15 KB)


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.


System architecture


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).

Flash Access Server for Protected Streaming

Figure 1. Functional diagram of the Flash Access Server for Protected Streaming (click to enlarge)


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".




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".


OSMF sample player

Figure 2. OSMF sample player


Content preparation


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:
f4fpackager - input-file = sample.f4v - output-path = c: \ sampleoutput


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:
f4fpackager - input-file = sample.f4v - output-path = / sampleoutput


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:
f4fpackager - input-file = sample1_150kbps.f4v - bitrate = 150

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

  1. Repeat encoding for the second file:
f4fpackager - input-file = sample1_700kbps.f4v - manifest-file = sample1_150kbps.f4m - bitrate = 700

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).

  1. 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.

  1. 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:
#offline <input-file> someFile.f4v </ input-file> <content-id> contentId </ content-id> <common-key> commonKey.bin </ common-key> <license-server-url> </ license-server-url> <license-server-cert> licenseServer.der </ license-server-cert> <transport-cert> transportCert.der </ transport-cert> <packager-credential> packagerCredential.pfx </ packager-credential> <credential-pwd> mYpwd </ credential-pwd> <policy-file> policyFile.pol </ policy-file> #offline
  1. Save the configuration file.
  2. Open a console window with the command line.
  3. Execute the command:
f4fpackager - conf-file = f4fpackager_config.xml


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:

<?xml version = "1.0" encoding = "utf-8"?> <manifest xmlns=""> <id> myvideo </ id> <duration> 253 </ duration> <mimeType> video / x-flv </ mimeType> <streamType> recorded </ streamType> <baseURL> "</ baseURL> <drmMetadata url=""/> <bootstrapInfo profile="named" url="/mybootstrapinfo"/> <media url="/myvideo/medium" bitrate="908" width="800" height="600"/> </ Manifest>
<?xml version = "1.0" encoding = "utf-8"?> <manifest xmlns=""> <id> myvideo </ id> <duration> 253 </ duration> <mimeType> video / x-flv </ mimeType> <streamType> recorded </ streamType> <baseURL> "</ baseURL> <drmMetadata url=""/> <bootstrapInfo profile="named" url="/mybootstrapinfo"/> <media url="/myvideo/low" bitrate="408" width="640" height="480"/> <media url="/myvideo/medium" bitrate="908" width="800" height="600"/> <media url="/myvideo/high" bitrate="1708" width="1920" height="1080"/> </ Manifest>


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).


Content delivery


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

  RTMP Dynamic Streaming HTTP progressive download HTTP Dynamic Streaming
Flash Player version Flash Player 6 or later Flash Player 7 or later Flash Player 10.1 or later
Quality of service Measured on bandwidth and performance N/A (often resulting in poor user experience) Measured on bandwidth and performance
Adaptive bit rate Yes No Yes
Publishing workflow Simple Simple Packaging plus manifest file required
Content protection Real time (RTMPe), SWF verification, DRM DRM for VOD only DRM for both live and VOD
Live support Yes No Yes
Live latency Less than 1 sec. * N/A Less than 30 sec. **
Synchronous communication Yes No N/A
Logging Server side No Client side
Cacheable No Yes Yes


*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,
  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,
  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,

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

Structure of the fragmented content

Figure 3. Structure of the fragmented content ( F4F)

  1. 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).


Firebug report showing HTTP Dynamic Streaming content delivery

Figure 4. Firebug report showing HTTP Dynamic Streaming content delivery


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.

  1. 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
  1. 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".


  1. 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.

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


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


License server


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



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:

LicenseServer.LogRoot/ flashaccess-global.log flashaccessserver/ flashaccess-partition.log tenants/ tenantname/ flashaccess-tenant.log


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.


Custom authentication


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 .
<AuthExtensions> <Extension className="com.adobe.flashaccess.server.license.extension.auth.SampleAuthorizer"/> </AuthExtensions>


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

  1. Create an authentication processing class in your development environment. See the next section.
  2. Insert the class into your authentication package; for instance, auth.jar. Your authentication package should be placed in the LicenseServer.ConfigRoot/flashaccessserver/libs directory.
  3. 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).

Figure 5. Click here and insert your figure caption.

  1. Implement authentication logic in the SampleAuthorizer class:
package com.adobe.flashaccess.server.license.extension.auth; import; import; import; import; import org.apache.commons.logging.Log; public class SampleAuthorizer implements IAuthorizer { public SampleAuthorizer() {} public void authorize(IMessageFacade message, IAuthRequestFacade request, IAuthResponseFacade response, IAuthChain chain, Log log) throws Exception { if(message.getAuthToken() != null){ System.out.println(new String(message.getAuthToken())); URLConnection conn = null; DataInputStream dis = null; boolean authValid = false; try { conn = new URL("http://localhost/auth.jsp?" + new String(message.getAuthToken())).openConnection(); conn.setDoOutput(true); conn.setConnectTimeout(10000); conn.setReadTimeout(10000); dis = new DataInputStream(conn.getInputStream()); String inputLine = null; while ((inputLine = dis.readLine()) != null) if(inputLine.equalsIgnoreCase("auth=true")){authValid = true; k;} } catch (IOException e) { } finally{ if(dis != null) dis.close(); } if(authValid){ chain.execute(message); return; } } throw new Exception("AuthToken error"); } @Override public IAuthorizer clone() { return new SampleAuthorizer(); } }


OSMF video player


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.

Sample OSMF-based video player for viewing licensed content

Figure 6. Sample OSMF-based video player for viewing licensed content (click to enlarge)


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:


private function initMediaPlayer (): void { _mediaPlayerSprite = new MediaPlayerSprite (); _mediaPlayerSprite.mediaPlayer.addEventListener (DRMEvent.DRM_STATE_CHANGE, onDRMStateChangeHandler) addChild (_mediaPlayerSprite); }


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:


private function addMedia (m_url: String): void { var _urlResource: URLResource = new URLResource (m_url); var _factory: MediaFactory = new MediaFactory (); var _f4mElement: F4MElement = new F4MElement (_urlResource, new F4MLoader (_factory)); = _f4mElement; }


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):


protected function onDRMStateChangeHandler (evt: DRMEvent): void { switch (evt.drmState) { case DRMState.AUTHENTICATING: break; case DRMState.AUTHENTICATION_COMPLETE: break; case DRMState.AUTHENTICATION_ERROR: break; case DRMState.AUTHENTICATION_NEEDED: _mediaPlayerSprite.mediaPlayer.authenticate ("test", "test"); break; case DRMState.DRM_SYSTEM_UPDATING: break; case DRMState.UNINITIALIZED: break; } }


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.


Where to go from here


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:


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


Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License + Adobe Commercial Rights


This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.