Windows Azure is a constantly evolving platform. What makes it more attractive, in my opinion, than the competition, is that Microsoft is constantly building and expanding the set of ready to use services around the platform. These are some of the services that form the Windows Azure ecosystem: Windows Azure Mobile Services, Windows Azure Active Directory, HDInsight Service (preview), Windows Azure Media Services and others. It is really hard to keep track of all the additional ready-to-use services that are built around the Microsoft Cloud Platform. In this article we will focus on Windows Azure Media Services or just Media Services.
In its current state Media Services provide a flexible and scalable platform for Video-on-Demand (VOD) solutions, which includes media ingesting, media transformation, and media delivery. As with all of Windows Azure services, Media Service has a REST-based API. You can go through the detailed documentation on the REST API here. There are, of course developer SDKs to help out with Media Services. The Media Services SDK is currently available on the .NET and JAVA platforms.
Because media is a special domain, when working with Media Services you have to cover or consider both the Server and Client sides. While a simple website can be visualized in a single common container – the Web Browser, it has only one state of representation – HTML or XML with applied styling. This is certainly not the case with Media. Depending on the platform on which we want the media to be delivered, there are different options/techniques/formats that must be matched.
To help developers reach the widest audience, the Microsoft team has released a number of additional SDK packages for the client platforms, for example:
- Smooth Streaming Client SDK for Windows 8 (modern UI),
- Smooth Streaming Plugin for OSMF (allowing Flash client to play smooth streaming media),
- Azure Media Service iOS Media Player Framework (to deliver media to iOS devices)
- Smooth Streaming Client SDK for Silverlight and Windows Phone.
You can find out more about available SDKs and documentation on the official Windows Azure Media Services SDK page here.
To start working with Media Services you will need to have an active Windows Azure subscription. If you don’t, now is the right time to get started! You can get a free trial here. Once you have your subscription, go to the Azure Management portal and hit the big plus sign at the bottom. Choose App Services, then a Media Service. A Media Service account is tightly coupled with one (or more) storage accounts. If you already have a storage account, you may choose to assign it to your new Media Service account. Or, you can select the option to create a new storage account for your media service:
Wait a few moments and you are ready to rock! Now that your Media Service is created you can start playing around with it. You can quickly upload some media files directly from management portal and see the results directly there.
About Media Services
Before we start programming, let’s make clear some of the core concepts and terms you will encounter when working with Media Services. As I already mentioned, Media Services is exposed over REST API. The authentication is handled by an OAuth tokens. For this purpose two authorization keys are automatically created and associated with your Media Service account. Very much like the authorization keys for Azure Storage Account. You can get your authorization keys from the Dashboard of your media service account:
Once you get your token and are authorized to work with a Media Service account, you will have to work with the following entities:
- Asset – this is a set of files that have same contextual meaning. An asset may have just a single file, for example single MP4 video file. Or a multiple files – different MP4 video files, which represent same motion movie, but have different bitrates, additional thumbprints of the movie and an XML file manifesting the content of the Asset;
- File – file in Media Services represents a single file within an Asset;
- Access Policy – strictly defined access policy for accessing your media. You can define Read/Write/Delete/List or any combination of them, and an effective Start Date Time and Expiry Date Time;
- Locator – defines and endpoint for accessing an Asset. A Locator is tightly associated with an Access Policy, meaning that we must first create an Access Policy before creating a locator (or lookup an existing and valid Access Policy);
- Media Processor – there are a few media processors available for your Media Service. One is dedicated to media transcoding, another is for media encryption, third for media packaging and so on. The list changes overtime, so you’ll need to look up the list of Media Processors available for your Media Service account using the List MediaProcessors action on the Rest API (or developer SDK);
- Task – task represents a single operation over your Asset. It is important to understand that Task is executed over the whole Asset (input Asset) and generates a whole new Asset (output Asset). That single operation may be video transcoding, or asset encryption, or thumbnails extracting etc.;
- Job – job is a set of tasks. You can link up multiple tasks in a single job. The job can then execute tasks in parallel (if there are no dependencies between the separate tasks) or in serial (if tasks are dependent on each other – say the output Asset from one task in used as an input asset for the other). Media services manages task dependencies automatically so you don’t have to worry about this;
- NotificationEndPoint – when you submit jobs to Media Service, you can instruct it to send message to Azure Storage Queue (not Azure Service Bus Queue!). Be warned: when using this feature, the notifications are not sent in real time! There might be delay of up to 15 minutes between job status change and message submitted to the Queue;
- Origin – this is the service that will stream your media. You can work with “shared” origins, or you can reserve dedicated origin units. If you want to do Smooth Streaming with Dynamic packaging, you will need at least one reserved origin unit.
While Asset and Access Policy are very straightforward to work with, we have to pay attention to the Locators. Locators can be of different types: OnDemandOrigin or SAS (coming from Shared Access Signature). Because of tight coupling between Media Services and Azure Storage services, you cannot have more than five unique SAS locators associated with a single Asset. Make a note – every time you need a locator for an asset, first check if there’s already a valid existing locator before creating new one. A good practice is to delete expired locators while looking up a valid one. Often you have additionally manipulate the locator URI to make it usable for a specific file within the asset. For SAS locators for example you have insert the concrete file name between the host and the signature (refer to Shared Access Signatures for Blob Service here).
So what can we do with Azure Media Services?
First and foremost we can transcode media files. One example of transcoding is when we upload (ingest) the movie taken with a Smart Phone or Camcorder and want to convert it to a format that will be played on greatest variety of devices and bandwidth. This format is known as Smooth Streaming in Microsoft world and Apple HTTP Live Streaming (or just HLS) is iOS/Mac world. In either way you need to produce multiple files with different bitrates to support better end user experience. Using Azure Media Encoder will help you achieving this goal. You can use any of the “H264 Adaptive Bitrate MP4 Set XXX” task presets to create a job. Full list of available task preset is available here. Using a “H264 Bitrate MP4 set” family task will create multiple MP4 files using H.264 Video encoding and AAC Audio encoding with different bitrates. However, Smooth Streaming and Apple HLS streaming manifest the content in different ways.
Next – deliver your media to millions of users. There are couple of ways you can use to to deliver your media. First and easier on is to use dynamic packaging. This means that Windows Azure Media Services will dynamically generate the manifest for delivering the Asset to the right device in the right format. This will ease you in managing your assets. However having dynamically packaged content requires you to have a reserved origin unit (additional charge per unit hour). If you don’t want to pay the additional fee for a reserved origin unit you can “pre-package” your media for the both different formats – Smooth Streaming and HLS. Pre-packaging your media means you will have to manage two separate assets – one for Smooth Streaming and one for Apple HLS streaming; both assets will present the same content. If you want to go that way, you’ll have to first create the Smooth Streaming asset using any of the “H264 Smooth Streaming XXX” task preset. This will be your Smooth Streaming Asset and you can use it for your Smooth Streaming clients (Windows 8/modern UI, Windows Phone, Silverlight, Flash). Next use the Windows Azure Media Packager to package this asset into Apple HLS format. You have to use the XML definition for the task “Convert Smooth Streams to Apple HLS”, which you can grab from the online documentation here. Please note that this conversion will only work over H.264 based smooth streams! It will fail on VC1 based smooth streams!
Finally, you can chose to encrypt your media assets so that no one else could read them, unless they have a proper license. This process is also known as Digital Rights Management, or simply DRM. The process is really easy, but you will need a DRM service provider. Windows Azure Media Services provides the platform for ingesting, storage, managing and delivering the assets. But it does not provide the platform for full DRM protection. You can test protecting/encrypting your media with Microsoft PlayReady Test Server here. You have to use the Windows Azure Media Encryptor processor from Azure Media Services and create a task with the task preset for PlayReady protection, which you can take from this online resource
Windows Azure Media Services provides a fully-featured media management platform for Video-On-Demand solutions. Covering the full media lifecycle management – from ingesting media to delivering encrypted and digitally protected media to millions of end users and great variety of devices. You can start with standard small fee and scale out on demand.