Windows Azure Media Service (Media Service) is one of the newest service offering on Windows Azure platform. I haven’t really looked at it till now (thanks to Brent Stineman for pushing me ) and in next few blog posts, I will share my understanding of this service, what it can do for you and how you can make use of it. Since my ultimate interest is in understanding the REST API for managing this, mostly I will talk about them (if I ever get to that ).
This blog post is introductory blog post about what this service is, how you can sign up for this service and explanation of some of the processes and terminology. This post will become the foundation of subsequent posts (so wish me luck!!!)
What is Windows Azure Media Service (Media Service)?
This is how it is defined on MSDN website (http://msdn.microsoft.com/en-us/library/windowsazure/hh973632.aspx):
Windows Azure Media Services form an extensible cloud-based media platform that enables developers to build solutions for ingesting, processing, managing, and delivering media content. Media Services are built on the infrastructure of Windows Azure (to provide media processing and asset storage), and IIS Media Services (to provide content delivery).
If we look at the definition, a few things stand out:
- an extensible cloud-based media platform
- ingesting, processing, managing and delivering media content
- built on the infrastructure of Windows Azure and IIS Media Services
To understand the significance of this, let me share a story with you (and this is a real story ).
A few years ago, a cousin of mine had an idea of broadcasting events live on the Internet. His idea was to broadcast events like weddings and birthday parties and other personal events over the Internet. Take the scenario if someone close to you in your family is getting married and for some unfortunate reason you’re not able to attend the wedding in person. My cousin’s idea was to provide a platform so that the wedding can be broadcasted live over the Internet so that you can watch the events in real-time as they occur instead of watching a DVD of the wedding later.
Anyways, he was supercharged about this idea and we discussed this idea in great detail. While I could see some sentimental value in this business but the barrier to entry was the requirement of massive technical infrastructure that would be needed to achieve this. He would need massive computing power to process the media and then once the media is processed he would need huge bandwidth to broadcast this event. Furthermore, if you’re aware of wedding scenarios in India they happen only at a certain times of the year thus he would need to be prepared for high traffic during the “wedding” season and then somehow justify the cost of infrastructure he would have acquired to accommodate this high traffic when his business is going through lean season.
Needless to say, I advised him to drop the idea and eventually he did.
Now let’s take the same scenario with this service in picture. With this service, he will be able to process the media without investing in the infrastructure needed for that purpose. Again for the delivery of the media, he can make use of this service (either through Windows Azure CDN with Windows Azure Blob Storage or Partner CDN
or with Windows Azure Blob Storage) so that he need not invest in procuring really high speed Internet in his infrastructure. Again because this is built on Windows Azure Platform and the basic premise is that you only pay for the resources you consume, he need not worry about what to do with the infrastructure during lean season because simply he doesn’t own any infrastructure. Also during peak season, he can scale out thanks to the elastic nature of Windows Azure.
Based on this, if he were to come to me with this idea today, I would have told him to go ahead with it .
So what’s Media Service??? Essentially if you’re in a business where you want to either process and/or deliver media content but were worried about the scalable infrastructure requirement, Media Service is the answer for you. Think of it as a Platform as a Service (PaaS) for Media-based applications.
With Media Service, Microsoft has again lived up to its’ promise they made when they launched Windows Azure:
You (as a business owner/developer) focus on solving business problems, leave the platform to us (Microsoft).
This obviously opens up a lots of possibilities for developers/entrepreneurs like us. Some of the things I could think of (just thinking out loud):
- Build your own version of YouTube or Vimeo to serve user generated content.
Build something like Spotify.Update: Based on the feedback from Media Service team, this scenario is currently not covered.
- If you’re an independent film maker, you could use this platform to process your movies/content.
and many more .
At the time of writing of this blog post, this service is in Preview mode (or in beta phase in other words). Thus you would need to enable this service for your subscription. To do so, please visit accounts section in Windows Azure Portal (https://account.windowsazure.com) and after signing in using your Live Id, click on “preview features” tab.
You should see the list of preview services. Click on “try it now” button next to Media Services.
On the pop-up window you will see all the subscriptions associated with your Live Id. Please select appropriate subscription and click OK button.
Once this feature is enabled under your subscription, you will receive an email and then you can start using this service. I got my notification email in about 10 minutes but if you don’t receive an email in 10 minutes, give it a day or so before contacting support. For some of the services, I had to wait for a day or so.
One important note:
Since this service is in preview mode, you would need to activate it individually for each subscription. For example, if you have 2 subscriptions (say one personal and one official), you would need to repeat the steps for both of your subscriptions.
This is applicable to all services which are in preview mode currently like this and Windows Azure Websites etc.
Let’s take a moment and understand some of the terms used in context with Media Service. Most of the definitions are copied from MSDN site: http://msdn.microsoft.com/en-us/library/windowsazure/hh973632.aspx
An asset is a logical entity which contains information about media. It may contain one more files (audio, video etc.) which needs to be processed.
Delivery is the operation of delivering processed media. This may include streaming content live or on-demand to clients, retrieving or downloading specific media files from the cloud, deploying media assets on other servers such as an Azure CDN server, or sending media content to another provider or delivery network.
A File is an object containing audio/video blob to be processed. Files are stored in Windows Azure Blob Storage. A file is always associated with an asset and as mentioned above, an asset can contain one or more files.
Ingestion is the process of bringing assets into Media Service. This include uploading files into blob storage and encrypting assets for protection.
A job is again a logical entity representing the work to be done on assets and files. The work is performed by one or more tasks (described below). In short we can say that a job is a collection of tasks. For example, you could have a “Encoding” job which encodes an input file into multiple formats (each task is responsible for converting a file in a specific format).
Managing is the process of managing assets which are already in Media Service(i.e. ingestion process has been done on them). This may include listing and tagging media assets, deleting assets, editing assets, managing asset keys, DRM key management, and checking account usage reports.
This to me is the most important operation in Media Service. This operation involves working on your ingested assets and performing encoding, converting them or creating new assets out of existing assets. This also includes encoding and bulk-encoding assets, transmuxing assets (transmuxing means changing the outer file or stream format that contains a set of media files, while keeping the media file contents unchanged), creating encoding jobs, creating job templates and presets, checking job status, cancelling jobs, and other related tasks.
A task is an individual operation to be performed on asset or file. A task is always associated with a job.
As the name suggests, access policies define the permissions on an asset or a file. The permissions can be access type (read/write/delete/list/none) and the duration for which the access type is valid.
A locator is a URI which provides time based access to an asset. It is used in conjunction with an access policy to define the permissions and duration that a client has access to a given asset.
If you have a job that you wish to perform repeatedly, you can create a template for that job and reuse that template so that you don’t end up creating a new job from scratch. It is essentially a collection of task templates (defined below).
At times you may want to protect assets in Media Service by encrypting them. Content keys store the data which is used for encrypting an asset.
A task template basically provides a template that you can use for a task which you perform repeatedly so that you don’t end up creating a new task from scratch. A collection of these task templates create a job template.
Basically your media application goes through these 4 operations/processes:
Ingest –> Process –> Manage –> Delivery
Please see the section above for explanation of these operations.
Some Useful Links
You may find these links useful when working with Media Service:
Mingfei Yen’s Blog: She is a PM on Media Service team and has written excellent blog posts on the same.
Nick Drouin’s Blog: Like Mingfei, Nick is also a PM on Media Service team and has written excellent blog posts on the same.
Well, this is the start of hopefully a long and fruitful journey exploring Media Service. I hope you have found this information useful. As always, if you find some issues with this blog post please let me know immediately and I will fix them ASAP. In the next post, we’ll start exploring some of the APIs (REST and hopefully managed too).
So long and stay tuned!