I’m very excited about the release of this features in Azure Media Services. In fact, in the past few months there have been several asks from my customers which I personally engaged with.
Jason and Cenk from Media Services team have explained how the feature works in technically details. In this post, I’ll explain it differently, specifically from scenario-driven perspective, follow by the “how-to” with the UI-based Azure Media Services Explorer and also through .NET SDK.
Customer Requirement: Bitrates filtering for different clients (browser-based and native mobile-based)
Imagine that, as an OTT provider, I’ve encoded all my video library with H264 Adaptive Bitrates MP4 Set 720p which has 6 video bitrates (3400, 2250, 1500, 1000, 650, 400 all in kbps).
And here is what I’d like to achieve:
- User connecting through browsers – larger screen (PC-based browsers which typically bigger screen) to only see highest four bitrates (3400, 2250, 1500, 1000 kbps). This is because I want to avoid the end-user to view “blocky” video experience (with 400 kbps).
- User connecting through native apps – smaller screen (Android, iOS, or Windows Phone) to only see lowest four bitrates (1500, 1000, 650, and 400 kbps).
- This could be either the mobile phones are not capable to playback highest bitrates due to screen-size limitation.
- Or this could be because I’d like to save end-users’ bandwidth especially when they’re connecting via 3G or 4G network through their data-plan.
Figure 1: Larger screen vs. smaller screen playback experience
How do we design the most effective media workflow to handle such scenario?
You can definitely produce / encode different assets to serve different purposes: one asset for larger screen (which encoded with 4 highest bitrates), another one for smaller screen (which encoded with 4 lowest bitrates)
Although it works, I don’t think it’s a great idea since you face these challenges:
- Management overhead as you’ve have different physical files / assets / locator URL
- Redundant storage which cause higher storage cost
- Not-future proven: imagine that in the future, you have “paid silver tier” which the user can watch 5 bitrates, you’ll need to re-encoded your library again which can be cumbersome process.
A. Using Dynamic Manifest for Bitrate Filtering through Azure Media Services Explorer (AMSE)
Let me show how you can leverage Dynamic Manifest capability (with AMSE tool) to achieve this. The following step-by-step guide will cover how this can be done in more “elegant” way.
1. Download and install AMSE here if you haven’t done so. Since version 3.24 onward the features have been added. But I’ll still recommend you to use the latest one.
2. Connect to your Azure Media Services account.
3. Prepare your content and encode them with H264 Adaptive Bitrates MP4 Set 720p
(for step 2 and 3, you may refer to Video 1 in this post on how it can be done)
4. Navigate to tab “Global filters” and right click select “Create a global filter…”.
Note: there are 2 types of filters: asset-level and global-level. We’re using global filter in this tutorial.
Figure 2 – Creating a global filter
5. Give the global filter a name, in my example “smallerscreen” and then navigate to “Tracks filtering” tab.
Figure 3 – Track Filtering in creating global filter
6. Although you may add the track rules and conditions manually, I’d recommend you to insert the “track filtering example” and modify from there. To do so, click “Insert tracks filtering example”.
Figure 4 – Defining bitrates in tracks filtering
Notice that in Rule1, the condition of bitrate is 0-1500000, which is 1500 kbps encoding profile I’ve set. Of course you may adjust it accordingly to the bitrates that you’re expecting. Click “Create Filter”.
7. Go back to the Asset tab. Navigate to the asset that you’ve encoded earlier, publish a locator if you haven’t done so. Then right click on the asset and select Playback – with Azure Media Player – with a global filter – smallerscreen.
Figure 5 – Playing back the video with global filter
8. Now you can see that the video is played through Azure Media Player with the following URL:
http://<media services account>.origin.mediaservices.windows.net/<GUID>/<video>.ism/manifest(filter=smallerscreen)
Navigate to the “quality” selection button left to the “sound” icon and notice the quality that the “small scree” user can select.
Figure 6 – Playback experience for smaller screen user
With that URL, you will see that the “smallerscreen” user can only watch the lowest 4 quality (bitrates). Likewise, you may create another filter that indicates “largerscreen” user.
The interesting thing to note here is we only store 1 set of asset in Media Services without having to store multiple times.
B. Using Dynamic Manifest for Bitrate Filtering through .NET SDK
<to be updated>
Although Dynamic Manifest can be used in other use case (such as timeline trimming), this post fill focus on rendition, specifically on bitrates filtering for “larger screen vs. small screen” scenario.
The later part of the post also covers how to create a filter with UI-based tool (Azure Media Services Explorer) and .NET SDK although you can also achieve this with REST-API.
Please find the following post by Jason and Cenk explaining Dynamic Manifest features.
This article is reviewed by
Jason Suess – Principal PM Manager, Azure Media Services
Cenk Dingiloglu – Senior Program Manager, Azure Media Services