AWS News Blog

Amazon CloudFront Now Supports Microsoft Smooth Streaming

Delivering high-quality video or audio content to web and mobile clients is a tricky endeavor. Beyond supporting a multitude of formats and device types, you need to account for frequent and dramatic changes in the quality of each customers Internet connection. Latency, available bandwidth, transmission error rates, and other factors stand to compromise the overall customer experience.

New Support for Microsoft Smooth Streaming
Today we are enhancing Amazon CloudFront with support for the Smooth Streaming protocol. This HTTP-based protocol allows the client application (your video or audio player) to adapt to changing conditions by dynamically optimizing content quality throughout the course of a streaming session. On the server side, content is encoded at multiple bit rates, one MP4 file per bit rate.

With today’s release, CloudFront will recognize and respond to the specially formatted URLs which comprise a Smooth Streaming request. You don’t need to run a streaming server; all of the content is stored in an origin server (Amazon S3 is a great choice) and served up by CloudFront, with high performance, great scalability, and a global network of edge locations.

This release adds Smooth Streaming to the set of video streaming technologies that CloudFront supports, which includes native on-demand streaming using HLS and multi-format live streaming using third party media servers from Wowza and Adobe.

Our colleagues at Amazon Instant Video helped us to design and beta test this feature. Weve tested Microsoft Smooth Streaming through CloudFront using a wide variety of streaming devices, including Kindle Fire HD, and multiple connected TV platforms, while measuring and validating that the end-to-end service continues to deliver a great experience for our customers.

Getting Started With CloudFront Support for Microsoft Smooth Streaming
Here’s what you need to do to get started with Smooth Streaming:

  1. Transcode your video into the Smooth Streaming Fragmented MP4 format using one of the tools listed in the Smooth Streaming Primer provided by Microsoft. At the conclusion of this process you will have a series of files: One MP4 (.ismv for video, or .isma for audio) files per bit rate, a server manifest file (.ism), and a client manifest file (.ismc).
  2. Optionally encrypt and package your content using a Digital Rights Management (DRM) system such as PlayReady.
  3. Upload the files to an Amazon S3 bucket (you can also use other origins).
  4. Create a CloudFront distribution for the origin.
  5. Enable Smooth Streaming by creating a new Cache Behavior and checking Smooth Streaming:
  6. Embed a suitable video player in your web page or your mobile app, and reference the URL of the distribution and the name of the client manifest file.

And that’s it! Once you have done this, your customers will be able to enjoy video and audio playback that adapts and responds to changing conditions.

As the content owner, you can choose to encrypt and package your content using a Digital Rights Management (DRM) technology such as PlayReady

Behind the Scenes
Let’s take a closer look at each of the moving parts required to deliver a Smooth Streaming experience. I’ll start from the customer and work backward to the server (this is a time-honored Amazon.com tradition).

The customer wants to watch a video that you have made available in Smooth Streaming format, and they click the Play button. The video player starts by fetching and processing the client manifest (.ismc) file using a URL like this:

http://video.my-site.com/birthday_party.ism/Manifest

This file describes the video streams that are available to the client. It includes information about codecs, bit rates, video resolutions, markers, captions, and so forth.

The video player selects an initial bit rate. Factors involved in this decision could include network speed and latency, the amount of memory available to the player, and the amount of CPU power available for video decoding and scaling.

The video player tracks the time offset from the start of the video (typically in 100 nanosecond units). It uses the content URL, the time offset and the current bit rate to form a final URL that looks like this:

http://video.my-site.com/birthday_party.ism/QualityLevels(40000)/Fragments(video=461075114)

The final parts of the URL (QualityLevel and Fragments) are specific to Smooth Streaming. The QualityLevel is derived from the desired bit rate and the content Fragments are derived from the presentation time offset. In effect, the URL says “Give me the chunk of video at this time offset, at this quality level.”

The player asks CloudFront for the content at the URL. CloudFront recognizes that Smooth Streaming has been enabled for the distribution which contains the URL and applies special treatment to it. It consults the server manifest (.ism) file to figure out which MP4 file to use and then uses metadata in the manifest to figure out which content to extract and return. This content is retrieved (if not already cached in the CloudFront edge location responsible for handling the request) from the origin and returned to the video player.

The video player decodes, scales, and displays the content. The player will generally retrieve chunks ahead of time, while also tracking changes in operating conditions that might lead to a decision to increase or decrease the desired bit rate.

As you can see, the combination of an intelligent player, a special URL format, the data contained in the client and server manifest files, and the easy access to discrete chunks of video at the desired bit rate all come together to enable Smooth Streaming to work.

Get Going Now
This new feature is available now and you can start using it today! There’s no extra charge for this feature; you’ll pay the same bandwidth and request fees that you would for any other HTTP workload on CloudFront.

To learn more, read about Configuring On-Demand Smooth Streaming in the CloudFront Developer Guide.

— Jeff;

Jeff Barr

Jeff Barr

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.