Adobe Flash Platform Technical White Paper

HTTP Dynamic Streaming on the Adobe Flash Platform

Enabling high-quality, network-efficient HTTP streaming for media delivery
Table of contents 1: Introduction 2: Overview of HTTP Dynamic Streaming 5: HTTP Dynamic Streaming tools 7: Open Source Media Framework 7: Protected streaming powered by Flash Access 10: Deployment options for HTTP Dynamic Streaming 11: HTTP Dynamic Streaming use cases 12: HTTP Dynamic Streaming file formats 17: Online resources 18: Glossary

HTTP Dynamic Streaming enables media distributors to leverage the Internets 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.

Introduction
Adobe Flash Player 10.1 software introduces support for HTTP Dynamic Streaming, enabling an adaptivebitrate, 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 networksCDNs, ISPs, office caching, home networking) Open source and customizable media player framework integration (Open Source Media FrameworkOSMF) 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.

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 Streaming

HTTP 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
Flash Player File format Reduced reach until Flash Player 10.1 is widely adopted F4F format compatible only with HTTP Dynamic Streamingsame files cannot yet be delivered using RTMP streaming Note: Progressive download is supported but requires additional development. Publishing workflow Content protection Live latency Additional workflow steps required to prepare content; special origin server required Requires Flash Access 2 Increased latency on live streams due to media fragmentation/encryption process before delivery

RTMP Dynamic Streaming with Adobe Flash Media Server

Flash Player 10 or later support (99% of all connected PCs) Support for all Flash formats, including FLV and F4V Note: F4F is not supported by Flash Media Server. Simple publishing workflow RTMPe/SWF file verification for simple workflow; Flash Access 2 supported Low latency depending on deployment and buffer settings

Adobe Flash Platform Technical White Paper

How HTTP Dynamic Streaming works

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

Figure 1. HTTP Dynamic Streaming delivery workflow for live and VOD.

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

Adobe Flash Platform Technical White Paper

Publishing and playback Portions 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 clients 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 API

Flash 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 Streaming

HTTP Dynamic Streaming supports highquality, 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
Short-form content Long-form content

General range
25 seconds 58 seconds

Typical range
23 seconds 35 seconds

Minimum range
2 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.

Adobe Flash Platform Technical White Paper

Encoding for live HTTP Dynamic Streaming Live 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 dont cross into adjacent fragments. To make sure that keyframes remain aligned, scene-change detection should also be disabled on the encoder.

Media delivery options

The 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
Flash Player version Quality of service Adaptive bitrate Publishing workflow Content protection Live support Live latency Synchronous communication Logging Cacheable
*

HTTP progressive download

Flash Player 7 or later N/Aoften resulting in poor user experience No Simple Flash Access DRM for VOD only No N/A No No Yes

HTTP Dynamic Streaming

Flash Player 10.1 or later Measured on bandwidth plus performance Yes Packaging plus manifest file required Flash Access DRM for both live and VOD Yes Less than 30 seconds N/A Client side Yes

Flash Player 6 or later Measured on bandwidth and performance Yes Simple Real time (RTMPe), SWF file verification, Flash Access DRM Yes Less than 1 second* Yes Server side No

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
File Packager for video on demand

Description
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. Server solution that ingests a live RTMP stream and creates MP4 fragmented (F4F) media. The tool also (optionally) encrypts using Flash Access. 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. ActionScript framework used to parse and play media sets and manifest files, requesting media, monitoring QoS, and rendering playback in Flash Player 10.1.

Reference
Download www.adobe.com/products/ httpdynamicstreaming Contact Flash Media Server 4 www.adobe.com/go/fms/ Download www.adobe.com/products/ httpdynamicstreaming Download http://opensource.adobe.com/wiki/ display/osmf/Downloads

Live Packager

HTTP Origin Module for Apache

Open Source Media Framework

Adobe Flash Platform Technical White Paper

Adobe tool
Strobe Media Playback Adobe Flash Access 2k

Description
Compiled OSMF-based sample player to get you started quickly. 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. .

Reference
Download www.osmf.org/developers.html 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 tool

Part 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 Apache

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

Adobe Flash Platform Technical White Paper

Open Source Media Framework

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

Figure 2. Open Source Media Framework sample player interface.

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 OSMF

To 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 viewers 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 Access

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

Adobe Flash Platform Technical White Paper

The protected HTTP Dynamic Streaming workflow includes three primary components: License serverIssues 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 combination with HTTP Dynamic Streaming to provide a seamless user experience without compromising content. PackagerPrepares 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 Server

The 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 Streaming Media 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.
Adobe Flash Platform Technical White Paper

Protecting live streams for HTTP Dynamic Streaming with Flash Media Server 4 Media 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> <ContentProtection enabled=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 file The 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 server Once 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.

Adobe Flash Platform Technical White Paper

The APIs allow your license server to grant licenses and authenticate clients. All requests follow the same basic workflowcreate 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).

Streaming
All 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 protectionDefine 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 restrictionsSpecify (via a whitelist) which SWF files or AIR applications can play back the content, which protects against deep linking. License cachingEnable caching of license authentication to allow instant start and offline playback. Multiple play rightsSpecify 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 Streaming

A 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-todeploy services that help prepare, protect, and deliver media and services. The following services can be made available to support HTTP Dynamic Streaming.
Service offering
Encoding F4F packaging for VOD F4F packaging for live Origin services Delivery services

Description
Encode live or prerecorded media into Flash supported codecs ( H.264/AAC). Encoders create multiple bitrates, align keyframes, and insert metadata and timecode. Prepackage and protect FLV or F4V media into the MP4 fragment format (F4F), apply encryption, and generate a manifest file (F4M) Prepackage and protect live streams into F4F, apply encryption, and generate F4M. Typically, services will also act as live HTTP origins. Serve fragment requests. Typically, origins are tied to a remote archive or live packaging solution. 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. Serve Flash Access license keys for encrypted media (live or on demand). Create custom media experiences based on the Open Source Media Framework.

License server hosting services Player development (OSMF)

Adobe Flash Platform Technical White Paper

10

HTTP Dynamic Streaming use cases

HTTP 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 doesnt want to add any steps to its workflow and doesnt 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 providers 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 publishers 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 doesnt 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 publishers 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 viewers 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 DRM

A 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 publishers 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 publishers 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 publishers origin server if no cache is available. The video begins to play at the appropriate bitrate for the viewers 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.

Adobe Flash Platform Technical White Paper

11

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 formats

The 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
.f4f

Description
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+Form at+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. Adobe extension for external DRM metadata for media protected with Flash Access. (Live only) Extension for a file that contains additional stream metadata such as bitrate, frame size, and so on. (Live only) Extension for a file that contains bootstrap information. (Live only) Extension for a file that contains internal metadata used by the Live Packager.

.drmmeta .meta .bootstrap .control

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

Media format (F4F) advantages

The 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 startThe 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 informationBecause run tables are used, the bootstrap information is minimal while still being effective. Mix and match protocolsBy 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.

Adobe Flash Platform Technical White Paper

12

Media format (F4F) details

To 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).
Asset Segment 1
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

Asset Segment 1
Frag 1 Frag 2 Frag 3 Frag 4

Asset Segment 1

Frag 1

Figure 3. Segment and fragment structure in F4F media. Media asset files can have any combination of segments and fragments, as shown in these three examples.

The following table provides a summary of elements that compose the F4F file format.
Element
Fragment Multiplexed hint track Segment Bootstrap information Random access point URL derivation scheme

Description
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 audio, video, and data tracks in the same order used for RTMP or FLV formats Element of a media presentation that stores one or more fragmentsan F4F file The initial information required to start consuming media, located in both the media file (F4F) and the manifest file (F4M) Synchronization points in a media file from which media can be played backusually a keyframe The method of retrieving fragments within a file via specific URLs, enabling caching of media content

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

Adobe Flash Platform Technical White Paper

13

Fragment Afra
Random access Sample O sets Traf audio, video, hint trun Video track samples Hint track samples

Moof

Mdat Audio track samples

Figure 4. Fragment structure in F4F media.

Multiplexed hint track In 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. Segments A 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 information Bootstrap 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.
Metadata (optional) Servers DRM (data or link) Other asrt (Seg Run Table) seg frag 1 40 10 6

Bootstrap Box (abst)

afrt (Frag Run Table) frag secs 1 2 100 3

Figure 5. Bootstrap information box.

Adobe Flash Platform Technical White Paper

14

Bootstrap information includes the following data:

Bootstrap property
Movie identifier Live Time Update Profile Version Server base URLs DRM metadata Other metadata Segment run table Fragment run table

Description
The identifier of this presentation in the form of a null terminated string. This could be a file or pathname in a URL. Indicates if the movie is live or not. Current media time for live; can be 0 for nonlive. Indicates if this is an update to a previous version of the bootstrap file. Indicates which profile is used (Named access profile is the only available profile at this time). Version number of bootstrap info, or the version this information updates if the update flag is set. The server base URL for this media presentationthis field is not used when F4M files are used. A Base64 representation of metadata or the URL of the license server. This field is not used when F4M files are used. A string containing metadata or the location of additional external metadata. Listing of number(s) of fragments per segmentused to find the segment that contains a sample corresponding to a specific time. Listing of duration(s) of fragmentsused to find a sample corresponding to a specific time.

Sample value
my_movie true/false 0 true/false Named 12345 http://www.example.com 0x2834897 Movie asrt box as defined in the format specification afrt box as defined in the format specification

Random access point Random 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 scheme The 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/QualityModifierSegsegment_numberFragfragment_number

The breakdown of the URL is as follows:

server_and_path qualityModifierSeg segment_number fragment_number Web server path to the content Name used for the multibitrate or trick play files (optional) Number (without leading zeros) associated with the segment 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 format

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

Adobe Flash Platform Technical White Paper

15

As part of Adobes 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 workflow The 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 servers 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 structure The 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
Bitrate information Bootstrap information Moov atom DRM authentication

Description
Media file information for multibitrate delivery Basic information needed to begin playback; can include the bootstrap data itself or a URL to an external file Optional metadata for a media representation 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:
<?xml version=1.0 encoding=utf-8?> <manifest xmlns=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> <drmMetadata url=http://mydrmserver.com/mydrmmetadata/> <bootstrapInfo profile=named url=/mybootstrapinfo/> <media url=/myvideo/medium bitrate=908 width=800 height=600/> </manifest>

Adobe Flash Platform Technical White Paper

16

Bitrate information The 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:
<?xml version=1.0 encoding=utf-8?> <manifest xmlns=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> <drmMetadata url=http://mydrmserver.com/mydrmmetadata/> <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>

Bootstrap information A 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 atom The 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 information The 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 resources
HTTP 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

Adobe Flash Platform Technical White Paper

17

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. Initial information required to begin consuming media. See Atom. Content delivery network. Digital rights management as implemented in Flash Player 10.1. Digital video recorder. Flash Media Manifest file format. 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. A pair of moof and mdat boxes that contain metadata and media data. Hypertext Transfer Protocol. 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. A header that describes a fragment in an ISO/MP4 file. A single container atom whose subatoms define the metadata for a piece of media. 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). A synchronization point in a media file from which media can be played back; usually a keyframe. Real Time Messaging Protocol, the delivery method used by Flash Media Server. A collection of fragments stored as a file or a resource identifiable by a URL. Playing in reverse or fast forward mode or other than conventional forward playing. Video on demand.

Bootstrap Box CDN DRM DVR F4M F4X

Fragment HTTP Mdat atom Moof atom Moov atom Manifest file Random access point RTMP Segment Trick play VOD

For more information

Solution details: www.adobe.com/go/httpdynamicstreaming
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.

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

91030544 9/10

18