Tuesday, September 25, 2012

F4X - File - (HDS) HTTP Dynamic Streaming

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.

Monday, September 24, 2012

HDS (HTTP Dynamic Streaming) Workflow (flow) for On Demand Video (VOD)

The best way to experience the workflow for on-demand HTTP streaming is to complete a tutorial. See Stream on-demand media (HTTP).
The following is the workflow for Adobe HTTP Dynamic Streaming and Apple HTTP Live Streaming use cases:
  1. Encode media files and copy them to the rootinstall/webroot/vod directory on Flash Media Server.
    To configure this location, see Configure the location of content (HDS and HLS).
  2. (Optional) To configure multi-bitrate streaming, use the Set-level F4M/M3U8 File Generator tool to generate a set-level manifest file. See Play on-demand multi-bitrate media files over HTTP.
  3. (Optional—Adobe HTTP Dynamic Streaming) To encrypt content for protected HDS (without Flash Access), see Configure protected HTTP Dynamic Streaming (PHDS).
    To encrypt content for use with Flash Access, edit the jit.conf file. See Encrypt content for Flash Access protection.
  4. (Optional—Apple HTTP Live Streaming) To encrypt content for Apple HTTP Live Streaming, configure the jit.conf file or the Apache httpd.conf file. See Protect content for Apple HLS.
  5. Create a crossdomain.xml file and copy it to the rootinstall\webroot folder.
    A crossdomain.xml file allows Flash Player clients hosted on other domains to access data from this domain. For more information, see Website controls (policy files) in the ActionScript 3.0 Developer’s Guide.
  6. (Adobe HTTP Dynamic Streaming) Use Strobe Media Playback to play media. Strobe Media Playback is installed with Flash Media Server.
  7. (Apple HTTP Live Streaming) Play the content on an iOS device or on MacOS.
    For supported devices, see Apple HTTP Live Streaming documentation.

HDS (HTTP Dynamic Streaming) Workflow (flow) for Live media

The best way to experience the workflow for live HTTP streaming is to complete a tutorial. See Stream live media (HTTP).
The following is the workflow for all Adobe HTTP Dynamic Streaming and Apple HTTP Live Streaming use cases:
  1. Use the default live event or create a live event.
    The default live event is rootinstall/applications/livepkgr/events/_definst_/liveevent. Each live event contains configuration settings for one set of content. For more information, see Create and configure live events.
  2. (Optional) To configure multi-bitrate streaming, use the Set-level F4M/M3U8 File Generator tool to generate an set-level manifest file. The set-level manifest file contains information about each stream. See Publish and play live multi-bitrate streams over HTTP.
  3. (Optional) To configure DVR for Adobe HTTP Dynamic Streaming, create a set-level manifest file.
    To configure a Sliding Window for Apple HTTP Live Streaming, configure the httpd.conf, Application.xml, or Event.xml file.
    See Configure DVR (HDS) and Configure a sliding window (HLS).
  4. (Optional—Adobe HTTP Dynamic Streaming) To encrypt content for protected HDS, see Configure protected HTTP Dynamic Streaming (PHDS).
    To encrypt content for use with Flash Access, edit the Event.xml file. See Encrypt content for Flash Access protection.
  5. (Optional—Apple HTTP Live Streaming) To encrypt content for Apple HTTP Live Streaming, see Protect content for Apple HLS.
  6. Create a crossdomain.xml file and copy it to the rootinstall\webroot folder.
    A crossdomain.xml file allows Flash Player clients hosted on other domains to access data from this domain. For more information, see Website controls (policy files) in the ActionScript 3.0 Developer’s Guide.
  7. Publish a stream to the server.
  8. (Adobe HTTP Dynamic Streaming) Use Strobe Media Playback to play media. Strobe Media Playback is installed with Flash Media Server.
  9. (Apple HTTP Live Streaming) Play the content on iOS or MacOS.
    For supported devices, see Apple HTTP Live Streaming documentation.

HDS (HTTP Dynamic Streaming) Components

The Adobe HTTP Streaming solution contains the following components:
Live Packager
Live Packager is a Flash Media Server application installed to rootinstall/applications/livepkgr. The server ingests a live stream over RTMP and the Live Packager translates it into F4F files and MPEG-2 TS files in real-time.
F4F HTTP Module
An Apache HTTP Server module that serves files to Flash Player and AIR. The F4F module (also known as the HTTP Origin Module), serves live content. It also serves on-demand content that was packaged offline with the File Packager tool. The F4F HTTP Module installs with Flash Media Server 4 and later to rootinstall/Apache2.2/modules/mod_f4fhttp.so. The module is also available from adobe.com as a stand-alone Apache module.
HLS HTTP Module
An Apache HTTP Server module that serves files to iOS devices and Mac OS. The HTTP HLS Module installs with Flash Media Server 4.5 and later to rootinstall/Apache2.2/modules/mod_hlshttp.so. It is not available as a stand-alone Apache module.
JIT HTTP Module
An Apache HTTP Server module that packages on-demand files just-in-time and serves them to Flash Player and AIR. “Just-in-time” means that media files are packaged in real-time when clients request them. The JIT HTTP Module installs with Flash Media Server 4.5 and later to rootinstall/Apache2.2/modules/mod_jithttp.so. It is not available as a stand-alone Apache module.
File Packager
A command-line, offline tool that translates on-demand media into F4F fragments. The File Packager is located in the rootinstall/tools/f4fpackager folder and is available from adobe.com.
OSMF media players
There are several media players built on the Open Source Media Framework (OSMF) that support HTTP Dynamic Streaming to Flash Player and AIR. See Pre-built media players.
F4F File Format Specification
The F4F file format describes how to divide media content into segments and fragments. The Live Packager, the File Packager, and the JIT HTTP module output content based on this specification. Each fragment has its own bootstrap information that provides cache management and fast seeking. For more information, see F4F File Format Specification.
F4M File Format Specification
The Flash Media Manifest file format contains information about a package of files that the HTTP Origin Module can serve. Manifest information includes codecs, resolutions, and the availability of files encoded at multiple bit rates. Manifest information also includes DRM data. The media player uses the F4M file to play a piece of media. For more information, see F4M File Format Specification.
Flash Access
Flash Access delivers protected media to Flash Player. To use HTTP Dynamic Streaming with Flash Access, use the File Packager and Flash Media Server to both package and encrypt content. For more information, see Protecting content with Flash Access.Flash Media Server 4.5 adds support for Flash Access level protection without using a Flash Access server. See Configure protected HTTP Dynamic Streaming (PHDS) and Configure protected HTTP Live Streaming (PHLS).

Thursday, September 20, 2012

Fragmented MP4 Format - fMP4 - F4F - Adobe and Microsoft thoughs adoption

Two companies that contributed to this white paper—Adobe and Microsoft—shared thoughts on
their journey towards fMP4.

For more than a decade, that business centered on the Real-Time Media Protocol (RTMP) that Adobe launched back in 2001 with Flash Player 6. RTMP stood at the heart of Adobe Flash Media Server (FMS) and many de facto workflows sprung up around the protocol, although it was extended over the years to address encryption (RTMP-E) and peer-to-peer delivery (RTMFP).
One such enhancement to FMS was a precursor to Adobe’s foray into HTTP delivery. Back in December 2009, with the release of FMS 3.5.3, Adobe essentially decoupled the buffer from the connection, allowing semi-stateless connection between player and server and empowering Flash Player to continue play back even if the connection dropped. Developers can use ActionScript to
reconnect to Flash Player to FMS and, if reconnection occurs before the buffer empties, there is no perceived disruption in client playback, critical for mobile video delivery on intermittent networks.
Adobe saw opportunity to provide similar workflows for devices that did not use its Flash Player plug-in. In 2010, Adobe announced Adobe HTTP Dynamic Streaming (HDS), an HTTP-based adaptive streaming approach that built on fMP4 as its base protocol.
“This is a very different approach than our RTMP delivery with Adobe FMS, which uses normal FLV or MP4 (F4V) file formats,” said Kevin Towes, Adobe’s senior product manager for delivery. “The MP4-Fragment format [Adobe calls it F4F] adheres to the industry standard which is important for re-usability. The format also enabled a major requirement for media streaming – protection—
allowing you to deliver your live or pre-recorded content, leverage the caching devices, and still maintain control over your video assets.”
As part of the new Flash Media Server, announced in September 2011, Adobe enhanced support for both manifest (F4M) and fragment (F4F) file formats. Adobe uses an XML-based solution it calls F4M version 2, similar in concept to a variant playlist in what Adobe calls “set level manifests”.
“Workflows in RTMP have more than a decade of robustness behind them,” said Towes, “but the same workflows haven't been as easy in HTTP. Our investment into the HTTP workflows—bringing them on par with RTMP workflows—allows established FMS customers to maintain their sizable desktop/laptop viewer base while also pursuing new iPad and other iOS device revenue streams.”
Modifications to F4F allow real-time packaging, protection and features such as variant playlists to act on par with RTMP-based workflows. For encryption, FMS encrypts F4F fragments within FMS, using either a built-in Flash Access encryption module or a stand-alone Flash Access server.


Adobe emphasizes the point that fMP4 natively allows for network optimization and content encryption, but it also notes that different devices require different optimizing tweaks for delivery. Leveraging FMS for both desktop and mobile devices, including creation of HLS-based transport streams, Adobe feels it can supply content to every device at optimal resolutions and bandwidths. Seeking is one such area: given the ability to identify and deliver a byterange via fMP4,  Adobe can bring its “seek” enhancement from RTMP directly into an HTTP delivery scenario. When enabled, seeking occurs first within the buffer,  significantly reducing the load on the server compared to traditional back-and-forth seeks between client and server. The duration of the buffer can be dynamically changed, something not currently possibly in MPEG-2 TS solutions, to allow for pseudo-DVR functions such as instant replay or simple time-shifting options within the player. This also allows playback at different speeds and frame-accurate stepping from scene to scene. “We try to help broadcasters realize new revenue streams,” said Adobe’s Kevin Towes, “regardless of platform being delivering to. Where Flash Player is available, we'll use RTMP or HTTP Dynamic Streaming to deliver world-class quality of experience, encryption and rights management. With other platforms, such as iOS-based devices, we'll do an equally good job. Adobe also sees the benefit of standards-based approaches like the Common File Format, HTML5 and  MPEG-DASH.”


Microsoft. Microsoft had a significant installed Windows Media® user base for well over ten years. Yet the company announced in late 2008 it was moving toward fragmented MP4 with the launch of Smooth Streaming, a first-to-market adoption of fMP4. Smooth Streaming combines Windows Server® and Silverlight® (or other Smooth Streaming clients) with XML and SMIL manifests.
Manifests have an *.ismv extension. Manifests indicate to an adaptive streaming client what bitrates are available in a file set, where fragments reside, and header parameters from each video file. Microsoft stores like-bitrate "chunks" of video as movie fragments in a single file, using timecode information stored in each movie fragment (moof) as an index for particular segments to download
and play back. Smooth Streaming devices download movie fragments containing either a video closed Group of Pictures (GOP) or an integral number of audio sync frames, via a single HTTP request. The player than select segments (typically 2-4 seconds long) from multiple streams encoded with different bitrates, resolutions, languages, etc.
What were Microsoft’s reasons for choosing fMP4 over ASF? The company notes five:
• MP4 is a lightweight container format with less overhead than ASF
• MP4 is easier to parse in managed code (.NET) than ASF
• MP4 is itself a widely used standard, making 3rd party adoption / support more straightforward
• MP4 was architected with H.264 video codec support in mind
• MP4 was designed to natively support payload fragmentation within the file

“The MPEG-4 fragmented format was able to do everything we needed,” wrote Ben Waggoner, principle program manager at Microsoft, “so it was simplest to just use that rather than make up something new. We're not trying to make up a new file format here; just take advantage of existing technologies in a novel way.”
“ASF was a great format for bit-pumping,” wrote Waggoner in 2009, “with a MIPS-per-Mbps ratio better than other formats of its era. However, it simply wasn't well set up to allow a byterange to encapsulate a fragment that could potentially be a single closed GOP. Since server hardware is so much more powerful these days and proxy caching so dramatically reduces the load on the origin server, going for a somewhat more complex server-side parsing methodology made good sense.”
Microsoft chose to go “all in” around the standard, including use of *.ismv and *.mp4 extensions. What have they done with Smooth Streaming since its announcement in 2008? Quite a lot, actually. Smooth Streaming has seen significant traction with Silverlight, but doesn’t require Silverlight to deliver adaptive bitrate HTTP streaming, as evidenced by Smooth Streaming clients such as the Comcast® XFINITY® TV App for iOS devices and Linux-based  Netgem set-top boxes. Such non-Silverlight clients can be created using a Smooth Streaming client source-porting kit from Microsoft that enables playback on any device.
In addition, publication of a Smooth Streaming specification, called PIFF (protected interoperable
file format) has been adopted—along with Microsoft PlayReady® DRM technology—for use in new Netflix ready devices and applications, including the Apple iPad. Microsoft has also enabled several compelling scenarios—including advertising and alternate language tracks—on top of fMP4. In addition, the Microsoft ecosystem surrounding the Smooth Streaming format includes two key tools: Expression® Encoder for live- and on-demand Smooth Streaming encoding and IIS Media Services. The latter rides on top of the Microsoft Internet Information Services (IIS) web server that ships in every version of Windows Server 2008.
Another very interesting part of the workflow, that I’ve covered for several trade publications as well as the Workflowed blog, is IIS Transform Manager, a server-side transcoding and transforming tool. Transform Manager can convert a variety of formats, including segmented .mp4 files, to Smooth Streaming presentations. It can also convert Smooth Streaming content for use on Apple iOS devices, converting from fMP4 to HLS (MPEG-2 TS) as part of its standard workflow. Transform Manager scales out on multi-core HPC clusters, plus allows audits of all file copies/movement to improve monitoring/management control.
Microsoft is committed to supporting the standards-based approach, including the Common File Format (CFF), Common Encryption (CENC) and the MPEG-DASH adaptive delivery over HTTP.

Wednesday, September 19, 2012

Difference between HTTP Dynamic Streaming and RTMP 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.


F4F File Format Specification

The F4F file format describes how to divide media content into segments and fragments.
Each fragment has its own bootstrap information that provides cache management and fast seeking. For more
information


see F4F File Format Specification
at Adobe site.