Customized Renditions and Asset trimming with Dynamic Manifest

As a follow up on Jason’s announcement of our dynamic manifest capabilities last month during NAB, I am pleased to announce that they are now available for you to begin using in your streaming applications. Jason’s post covered many of the common usage scenarios so I encourage you to start there if this is the first time you’re reading about dynamic manifests since here I will primarily focus on technical implementation details. Before going into the details of how it works, I want to provide some background for the following terminologies.

• Adaptive Bit Rate over HTTP (ABR), adaptive bit rate streaming is a method of video streaming over HTTP where the source content is encoded at multiple bit rates and chunked into small multi-second parts. The streaming client is made aware of the available streams at differing bit rates, and chunks of the streams by a manifest file. To meet the subscriber demand for multi-screen and deliver video to any device across any network, operators use adaptive bit rate (ABR) protocols in their multi-screen implementations, such as Apple HLS, Microsoft Smooth, Adobe HDS and MPEG-DASH.
• The manifest, sometimes referred to as “the playlist”. This file includes streaming metadata such as qualities, audio languages, and presentation window and also provides the player currently available as well as next playable fragments with their respective locations. It is a text-based or XML file with specific attributes depending on format.  Using “asset filters” which I’ll describe below you can create a dynamic manifest based on the following properties and attributes.
  • Track type – audio, video, or text
  • Track name
  • Start and end time
  • Presentation window – sliding window of fixed duration, anchored from live position.
  • Bitrate (qualities)
  • Track language
  • FourCC
• Fragments/segments, actual chunks of video, audio or text content.

What is a filter?

Asset filter is a combination of rules based on manifest attributes and timeline which describes the streaming endpoint (backend service) how to manipulate the output playlist (Manifest).

Filter Types

There are two types of asset filters; global and local (asset level). Both of the filter types have exactly the same features and uses the same attributes to define filters. The main difference between the two is the scenarios they are suitable for and also where they are stored.

• Global filters are generally suitable for device profiles (track filtering) whereas local filters are mostly preferred for range filters (trimming), since most of the time trimming is specific to asset.
• Global filters are stored at the account level and when created can be applied to all assets under the account. Local filters are per asset and can only be used for the asset under which they are created. A local filter’s lifetime is tied to the asset lifetime, in other words when the asset is deleted all local filters created on it are also deleted.

How it works?

Filters can consists of multiple rules. As an example you can define remove slate and apply back-off over a live playlist (manifest) as well as include removing qualities to the combination. For multiple filtering rules the end result is the composition (intersection only) of the rules.

Creating Filters through Our APIs

Asset filter API is available for Azure Media Service REST version >= 2.11. This release includes only REST APIs and a corresponding .NET SDK is underway which is targeted for following weeks.
You can find more information regarding to Azure Media Services REST from here.

Asset filters consist of two sections (groups); PresentationTimeRange and Tracks.

PresentationTimeRange:

Tracks:

Note: Azure Media Services dynamic packager can source from multi-bitrate MP4 and Smooth Streaming files. Dynamic manifests(asset filters) uses Smooth Streaming server and client manifest data for filtering. Please also note that you should have at least one streaming unit to use this feature.

Sample Global filter REST request: