About Windows Azure Media Services

From an application development perspective, the Media Services architecture has several key components. The following diagram illustrates the layers of Media Services.

Important
This diagram illustrates the long-term design for Media Services. Not all components in the diagram are available in the current release.

There are two categories of Media Services developers.

• Independent Software Vendors (ISVs). ISVs build end-to-end media management services. These developers can access Media Services through the REST API layer as seen in the diagram. There are two main options for accessing the REST API: by using ODATA (which can be called directly over HTTP from various languages and applications, including web pages), or by using the Windows Azure Media Services SDK for .NET (which wraps the REST API calls and simplifies the process of building a .NET based Media Services client application).
  
  
• Partners. Partners build Media Services add-on components that run as part of the platform. These add-ons can be used by ISV's as they develop their end-to-end services. For Partners, a Windows Azure Media Services Platform SDK for .NET is available to develop add-ons.
  
  

The REST API is the public, programmatic interface for accessing Media Services. REST (for Representational State Transfer) is an architectural strategy for building networked client-server applications. REST relies on a stateless, cacheable, standard protocol (HTTP) to send information between networked machines. Machines in a REST application can use HTTP requests to carry out typical data operations such as reading (equivalent to a GET), writing (equivalent to a POST), or deleting data over the network. As a Media Services developer, your application calls into the services layer by using the REST API. As described previously, ISVs will call into the REST API by using either ODATA, or by using the Media Services SDK.

In a typical media management application, there are four basic types of operations for working with media assets, and these operations make up the application workflow. Media Services provide full support for each operation in this workflow.

• Ingest. Ingest operations bring assets into the system. This includes uploading media content and encrypting assets to protect their contents.
  
  
• Process. Processing operations involve encoding, converting, and generating media assets. This 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.
  
  
• Manage. Management operations involve working with assets that are already in Media Services. This includes listing and tagging media assets, deleting assets, editing assets, managing asset keys, DRM key management, and checking account usage reports.
  
  
• Deliver. Delivery operations enable you to get media content back out of Media Services. This includes 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.
  
  

When ISVs access Media Services programmatically (using ODATA, or using the Media Services SDK), they will find that Media Services has a number of fundamental objects for working with media content. These objects are called entities. The following table summarizes the main Media Services entities.

Entity	Description
Assets	An asset is a virtual entity that holds metadata about media. An asset may contain one or many files.
Files	A file is an actual video or audio blob object on the file system or on a remote server. A file is always associated with an asset, and an asset may contain one or many files that are part of a collection.
Jobs	A job is an entity that holds metadata about tasks. The tasks perform work on assets and files, and a job can create new assets or files. A job always has one or more associated tasks.
Tasks	A task is an individual operation of work on an asset or file. A task is associated with a job.
AccessPolicies	An access policy defines the permissions to a file or an asset (what type of access, and the duration).
Locators	A locator is a URI that provides time-based access to a specific asset.
JobTemplates	A job template provides reusable settings for jobs that you want to run repeatedly. A job template is composed of a collection of task templates. Note This entity is not supported in the current release of the Media Services SDK. You can, however, use this entity if you are programming with the REST API. See the Windows Azure Media Services REST API Reference.
ContentKeys	A content key stores key data that is used to encrypt an asset.
TaskTemplates	A task template provides reusable settings for tasks that you want to run repeatedly. Each job template has a collection of task templates. Note This entity is not supported in the current release of the Media Services SDK. You can, however, use this entity if you are programming with the REST API. See the Windows Azure Media Services REST API Reference.

Concepts

Other Resources