httpdynamicstreaming_wp_ue

Adobe Flash Platform Technical White Paper

HTTP Dynamic Streaming on the Adobe® Flash® PlatformEnabling high-quality, network-efficient HTTP streaming for media delivery

HTTP Dynamic Streaming enables media distributors to leverage the Internet’s most prevalent protocol to deliver the best adaptive media streaming experience to the largest potential audience across all devices and platforms that support Adobe Flash software. It leverages industry standards and open technology to support high-capacity, cacheable, and protected media delivery.

The MP4 fragment format, F4F, is used for both live and on-demand streaming with full support for the high-quality media codecs available on the Adobe Flash Platform. Robust content protection (DRM) is tightly integrated with the content preparation and delivery process to help ensure content is safely transmitted, enabling new business models.

IntroductionAdobe Flash Player 10.1 software introduces support for HTTP Dynamic Streaming, enabling an adaptive-bitrate, protected streaming experience with common HTTP servers, caching devices, and networks using a standard MP4 fragment format (F4F). HTTP Dynamic Streaming supports both live and on-demand media content that adjusts to viewer connection speed and processing power using standard HTTP protocol infrastructures that can meet the demand for HD content on a massive scale.

HTTP Dynamic Streaming provides tools to integrate adaptive streaming into encoding workflows. In addition, robust and flexible content protection is available for both live and on-demand media, powered by Adobe Flash Access™ 2 software. Flash Access helps make content protection simple to implement and transparent to the viewer.

Utilizing HTTP Dynamic Streaming on the Adobe Flash Platform provides many benefits:

• Unparalleled reach through Flash Player

• Industry-standard MP4 fragment format

• Integrated content protection powered by Flash Access 2

• Support for unmodified HTTP caching systems (such as content delivery networks—CDNs, ISPs, office caching, home networking)

• Open source and customizable media player framework integration (Open Source Media Framework—OSMF)

• Open Flash Player API for developing custom playback applications

• File preparation and Adobe toolset based on open specifications

• Open file format specifications for media (F4F) and manifest (F4M)

• High-quality, Flash compatible codecs (VP6/MP3, H.264/AAC)

This white paper provides a technical overview of HTTP Dynamic Streaming with sample use cases, outlines the available workflows, reviews typical use case scenarios, and introduces the capabilities of protected delivery powered by Flash Access 2. For more information, including free tools, format specifications, and support forums, visit the HTTP Dynamic Streaming website at www.adobe.com/go/httpdynamicstreaming.

Table of contents1:Introduction2:OverviewofHTTP

DynamicStreaming5:HTTPDynamicStream-

ingtools7:OpenSourceMedia

Framework7:Protectedstreaming

poweredbyFlashAccess

10:DeploymentoptionsforHTTPDynamicStreaming

11:HTTPDynamicStreamingusecases

12:HTTPDynamicStreamingfileformats

17:Onlineresources18:Glossary

2Adobe Flash Platform Technical White Paper

Overview of HTTP Dynamic Streaming HTTP Dynamic Streaming enables high-quality (H.264 or VP6), network-efficient HTTP streaming for media delivery that is tightly integrated with Flash Access for robust content protection in Flash Player 10.1. This open format solution allows online media publishers to leverage existing network and cache infrastructures to efficiently deliver media content to the Flash Platform. Adobe Flash Media Server software continues to be a great option for protected streaming, with a simple workflow for advanced interactive media experiences and multiway communication applications.

Like Flash Media Server, HTTP Dynamic Streaming supports quality of service (QoS) monitoring, adaptive bitrate, and DVR functionality. The HTTP Dynamic Streaming workflow includes prebuilt media preparation tools, a fragmented MP4 format that is HTTP cache friendly, a playback framework (OSMF), and options for protected streaming powered by Flash Access, continuing to make the Flash Platform the best choice for the reliable delivery of more secure, high-quality playback experiences.

The Flash Platform offers true multiprotocol support in Flash Player 10.1. HTTP Dynamic Streaming provides a similar end-user experience as traditional (RTMP) streaming from Flash Media Server. Flash Media Server offers an easy content delivery and protection workflow and low-latency live, and it supports trick modes for interactive playback. Flash Player 10.1 also introduces peer-assisted networking (P2P) for media delivery and communication via the RTMFP protocol. Multicast delivery is also included to help ensure that publishers have options that will perform best for their use cases.

When to use HTTP Dynamic StreamingHTTP Dynamic Streaming can provide additional benefits and enables significant improvements over progressive delivery. Some advantages of HTTP Dynamic Streaming over HTTP progressive download include:

• Delivery cost reduction by utilizing Internet caching infrastructure

• Easier firewall traversal

• Higher burstable capacity by utilizing standard CDN load-balanced networks and HTTP infrastructure caching

• Live streaming with adaptive bitrate, DVR support, and integrated content protection powered by Flash Access

• Continuous protection of content throughout the distribution chain, closing some potential vulnerabilities

• OSMF for rapid custom video player development, offering easy integration with advertising and analytics

• Bitrate throttling to help ensure only what is watched is delivered

• Media navigation supporting enhanced seeking and start anywhere

The following table shows some differences between HTTP Dynamic Streaming and RTMP Dynamic Streaming.

HTTP Dynamic Streaming RTMP Dynamic Streaming with Adobe Flash Media Server

Flash Player Reduced reach until Flash Player 10.1 is widely adopted

Flash Player 10 or later support (99% of all connected PCs)

File format F4F format compatible only with HTTP Dynamic Streaming—same files cannot yet be delivered using RTMP streaming

Note: Progressive download is supported but requires additional development.

Support for all Flash formats, including FLV and F4V

Note: F4F is not supported by Flash Media Server.

Publishing workflow Additional workflow steps required to prepare content; special origin server required

Simple publishing workflow

Content protection Requires Flash Access 2 RTMPe/SWF file verification for simple workflow; Flash Access 2 supported

Live latency Increased latency on live streams due to media fragmentation/encryption process before delivery

Low latency depending on deployment and buffer settings

3Adobe Flash Platform Technical White Paper

How HTTP Dynamic Streaming worksHTTP Dynamic Streaming extends the F4V format using an additional standards-based MP4 fragment format (ISO/IEC 14496-12:2008) with the extension .f4f. This format allows HTTP “gets” to fetch and cache smaller portions of the media. Adobe has published the complete F4F format specification inside the F4V specification on Adobe Developer Connection at www.adobe.com/devnet/flv.

Figure 1 illustrates how to prepare, deliver, consume, and protect video on demand (VOD) and live content using HTTP Dynamic Streaming.

Figure1.HTTPDynamicStreamingdeliveryworkflowforliveandVOD.

Packaging media Adobe has developed two tools to make it easy to package your existing media into this fragmented format: the File Packager and the Live Packager. The File Packager is used to prepare prerecorded media, and the Live Packager is used to prepare live RTMP streams.

Both packagers perform three tasks:

• Generate MP4 fragment–compliant files (F4F)

• Generate an XML-based manifest file (F4M)

• Apply content protection (optional)

For prerecorded media, the packaging process creates an F4F file asset from a previously encoded FLV or F4V file. The process also creates a Flash Media Manifest (F4M) file that describes the media and, if applicable, includes digital rights management (DRM) metadata such as the Flash Access license server location. For adaptive bitrate media delivery, the File Packager can update an existing manifest file with the additional bitrate file information. Note that for adaptive bitrate delivery, the media may need to be reencoded to help ensure keyframe alignment between the various bitrate files. Keyframe alignment is required for a smooth transition between bitrates (see “Encoding considerations for HTTP Dynamic Streaming” for more information).

For live streams, the packaging process converts any live RTMP stream into the F4F format. Codecs supported include H.264, AAC, VP6, and MP3, originating from live encoder technology that supports RTMP streaming. The Live Packager can protect content on-the-fly and outputs multiple F4F segments (containing multiple fragments). It also creates a real-time manifest file, just like the File Packager.

Files (from both live and prerecorded workflows) are placed on an HTTP server classified as an origin. The origin server is responsible for receiving fragment requests over HTTP and returning the appropriate fragment from the file. Adobe provides an HTTP Origin Module for Apache to handle this task, which can be downloaded for free from the HTTP Dynamic Streaming web page at www.adobe.com/go/httpdynamicstreaming.

4Adobe Flash Platform Technical White Paper

Publishing and playbackPortions of the complete file, called fragments, are downloaded and rendered by the Flash Player client. As the stream is played, ActionScript® within Flash Player monitors the client’s bandwidth and playback experience and can switch requests to the appropriate bitrate file fragments to improve playback performance. At the start of the streaming session, the media player (running on Flash Player 10.1) downloads the manifest file (F4M) that provides all the information needed to play back the media, including fragment format, available bitrates, Flash Access license server location, and metadata information. Figure 1 illustrates the full delivery workflow.

Requesting and parsing the manifest file, assembling the media fragments, and monitoring QoS require added logic to be built into existing Flash based media players. To simplify implementation, full support for HTTP Dynamic Streaming is available within OSMF. A turnkey sample player called Strobe Media Playback makes it even easier to get started. OSMF handles the logic, including manifest file management, adaptive bitrate switching, DVR functionality, and Flash Access 2 content protection key management. For more information, see the “Open Source Media Framework” section of this document or visit the Open Source Media Framework website at http://opensourcemediaframework.com.

Flash Player 10.1 and ActionScript 3.0 APIFlash Player 10.1 adds enhancements to dramatically improve the media playback experience, including better hardware acceleration, new RTMP buffer features, multicast, and peer-assisted networking. New ActionScript APIs (additions to the NetStream class) make HTTP Dynamic Streaming possible.

Flash Player 10.1 can request portions of media assets via HTTP and support existing Dynamic Streaming features such as full adaptive bitrate switching, live streaming, and DVR functionality. The new ActionScript API, NetStream.AppendBytes(),introduced in Flash Player 10.1 has been developed into OSMF for the easiest implementation. You can review the APIs in the ActionScript 3 Reference at http://help.adobe.com/en_US/FlashPlatform/beta/reference/actionscript/3/flash/net/NetStream.html#appendBytes().

Encoding considerations for HTTP Dynamic StreamingHTTP Dynamic Streaming supports high–quality, Flash compatible codecs (VP6 and H.264). For adaptive bitrate streaming, special considerations need to be made in the encoding process to help ensure seamless playback during switching.

Keyframes need to be aligned between all bitrates of a given media presentation for two reasons:

• Keyframes are used as guides for creating fragments for HTTP Dynamic Streaming.

• Flash can only change bitrates at a keyframe.

When keyframes are aligned across all the segmented streams, bitrate switching can be seamless for the viewer. This alignment can be forced by setting the encoder to the same closed GOP (group of pictures) and fixed GOP size distance for all streams; therefore, the selection of keyframe distance should be carefully considered.

The following table provides general keyframe interval recommendations.

Content type General range Typical range Minimum range

Short-form content 2–5 seconds 2–3 seconds 2 seconds

Long-form content 5–8 seconds 3–5 seconds 3 seconds

For example, if the source video frame rate is 29.97, the keyframe interval should be 59.94 or 60 frames for a fixed GOP size of 2 seconds.

Note: Keyframe intervals are based on quality recommendations and not defined or limited by HTTP Dynamic Streaming.

For live content, HTTP Dynamic Streaming uses the Live Packager to ingest RTMP streams, so encoding settings are configured in the live encoder (for example, Adobe Flash Media Live Encoder software).

For more specific encoding recommendations for on-demand content, refer to the Video Encoding and Transcoding Recommendations for Adobe Flash HTTP Dynamic Streaming white paper available on Adobe.com.

5Adobe Flash Platform Technical White Paper

Encoding for live HTTP Dynamic StreamingLive streaming over HTTP can be done with any hardware or software encoder that supports RTMP delivery. Flash Media Live Encoder is a great free option, and there are numerous third-party encoders on the market. For successful live adaptive bitrate streaming, it is important to set up the encoder correctly, as the live packaging process is sensitive to encoded keyframe interval settings.

For the smoothest transitions, the selected keyframe interval needs to be set in the event.xml file using the Live Packager <FragmentDuration> setting. The “Closed GOP” setting is required to help ensure that intraframe references don’t cross into adjacent fragments. To make sure that keyframes remain aligned, “scene-change detection” should also be disabled on the encoder.

Media delivery optionsThe Flash Platform is flexible in its delivery methods and provides options to meet every use case. To help determine if HTTP Dynamic Streaming is the right solution for your application, refer to the following table.

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 plus performance

Adaptive bitrate Yes No Yes

Publishing workflow Simple Simple Packaging plus manifest file required

Content protection Real time (RTMPe), SWF file verification, Flash Access DRM

Flash Access DRM for VOD only

Flash Access DRM for both live and VOD

Live support Yes No Yes

Live latency Less than 1 second* N/A Less than 30 seconds†

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.

HTTP Dynamic Streaming Tools HTTP Dynamic Streaming consists of a media format that can be used to prepare, protect, deliver, and consume media with the Flash Platform. To help publishers and distributors leverage the technology, Adobe has created new tools to help create and deliver the file formats, producing media that will provide optimum performance regardless of the hosting provider. The following table provides an overview of the Adobe tools for processing and delivering HTTP Dynamic Streaming content.

Adobe tool Description Reference

File Packager for video on demand

Free tool that creates MP4 fragmented media (F4F) from existing content encoded for Flash. The tool also creates the manifest file (F4M) and (optionally) encrypts using Flash Access.

Download www.adobe.com/products/httpdynamicstreaming

Live Packager Server solution that ingests a live RTMP stream and creates MP4 fragmented (F4F) media. The tool also (optionally) encrypts using Flash Access.

Contact Flash Media Server 4 www.adobe.com/go/fms/

HTTP Origin Module for Apache

Free Apache module required for VOD delivery. The Origin Module needs to be installed in the same location as the content storage. For live streaming, the Origin Module creates the manifest file as a virtual file.

Download www.adobe.com/products/httpdynamicstreaming

Open Source Media Framework

ActionScript framework used to parse and play media sets and manifest files, requesting media, monitoring QoS, and rendering playback in Flash Player 10.1.

Download http://opensource.adobe.com/wiki/display/osmf/Downloads

6Adobe Flash Platform Technical White Paper

Adobe tool Description Reference

Strobe Media Playback

Compiled OSMF-based sample player to get you started quickly.

Download www.osmf.org/developers.html

Adobe Flash Access 2k

File and stream protection that can be integrated into existing content preparation workflows. Enables delivery of protected content to Flash Player or Adobe AIR® applications, allowing users to stream, progressively download, or download premium content to Mac OS, Microsoft® Windows®, or Linux® desktops. The server side of Flash Access is distributed as a software development kit (SDK) and includes a reference implementation. .

Learn more www.adobe.com/products/flashaccess

The HTTP Dynamic Streaming file preparation and delivery workflow consists of three software tools: the F4F File Packager for VOD, the Live Packager for live stream processing, and the HTTP Origin Module for configuring the server for HTTP Dynamic Streaming.

File Packager tool The File Packager is a scriptable, command-line tool that converts recorded media into MP4 fragmented media, generates manifests, and can apply encryption policies (with a valid license for Flash Access 2). The tool is available for both Windows and Linux. It can ingest FLV (VP6/MP3) and F4V (H.264/AAC) files and outputs F4F fragmented files along with an F4M manifest file.

When using adaptive bitrate streaming, the File Packager also updates the manifest file with additional bitrate information. Content protection (DRM) is applied in the tool with a valid Flash Access certificate.

Live Packager toolPart of Flash Media Interactive Server 4, the Live Packager tool is a server solution that converts RTMP-based live streams into MP4 fragmented files that can be accessed via an integrated HTTP origin server. Encoders that support RTMP streaming can be used as an input for the Live Packager (for example, Flash Media Live Encoder, which is free). The Live Packager supports high-quality codecs including VP6/MP3 and H.264/HE-AAC. The tool is supported for both 32 and 64 bit packaging on Microsoft Windows Server® 2008 and Red Hat® Enterprise Linux 5, and Centos 5.3.

The Live Packager can apply real-time encryption with valid Flash Access certificates to help protect live streams from theft.

HTTP Origin Module for ApacheAdobe provides an HTTP Apache module that handles F4F fragment requests, manages the cache, interfaces with the Live Packager, and provides monitoring and reporting. This module makes it easy to configure HTTP Dynamic Streaming on servers and content delivery networks and is now included with all versions of Flash Media Server 4.

7Adobe Flash Platform Technical White Paper

Open Source Media FrameworkOpen Source Media Framework is a robust and flexible ActionScript framework for rapidly building media players for the Flash Platform and easily leveraging third-party service providers (like CDNs, analytics, and advertising). OSMF provides a robust, open source code base that is extensible and customizable, supporting a variety of media types such as JPG, MP3, FLV, F4V, and F4F. HTTP Dynamic Streaming support is built in with features such as live streaming, adaptive bitrate switching, DVR functionality, and Flash Access 2 authentication.

Figure2.OpenSourceMediaFrameworksampleplayerinterface.

Getting started with OSMF is easy with the OSMF sample player (www.opensourcemediaframework.com/developers.html), shown in Figure 2. It can be used to quickly and simply publish videos on your website, or it can provide a starting point and reference implementation for building more advanced custom players.

How HTTP Dynamic Streaming works in OSMFTo use HTTP Dynamic Streaming in OSMF, you source an F4M file. OSMF internal logic parses the manifest file, retrieves Flash Access license information (if applicable), requests the appropriate media fragment from the server, and begins playback.

If adaptive bitrate streaming is part of the manifest file, the OSMF-based player can detect when there has been a change in the viewer’s bandwidth or playback performance and switch to a more appropriate bitrate stream. This can be triggered by dropped frames, repeated buffering, or other playback problems or through bandwidth detection. Both HTTP Dynamic Streaming and RTMP Dynamic Streaming support this adaptive bitrate functionality. OSMF makes it even easier to implement.

For more information about OSMF, visit the OSMF website (http://osmf.org). To download the OSMF Sample player, visit the developers section (www.osmf.org/developers.html) of the OSMF website.

Protected streaming powered by Flash AccessPublishers that require content protection (DRM) for HTTP Dynamic Streaming can leverage their license of Flash Access 2, a content protection and monetization solution that enables robust and flexible distribution of premium content. This content can be played back using Flash Player 10.1 or on standalone applications built on Adobe AIR 2. The right solution will depend on the specific business model requirements.

HTTP Dynamic Streaming integrates closely with Flash Access to offer protected streaming. Content protection can be easily enabled inside either the File Packager or the Live Packager. When this option is configured, the packager will not only fragment the file or stream, but it will also encrypt the payload (the actual media samples) and add DRM metadata to the manifest file.

8Adobe Flash Platform Technical White Paper

The protected HTTP Dynamic Streaming workflow includes three primary components:

• License server—Issues content licenses that contain decryption keys and associated usage rules, including SWF file verification. Flash Access Server for Protected Streaming is an optimized version that can be used in combina-tion with HTTP Dynamic Streaming to provide a seamless user experience without compromising content.

• Packager—Prepares the live or previously encoded content for HTTP Dynamic Streaming delivery, including creating protected fragments. The Live Packager (Flash Media Server 4) is used for live content and the File Packager is used for on-demand content.

• Client runtime (Flash Player 10.1 or Adobe AIR 2)—Includes a secure Flash Access client that handles protected content, including enforcing usage rules and decrypting content for playback.

Adobe Flash Access ServerThe license server component of Flash Access is distributed as part of an SDK. Developers can use this SDK to create a complete solution, including (if appropriate) integrating Flash Access with existing databases and content management infrastructures. To help simplify this task, Adobe provides a reference implementation that demonstrates a simple yet complete system. This reference implementation can be used as a starting point for creating a custom license server deployment.

In addition, the Flash Access SDK includes a solution specifically designed for protected streaming use cases, which enables highly efficient and scalable operation of a license server with minimal or no development effort. This component, identified as Adobe Flash Access Server for Protected Streaming in the SDK, can be deployed on a simple Java™ servlet container like Tomcat and does not require a complete application server.

Flash Access Server supports multiple tenants, meaning a single server can be hosted on behalf of multiple content publishers, each with its own configuration settings. The functionality of Flash Access Server for Protected Streaming can be extended (via plug-ins or filters), which could be used to help integrate with a third-party token authentication or authorization system.

Protecting video on demand for HTTP Dynamic StreamingMedia assets for HTTP Dynamic Streaming are protected using the File Packager along with a valid Flash Access 2 Pass digital certificate, purchased as part of the Flash Access 2 software license. FLV and F4V files are protected using 128-bit AES CBC encryption.

Adding encryption is done at the same time as fragmentation of the media. Using the File Packager, you pass the license server location (URL), certificates (DER), and policies (POL) into the packager to encrypt one or multiple assets with the same DRM license. A connection to the license server is not required at the time of packaging. The license server is contacted only during playback. Once encrypted, the metadata required to acquire a license is placed within the manifest file so the Flash client can retrieve the DRM key before playback begins.

Here is an example of a packager configuration file with the DRM information.

<offline><input-file>someFile.f4v</input-file><content-id>contentId</content-id><common-key>commonKey.bin</common-key><license-server-url>http://server1.com:9999</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>

When using the configuration XML file, you can use this as your input for the File Packager (f4fpackager):

f4fpackager--conf-file=f4fpackager_config.xml

The same DRM key should be used with all assets within a multibitrate set to limit any interruption between adaptive bitrate streaming. To help ensure all streams share a license key, use the same content ID, common key, policy, and license server for all packaging. For large sets of media that share the same DRM information, you can also use the same configuration file for multiple packaging processes running on different computers.

9Adobe Flash Platform Technical White Paper

Protecting live streams for HTTP Dynamic Streaming with Flash Media Server 4Media assets for live HTTP Dynamic Streaming are protected using the Live Packager (Flash Media Server 4), along with a valid Flash Access 2 Pass digital certificate, purchased als part of the Flash Access 2 software license.

Protected live streaming supports all the supported codecs and features of HTTP Dynamic Streaming including adaptive bitrate switching and DVR/PVR time shifting. The Live Packager is a server that uses a configuration file (Event.xml) to set parameters (for example, fragment durations) for each event. Within these parameters, the Flash Access DRM information is added.

Similar to VOD packaging, live packaging encryption is done at the same time as fragmenting the media. Using the Live Packager, you pass the license server location (URL), certificates (DER), and policies (POL) into the file packager to encrypt one or multiple assets with the same DRM license. A connection to the license server is not required at the time of packaging. The license server is contacted only at playback. Once encrypted, the metadata required to acquire a license is placed within the F4M file so the Flash client can retrieve the DRM key before playback begins.

Here is a sample Live Packager Event.xml file with Flash Access information added:

<Event><EventID>MyEvent</EventID><Recording><FragmentDuration>4000</FragmentDuration><SegmentDuration>3600000</FragmentsPerSegment> <ContentProtectionenabled=”true”> <ProtectionScheme>FlashAccessV2</ProtectionScheme> <FlashAccessV2> <ContentID>MyEvent</ContentID> <CommonKeyFile>common-key.bin</CommonKeyFile> <LicenseServerURL> http://license.corp.adobe.com:8090 </LicenseServerURL> <LicenseServerCertFile>license_server_cert.der</LicenseServerCertFile> <TransportCertFile>transport_cert.der</TransportCertFile> <PackagerCredentialFile>packager_cred.pfx</PackagerCredentialFile> <PackagerCredentialPassword>?????????</PackagerCredentialPassword> <PolicyFile>policy_anonymous.pol</PolicyFile> </FlashAccessV2> </ContentProtection></Recording></Event>

Also similar to VOD packaging, the same DRM key should be used with all assets within a multibitrate set to limit any interruption between adaptive bitrate streaming. To help ensure all streams share a license key, use the same content ID, common key, policy, and license server for all packaging.

DRM in the manifest fileThe DRM license server information is embedded within the F4F file and is also available in the F4M file (for both VOD and live). Having access to the DRM information before the media arrives promotes a fast start and lets the OSMF client prepare for media rendering quickly.

Here is sample DRM metadata within the F4M file received by OSMF:

<drmAdditionalHeader url=”/live/streams/myStream.drmmeta” drmContentId=”live_mbr_event” id=”drmMetadata9996”/>

Deploying a license serverOnce content is packaged, the next step is to create a license server application that can grant licenses to clients. The Flash Access SDK contains APIs that allow you to build your own license server application. Adobe provides a reference implementation that may make it easier to create a complete solution from the SDK.

10Adobe Flash Platform Technical White Paper

The APIs allow your license server to grant licenses and authenticate clients. All requests follow the same basic workflow—create a handler, parse the request, write a response, and close, which sends a response to the client. At a minimum, a license server must support granting licenses to clients. A license server may optionally include the ability to handle client authentication by implementing logic to validate user credentials (for example, LDAP integration or by checking a database).

StreamingAll usage rules are specified on the license server. Usage rules specified in the protected content are ignored. Those that are configurable can be set on a per-tenant basis.

Flash Access Server supports the following usage rules:

• Output protection—Define how or what type of screens or outputs the client can access for display.

• Adobe AIR and SWF file verification (similar to functionality on Flash Media Server)—Help ensure that only authorized playback clients can access content.

• DRM and runtime module restrictions—Specify (via a whitelist) which SWF files or AIR applications can play back the content, which protects against “deep linking.”

• License caching—Enable caching of license authentication to allow instant start and offline playback.

• Multiple play rights—Specify different combinations of output protection, application restrictions, and DRM/runtime restrictions.

The following usage rules are fixed when using Flash Access Server for Protected Streaming:

• Anonymous access

• Licenses valid for 24 hours, starting when the license is issued

• No license chaining support

• No playback window support

• No custom property support

For content that is using adaptive bitrate, a single license key can be used to package multiple files, promoting a smooth playback experience when switching between bitrates. For more information about Flash Access usage rules, see the Flash Access Help (http://help.adobe.com/en_US/flashaccess/2.0/usage_rules.pdf).

Deployment options for HTTP Dynamic StreamingA key benefit of HTTP Dynamic Streaming is industry standardization, which enables consistent ecosystem support for HTTP media delivery to Flash. A standardized platform provides the foundation to build easy-to-deploy services that help prepare, protect, and deliver media and services.

The following services can be made available to support HTTP Dynamic Streaming.

Service offering Description

Encoding Encode live or prerecorded media into Flash supported codecs ( H.264/AAC). Encoders create multiple bitrates, align keyframes, and insert metadata and timecode.

F4F packaging for VOD Prepackage and protect FLV or F4V media into the MP4 fragment format (F4F), apply encryption, and generate a manifest file (F4M)

F4F packaging for live Prepackage and protect live streams into F4F, apply encryption, and generate F4M. Typically, services will also act as live HTTP origins.

Origin services Serve fragment requests. Typically, origins are tied to a remote archive or live packaging solution.

Delivery services Allow fragment requests to be passed to the origin and cached (typical CDN) with a HTTP-based network. Also provide basic access restrictions including geo filtering and token authentication.

License server hosting services

Serve Flash Access license keys for encrypted media (live or on demand).

Player development (OSMF) Create custom media experiences based on the Open Source Media Framework.

11Adobe Flash Platform Technical White Paper

HTTP Dynamic Streaming use casesHTTP Dynamic Streaming has a variety of appropriate uses. This section introduces some key use cases and different workflows. In all examples, the video files can be encoded using either H.264 or VP6 video codecs, with multiple files encoded at different bitrates to enable adaptive bitrate functionality.

VOD files packaged using an external service (no DRM)A publisher requires simple implementation of HTTP Dynamic Streaming. It doesn’t want to add any steps to its workflow and doesn’t require content protection. It considers HTTP Dynamic Streaming as a wire format.

The publisher uploads its encoded content to a third-party service that provides HTTP Dynamic Streaming delivery. The service provider fragments the assets using the File Packager, which prepares an F4F file and an F4M file. These files are placed on the service provider’s web server, which has been configured as an origin for HTTP Dynamic Streaming.

When the packaging process is complete, the service provider sends the publisher a block of HTML that it embeds in the publisher’s web page, enabling site visitors to view the video via HTTP Dynamic Streaming in Flash Player 10.1. If the content has been played previously, it may come from a caching server between the player and the CDN.

VOD files packaged internally (no DRM)A publisher wants to handle the packaging of content itself and will use a CDN for delivery only. It doesn’t require content protection.

Using the File Packager tool, the publisher fragments the assets, making it very easy for the CDN to simply deliver the files. The packager outputs an F4M file for each media presentation and F4F files for each bitrate in the presentation. All files are uploaded to the CDN and registered in their content management system.

The publisher’s Flash developer utilizes OSMF to create an HTTP-based video player. When a site visitor requests a video, the OSMF-based player fetches the manifest file, which provides media locations and metadata. The player then begins to play the media at the appropriate bitrate for the viewer’s connection and adjusts quality automatically. If the content has been played previously, it may come from a caching server between the player and the CDN.

VOD files packaged internally with DRMA publisher wants complete control over its on-demand premium media assets. It chooses to package and encrypt the media itself and to host the origin and license servers.

Using the File Packager tool and its Flash Access Pass digital certificate, the publisher protects and fragments the assets, creating an F4M file for each media presentation and protected F4F files for each bitrate in the presentation. All files are then placed on a local HTTP Apache server with the HTTP Origin Module installed. The publisher links the local origin with the CDN and registers the media in its content management system.

The publisher’s Flash developer utilizes OSMF to create an HTTP-based video player. When a site visitor requests a video from the CDN, the OSMF-based player fetches the manifest file, which provides media locations and metadata, along with information about where to acquire a content license to access the video stream. In this case, the DRM license server requests from the publisher’s data center.

The player then acquires the license from the Flash Access license server, deployed in-house by the publisher. The F4F fragments are requested through the CDN and up into the publisher’s origin server if no cache is available. The video begins to play at the appropriate bitrate for the viewer’s connection. If the content has been played previously, it may come from a caching server between the player and the CDN.

Live stream packaged internally with DRM A publisher wants to deliver a secure live stream with DVR functionality on a massive scale. It will rely on multiple CDNs to deliver its stream, so it is handling the real-time packaging of the stream internally.

The publisher begins by configuring its Linux Apache HTTP server with the Adobe HTTP Origin Module for HTTP Dynamic Streaming. A live event configuration file is created on the Adobe Live Packager with the DRM and stream metadata.

12Adobe Flash Platform Technical White Paper

Flash Media Live Encoder encodes a live video feed and publishes it to the Adobe Live Packager using the RTMP protocol. The Live Packager protects and fragments the stream into multiple F4F segments (groupings of fragments), and the Origin Module generates a dynamic manifest file (F4M).

The client is an OSMF-based player. When a site visitor requests the live stream, the OSMF player fetches the manifest file, which provides media location and metadata, along with information about how to acquire a content license to access the video stream. The player then acquires the license from the Flash Access license server, which is operated in a highly scalable infrastructure internally.

The user can watch the live event in the video player and can use controls for trick play such as rewinding or pausing the live event.

HTTP Dynamic Streaming file formatsThe F4F file format is based on the industry-standard MP4 fragment format ISO/IEC 14496-12:2008 (www.iso.org/iso/catalogue_detail?csnumber=51533) as the media container. This media format can support additional functionality such as DRM, timed text, cue points, and much more in the future.

The F4M format is a new XML-based format containing F4F bootstrap information, Flash Access license server location (if applicable), metadata, and bitrate information. The following table outlines the file format specifications for HTTP Dynamic Streaming.

File extension Description

.f4f The Adobe extension for MP4 fragmented media.

Open specification: www.adobe.com/devnet/flv

.f4m The Adobe extension for manifest files. For VOD, this file is created from the File Packager. For live streaming, this is a virtual file created by the HTTP Origin Module.

Open specification: http://opensource.adobe.com/wiki/display/osmf/Flash+Media+Manifest+File+Format+Specification

.f4x Adobe extension for an index file that lists the fragment offsets (“afra” information) needed to locate specific fragments within the stream. The HTTP Origin Module uses the index file to deliver fragments upon request.

.drmmeta Adobe extension for external DRM metadata for media protected with Flash Access.

.meta (Live only) Extension for a file that contains additional stream metadata such as bitrate, frame size, and so on.

.bootstrap (Live only) Extension for a file that contains bootstrap information.

.control (Live only) Extension for a file that contains internal metadata used by the Live Packager.

The following section provides a detailed overview of all the files used with HTTP Dynamic Streaming.

Media format (F4F) advantagesThe benefits of the F4F file format are numerous, the most compelling being unmodified HTTP caching support, which enables massive scalability on standard network infrastructures. Other advantages include:

• Quick play start—The multiplexed hint track samples can be consumed directly for linear non-seek consumption even without parsing the metadata in the moof atom because they utilize standard RTMP messages/FLV tags.

• Lean bootstrap information—Because run tables are used, the bootstrap information is minimal while still being effective.

• Mix and match protocols—By using the multiplexed hint tracks, HTTP Dynamic Streaming can be mixed and matched with other protocols like RTMP or RTMFP to optimize the playback experience.

13Adobe Flash Platform Technical White Paper

Media format (F4F) detailsTo achieve a low-latency streaming experience with HTTP Dynamic Streaming, the media data is chunked into small units that contain all the information Flash Player needs to consume and play back that media data. These small units are referred to as fragments. Multiple fragments can exist within a single large media file or as multiple files (see Figure 3).

Segment 1

Asset

Frag 1

Frag 2

Frag 3

Frag 4

Segment 2

Frag 5

Frag 6

Frag 7

Frag 8

Segment 3

Frag 9

Frag 10

Frag 11

Frag 12

Segment 1

Asset

Frag 1

Frag 2

Frag 3

Frag 4

Segment 1

Asset

Frag 1

Figure3.SegmentandfragmentstructureinF4Fmedia.Mediaassetfilescanhaveanycombinationofsegmentsandfragments,asshowninthesethreeexamples.

The following table provides a summary of elements that compose the F4F file format.

Element Description

Fragment Element of a media presentation that contains metadata (moof box) and media data (mdat box) that includes a multiplexed hint track (along with audio and video tracks), with no data duplication

Multiplexed hint track Multiplexed audio, video, and data tracks in the same order used for RTMP or FLV formats

Segment Element of a media presentation that stores one or more fragments—an F4F file

Bootstrap information The initial information required to start consuming media, located in both the media file (F4F) and the manifest file (F4M)

Random access point Synchronization points in a media file from which media can be played back—usually a keyframe

URL derivation scheme The method of retrieving fragments within a file via specific URLs, enabling caching of media content

FragmentsA fragment contains both metadata (moof) that was originally encapsulated in a moov box in the unfragmented MP4 file and media data (mdat). The MP4 file format supports an efficient fragment structure that interleaves metadata inside multiple moof boxes and media data in multiple mdats in a single file. Each fragment begins with a random access point (a keyframe or an instantaneous decoding refresh picture for H.264 video) and can contain multiple seekable random access points. The fragment structure has a few boxes in addition to the MP4 standard to enable playback in Flash Player (see Figure 4).

14Adobe Flash Platform Technical White Paper

Afra

Fragment

Random accessSampleO�sets

Moof Traf – audio, video, hinttrun

MdatVideo track samplesAudio track samplesHint track samples

Figure4.FragmentstructureinF4Fmedia.

Multiplexed hint trackIn order to provide a consistent viewing experience in Flash, the F4F format uses multiplexed audio, video, and data tracks in the same order as used for RTMP or FLV formats. This information is stored in the media file as a hint track. The multiplexed hint track enables easy synchronization of audio and video data at the client.

SegmentsA segment is a collection of fragments stored as a file or a resource. Every media presentation is composed of one or more segments, with each segment containing one or more fragments. These fragments, in turn, contain one multiplexed hint track. Both segments and fragments are uniquely addressable using a URL.

Bootstrap informationBootstrap information is the initial information required to start consuming media. The information is located in both the media file (F4F) and the manifest file (F4M) so that the OSMF-based media player can start playback quickly. The bootstrap information is optimized for the quickest start. Fragment and segment information is stored in run tables, enabling the fastest access. A run table is a compact way to store a sequence of elements that are typically expected to have the same value. For example, a single record in the fragment run table represents a series of fragments with the same duration. Records are added only when the fragment duration changes; therefore, the bootstrap information is optimized for fragments having the same duration, but it can still support fragments with varying durations. Similarly, the segment run table stores the number of fragments in each segment in an efficient manner. The combination of the segment run table and the fragment run table allows a client to seek to the closest fragment for any given media time (or timecode).

Typically, the bootstrap information is composed of these two tables, along with a list of web servers where the data is stored, and optional content metadata. Content metadata includes the DRM metadata when the media content is protected with Flash Access. When F4F files are used with F4M files, this web server location and metadata can be stored outside the bootstrap information, which would then be a part of the F4M file but could still be included in the F4V media file or saved as an external bootstrap file. When included in the media file, it is contained in the BootstrapInfo box. This box contains basic information about the server, movie, segment, the segment run table(s), and the fragment run table(s). This box should be followed by the moov box in the F4V file whenever the moov appears at or very close to the beginning of the file.

Bootstrap Box (abst)Metadata (optional)ServersDRM (data or link)Other

asrt (Seg Run Table)seg frag1 4010 6

afrt (Frag Run Table)frag secs1 2100 3

Figure5.Bootstrapinformationbox.

15Adobe Flash Platform Technical White Paper

Bootstrap information includes the following data:

Bootstrap property Description Sample value

Movie identifier The identifier of this presentation in the form of a null terminated string. This could be a file or pathname in a URL.

my_movie

Live Indicates if the movie is live or not. true/false

Time Current media time for live; can be 0 for nonlive. 0

Update Indicates if this is an update to a previous version of the bootstrap file. true/false

Profile Indicates which profile is used (Named access profile is the only available profile at this time).

Named

Version Version number of bootstrap info, or the version this information updates if the “update” flag is set.

12345

Server base URLs The server base URL for this media presentation—this field is not used when F4M files are used.

http://www.example.com

DRM metadata A Base64 representation of metadata or the URL of the license server. This field is not used when F4M files are used.

0x2834897

Other metadata A string containing metadata or the location of additional external metadata.

”Movie”

Segment run table Listing of number(s) of fragments per segment—used to find the segment that contains a sample corresponding to a specific time.

”asrt” box as defined in the format specification

Fragment run table Listing of duration(s) of fragments—used to find a sample corresponding to a specific time.

”afrt” box as defined in the format specification

Random access pointRandom access points are synchronization points in a media file from which media can be played back—usually a keyframe. The fragment random access box is used primarily to provide random access information corresponding to one or many fragments. Although it is physically associated with a given fragment, it could contain random access information of other fragments within that same segment or in different segments. Each entry contains the location and the presentation time of the randomly accessible sample.

URL derivation schemeThe URL derivation scheme helps arrive at the specific URLs to be used for requesting fragments within a file. The HTTP Origin Module parses this URL and returns the bytes corresponding to that fragment from a specific F4F file. It is possible to request the entire fragment and seek to the requested random access point locally.

Each segment is identified as a separate URL resource (file), while each fragment is separately addressable by the URL scheme:

http://server_and_path/QualityModifierSeg’segment_number’–Frag’fragment_number’

The breakdown of the URL is as follows:

server_and_path Web server path to the content

qualityModifierSeg Name used for the multibitrate or trick play files (optional)

segment_number Number (without leading zeros) associated with the segment

fragment_number Number (without leading zeros) associated with the fragment

An example fragment request would look like this:

http://myserver.com/mypath/1080pSeg43-Frag210

Flash Media Manifest formatIn order to immediately access the data needed to begin playback, Flash Player needs some basic information about the media presentation. The F4M format is an XML-based open file format that provides this information, describing video fragment file information, bootstrap information, DRM license server location(s), available bitrates and file location(s), and metadata information for a single piece of media. The manifest file is created along with media file segments by the packaging tool (File Packager or Live Packager).

16Adobe Flash Platform Technical White Paper

As part of Adobe’s open specifications for HTTP Dynamic Streaming, you can review and contribute to the specification for the manifest file format as part of the Open Source Media Framework (http://opensource.adobe.com/wiki/display/osmf/Flash+Media+Manifest+File+Format+Specification).

Manifest file workflowThe manifest file provides all the information needed to initiate the display of media in the playback client. The client must have logic in place to parse the manifest file; OSMF provides this logic and is therefore the suggested solution for building players based on HTTP Dynamic Streaming. (The NetStream.appendBytes API also provides access to this information but is much more complicated to implement.)

First, the OSMF client sends an HTTP request for a specific F4M file to the server. Using the bootstrap information (run tables) contained in the F4M file, the client translates the desired timecode to a segment number/fragment number pair. The client then constructs a URL based on this number pair, which requests a specific fragment from a specific F4F file. This is passed to the server’s HTTP Origin Module, which references the F4X index file to locate the specific fragment requested within the F4F file. This fragment is then sent to the client for playback. Additional metadata in the bootstrap file is used by the client to perform tasks such as populating the player and customizing the display.

In the case of protected HTTP Dynamic Streaming, the OSMF client must also read the DRM metadata from the bootstrap information in order to begin playback. Once this metadata is parsed, the OSMF client contacts the specified Flash Access license server to acquire a license key and associated license rules. That key is then stored in memory. Ideally, if multibitrate delivery is being used, all bitrates of a specific media will be encoded with the same license key to eliminate the need for an additional round trip to the license server when changing from one bitrate to another.

General structureThe manifest file is an XML document that represents a single media asset. That media may have multiple related files, as with adaptive bitrate delivery, but a manifest file does not contain information about more than one distinct piece of media. Developers can extend the manifest file format by adding their own custom elements.

A manifest file can contain core metadata relating to a piece of media, as well as DRM and bootstrap information. Some of this information applies to all representations of the media, but other pieces may apply only to a specific representation. The following table outlines elements of a manifest file.

Element Description

Bitrate information Media file information for multibitrate delivery

Bootstrap information Basic information needed to begin playback; can include the bootstrap data itself or a URL to an external file

Moov atom Optional metadata for a media representation

DRM authentication Information needed to retrieve DRM voucher information; can include the authentication data itself or a URL to an external file

The following is an example of a manifest file specifying a single piece of streamed, protected media with a duration of 253 seconds:

<?xmlversion=”1.0”encoding=”utf-8”?> <manifestxmlns=”http://ns.adobe.com/f4m/1.0”> <id>myvideo</id> <duration>253</duration> <mimeType>video/x-flv</mimeType> <streamType>recorded</streamType> <baseURL>http://example.com”</baseURL> <drmMetadataurl=”http://mydrmserver.com/mydrmmetadata”/> <bootstrapInfoprofile=”named”url=”/mybootstrapinfo”/> <mediaurl=”/myvideo/medium”bitrate=”908”width=”800”height=”600”/></manifest>

17Adobe Flash Platform Technical White Paper

Bitrate informationThe manifest file format supports multibitrate delivery, with each bitrate file added as a separate media node. Files of different bitrates can share DRM and HTTP bootstrap information, or this information can be specified separately for each individual bitrate file.

This example demonstrates a manifest file specifying multiple bitrate streams with DRM and HTTP bootstrap information that applies to all streams:

<?xmlversion=”1.0”encoding=”utf-8”?> <manifestxmlns=”http://ns.adobe.com/f4m/1.0”> <id>myvideo</id> <duration>253</duration> <mimeType>video/x-flv</mimeType> <streamType>recorded</streamType> <baseURL>http://example.com”</baseURL> <drmMetadataurl=”http://mydrmserver.com/mydrmmetadata”/> <bootstrapInfoprofile=”named”url=”/mybootstrapinfo”/> <mediaurl=”/myvideo/low”bitrate=”408”width=”640”height=”480”/> <mediaurl=”/myvideo/medium”bitrate=”908”width=”800”height=”600”/> <mediaurl=”/myvideo/high”bitrate=”1708”width=”1920”height=”1080”/></manifest>

Bootstrap informationA manifest file can contain one shared bootstrap information block that applies to all media files, as shown in the previous example, or per-file bootstrap information. For example, there could be one bootstrap information block that applies to all MP4 versions of the media, and a second bootstrap information block that applies to all FLV versions of the media. Bootstrap information can be specified as an external bootstrap file, in which case the bootstrap information block of the manifest file would contain the URL to the external file.

moov atomThe optional moov element in the manifest file represents the movie box, or “moov” atom, for an authoritative representation of the piece of media. It contains a Base64-encoded movie box (moov) for the given media.

DRM authentication informationThe optional DRM authentication information block represents all information needed to perform DRM voucher retrieval for the media. It contains the DRM metadata represented either as a Base64-encoded representation or a URL pointer to an external DRMMETA file. A manifest file can contain one shared DRM authentication information block that applies to all media files, or per-file DRM authentication information.

Online resourcesHTTP Dynamic Streaming: www.adobe.com/go/httpdynamicstreaming

FLV format specification: www.adobe.com/devnet/flv

Support forums: http://forums.adobe.com/community/flash/httpdynamicstreaming

Open Source Media Framework: http://osmf.org

OSMF Sample player for HTTP Dynamic Streaming: www.osmf.org/developers.html

Kevin Towes on Online Video at Adobe: http://blogs.adobe.com/ktowes

Adobe Flash Access: http://www.adobe.com/go/flashaccess

18

Glossary

Atom Also referred to as a “box,” an atom is an object-oriented building block of an MPEG-4 file that can contain either data or other boxes, which in turn can contain data or still other boxes and so on. Each type of atom is defined by a unique type identifier (a four-character code, such as “moov” or “mdat”) and length.

Bootstrap Initial information required to begin consuming media.

Box See “Atom.”

CDN Content delivery network.

DRM Digital rights management as implemented in Flash Player 10.1.

DVR Digital video recorder.

F4M Flash Media Manifest file format.

F4X Flash Media Index file format. Only required by the client if using the NetStream.appendBytes API to build a custom player, rather than using the Open Source Media Framework. Otherwise, it is used by the HTTP Origin Module to calculate the byte offset within a selected media segment to locate a requested fragment.

Fragment A pair of moof and mdat boxes that contain metadata and media data.

HTTP Hypertext Transfer Protocol.

Mdat atom In the MPEG-4 file format, this is the “box” where the actual raw information for the media is stored. This top-level atom comprises the bulk of an MPEG-4 file.

Moof atom A header that describes a fragment in an ISO/MP4 file.

Moov atom A single container atom whose subatoms define the metadata for a piece of media.

Manifest file An F4M file that contains information about a Flash media asset (location of the media, DRM metadata, media bootstrap information, multibitrate information, and so on).

Random access point A synchronization point in a media file from which media can be played back; usually a keyframe.

RTMP Real Time Messaging Protocol, the delivery method used by Flash Media Server.

Segment A collection of fragments stored as a file or a resource identifiable by a URL.

Trick play Playing in reverse or fast forward mode or other than conventional forward playing.

VOD Video on demand.

For more informationSolution details: www.adobe.com/go/httpdynamicstreaming

Adobe Systems Incorporated345 Park Avenue San Jose, CA 95110-2704 USA www.adobe.com

Adobe, the Adobe logo, ActionScript, Adobe AIR, AIR, Flash, Flash Access are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. Mac OS is a trademark of Apple Inc., registered in the U.S. and other countries. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Red Hat is a trademark or registered trademark of Red Hat, Inc. in the United States and other countries. Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. All other trademarks are the property of their respective owners.

© 2010 Adobe Systems Incorporated. All rights reserved. Printed in the USA.

91030544 9/10