| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
HTTP Dynamic Streaming on the Adobe Flash Platform
August 21, 2011 | By Adobe
코멘트 (0)
8

[Table of contents] Introduction Overview of HTTP Dynamic Streaming HTTP Dynamic Streaming tools Open Source Media Framework Protected streaming powered by Flash Access Deployment options for HTTP Dynamic Streaming HTTP Dynamic Streaming use cases HTTP Dynamic Streaming file formats Online resources Glossary

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
Transcript
Adobe Flash Platform Technical White Paper
HTTP Dynamic Streaming on
the Adobe® Flash® Platform
Enabling 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.
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 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 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
Adobe Flash Platform Technical White Paper 2
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 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
Adobe Flash Platform Technical White Paper 3
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 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.
Adobe Flash Platform Technical White Paper 4
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 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 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 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.
Adobe Flash Platform Technical White Paper 5
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 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 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 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
Adobe Flash Platform Technical White Paper 6
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 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 7
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 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 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 8
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 combination
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 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 9
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 10
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).
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 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 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 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.
Adobe Flash Platform Technical White Paper 11
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 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 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 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.
Adobe Flash Platform Technical White Paper 12
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 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+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.
.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) 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 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.
Adobe Flash Platform Technical White Paper 13
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).
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
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 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
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 14
Afra
Fragment
Random access
Sample
Osets
Moof Traf – audio, video, hint
trun
Mdat
Video track samples
Audio track samples
Hint 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) Bootstrap Box (abst)
Servers
DRM (data or link)
Other
asrt (Seg Run Table)
seg frag
1 40
10 6
afrt (Frag Run Table)
frag secs
1 2
100 3
Figure 5. Bootstrap information box.
Adobe Flash Platform Technical White Paper 15
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 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/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 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 16
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 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 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 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 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:
<?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 17
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
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 information
Solution details: www.adobe.com/go/httpdynamicstreaming
Adobe Systems Incorporated
345 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
View All (815)
4G (2) 4G Evolution (1) 5G (35) 5g (1) 802.11 (1) 802.1X (1) ALTO (1) ANDSF (1) AT&T (2) Acceleration (1) Adobe HDS (3) Akamai (6) Amazon (3) Apple HLS (4) Authentication (1) BRAS (2) BT (1) Backbone (4) Backhaul (12) BitTorrent (1) Broadcasting (3) C-RAN (13) C-RAN/Fronthaul (12) CCN (4) CDN (52) CDNi (1) COLT (1) CORD (1) CPRI (2) Cache Control (1) Caching (5) Carrier Cloud (2) Carrier Ethernet (9) Channel Zapping (4) China Mobile (1) China Telecom (1) Cloud (10) Cloudfront (1) DASH (2) DCA (1) DHCP (3) DNS (1) DSA (1) Data Center (7) Dynamic Web Acceleration (1) EPC (5) Energy (1) Ericsson (5) Ethernet (8) FEO (2) Fairness (1) Fronthaul (5) GiGAtopia (1) Gigabit Internet (2) Global CDN (1) Google (5) HLS (1) HTTP (1) HTTP Adaptive Streaming (18) HTTP Progressive Download (3) HTTP Streaming (1) HetNet (1) Hot-Lining (1) Hotspot 2.0 (2) Huawei (3) ICN (4) IP (1) IP Allocation (1) IP Routing (8) IPTV (15) Intel (1) Internet (1) Interoperability (2) IoST (1) IoT (14) KT (22) LG U+ (3) LTE (70) LTE MAC (1) LTE-A (2) Licensed CDN (1) M2M (3) MEC (2) MPLS (25) MVNO (1) Market (4) Metro Ethernet (7) Microsoft (2) Migration (1) Mobile (4) Mobile Backhaul (1) Mobile Broadcasting (1) Mobile CDN (2) Mobile IP (1) Mobile IPTV (3) Mobile Video (1) Mobile Web Perormance (1) Mobility (1) Multi-Screen (7) Multicast (7) NFC (1) NFV (2) NTT Docomo (2) Netflix (6) Network Protocol (31) Network Recovery (3) OAM (6) OTT (31) Ofcom (1) Offloading (2) OpenFlow (1) Operator CDN (14) Orange (1) P2P (4) PCC (1) Page Speed (1) Programmable (1) Protocol (7) Pseudowire (1) QoS (5) Router (1) SCAN (1) SD-WAN (1) SDN (15) SDN/NFV (15) SK Telecom (21) SON (1) SaMOG (1) Samsung (2) Security (6) Service Overlay (1) Silverlight (4) Small Cell (3) Smart Cell (1) Smart Grid (2) Smart Network (2) Supper Cell (1) Telefonica (1) Telstra (1) Terms (1) Traffic (2) Traffic Engineering (1) Transcoding (3) Transparent Cache (2) Transparent Caching (14) VLAN (2) VPLS (2) VPN (9) VRF (2) Vendor Product (2) Verizon (2) Video Optimization (4) Video Pacing (1) Video Streaming (14) Virtual Private Cloud (1) Virtualization (3) White Box (1) Wholesale CDN (4) Wi-Fi (13) WiBro(WiMAX) (4) Wireless Operator (5) YouTube (4) eMBMS (4) eNB (1) 망이용대가 (1) 망중립성 (1) 스마트 노드 (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호