Uploading content into Azure Media Services

Previously I’ve introduced the Content Management System (CMS) that’s used to store video details for the video on-demand service, along with details of video encoding jobs. I’ve also explained how to connect to Azure Media Services.

In this blog post I’ll summarise how client apps can upload video to the video on-demand service. For info about the supported codecs and file container formats see Formats Supported by the Media Services Encoder.

Uploading content

To upload content into Media Services you must first create an asset and add files to it, and then upload the asset. This process is known as ingesting content. The content object in Media Services is an IAsset, which is a collection of metadata about a set of media files. Each IAsset contains one or more IAssetFile objects. The approach adopted here is to create an Asset, upload the content to Media Services, and then generate AssetFiles and associate them with the Asset. In order to create an Asset you must first have a reference to the Media Services server context. For more info see Connecting to Azure Media Services.

The following diagram shows a high-level overview of the media upload process used in the Building an On-Demand Video Service with Microsoft Azure Media Services project.

The client apps communicate with the web service through a REST web interface. When a new video is uploaded a new asset is created by Media Services, and the asset is uploaded to Azure Storage before the asset details are published to the CMS. The upload process can be decomposed into the following steps:

1. Create a new empty Asset.
2. Create an AccessPolicy instance that defines the permissions and duration of access to the Asset.
3. Create a Locator instance that will provide access to the Asset.
4. Upload the file that’s associated with the Asset into blob storage.
5. Publish the Asset.
   • Save the Asset details to the CMS.
   • Generate an AssetFile for the Asset.
   • Add the Asset to the encoding pipeline.

For a code walkthrough of this process see Upload process in the Contoso Azure Media Services applications.

Media Services also allows you to secure your content from the time it leaves your computer, by specifying an encryption option as a parameter when creating an Asset. For more info see Securing media for upload into Azure Media Services.

Summary

This blog post has summarised the media upload process from client apps into a video on-demand service that uses Azure Media Services. For more info see Building an On-Demand Video Service with Microsoft Azure Media Services.

In my next blog post I’ll discuss the next step in the Media Services workflow – encoding and processing uploaded media.

Connecting to Azure Media Services

Before you can start programming against Azure Media Services you need to create a Media Services account in a new or existing Azure subscription. For more info see How to Create a Media Services Account. Once you’ve setup a Media Services account you’ll have connection values for the account in the form of the account name and account key. These values can be stored in configuration and programmatically retrieved to make connections to Media Services.

To code against Media Services you create a CloudMediaContext instance that represents the server context. Media Services controls its access to its services through an OAuth protocol that requires an Access Control Service (ACS) token that is received from an authorisation server. One of the CloudMediaContext constructor overloads takes a MediaServicesCredentials object as a parameter, which enables the reuse of ACS tokens between multiple contexts. You could use a constructor overload that ignores ACS tokens, thus leaving the Media Services SDK to manage them for you. However, this can lead to unnecessary token requests which can create performance issues on both the client and server. The following code example shows how to reuse ACS tokens between multiple contexts.

public class EncodingService

{

    private static readonly Lazy<MediaServicesCredentials> Credentials =

        new Lazy<MediaServicesCredentials>(() =>

        {

            var credentials = new MediaServicesCredentials(

                CloudConfiguration.GetConfigurationSetting("AccountName"),

                CloudConfiguration.GetConfigurationSetting("AccountKey"));

            credentials.RefreshToken();

            return credentials;

        });

    public EncodingService()

    {

       this.context = new CloudMediaContext(EncodingService.Credentials.Value);

    }

}

The Credentials object is cached in memory as a static class variable that uses lazy initialisation to defer the creation of the object until it is first used. This object contains an ACS token that can be reused if it hasn’t expired. If it has expired it will automatically be refreshed by the Media Services SDK using the credentials given to the MediaServicesCredentials constructor. The cached object is then used by the EncodingService constructor. It’s particularly important to cache your Media Services credentials in a multi-tenant application, otherwise performance issues could occur as a result of thread contention issues.

When the CloudMediaContext instance is created the Credentials object will be created. Using lazy initialisation to do this reduces the likelihood of the MediaServicesCredentials object having to refresh its ACS token due to expiration. For more info about lazy initialisation see Lazy Initialization.

NDC 2014 – Accelerating Windows Store app development by using Prism for the Windows Runtime

Today I spoke at NDC 2014 about Accelerating Windows Store app development by using Prism for the Windows Runtime. The slides from the talk can be found here. An article I wrote about Prism WinRT can be found in the latest NDC magazine.

The code demos I used are:

• PhotoViewer
• Validation Quickstart

For further resources see:

• Developing a Windows Store business app using C#, XAML, and Prism for the Windows Runtime
• Prism for the Windows Runtime Templates
• Codeplex Site
• Pluralsight Training Course

Thanks to NDC for giving me the opportunity to present, and to all attendees for listening.

Developing the content management system for a video on-demand service

Previously I’ve introduced the architecture of the video on-demand service, and the Windows Phone app that consumes the service through a REST interface.

In this blog post I’ll discuss the Content Management System (CMS) created for the Building an On-Demand Video Service with Microsoft Azure Media Services project.

Designing the CMS

A video CMS enables you to upload, store, process, and publish media, and generally store data in a database that allows for metadata tagging and searching.

The requirements for our CMS were:

• Ability to store details of videos that can be consumed by client apps.
• Ability to store video metadata.
• Ability to store a thumbnail image for each video.
• Ability to store details of video encoding jobs.

We decided to store this information in a series of database tables that were optimized for many of the common queries performed by our client apps. The following diagram shows the database table structure.

The table structure was implemented as an Azure SQL relational database as they offer elasticity that enables a system to quickly and easily scale as the number of requests and volume of work increases. An additional advantage is that Azure SQL databases maintain multiple copies of the database on different servers. Therefore, if the primary server fails, all requests are transparently switched to another server.

Accessing the CMS

A relational database stores data as a collection of tables. However, the Windows Phone app processes data in the form of entity objects. The data for an entity object might be constructed from one or more rows in one or more tables. In the Windows Phone app the business logic that manipulates objects is independent of the format of the data for the object in the database. This offers the advantages that you can modify and optimize the database table structure without affecting the code in the Windows Phone app, and vice versa.

This approach requires the use of an object-relational mapping (ORM) layer. The purpose of the ORM is to act as an abstraction of the underlying database. The Windows Phone app creates and uses objects, and the ORM exposes methods that can take those objects and use them to generate relational CRUD operations, which it then sends to the database server. Tabular data is then returned from the database and converted into a set of objects by the ORM.

We used the Entity Framework as the ORM, and used the Fluent API to decouple the classes in the object model from the Entity Framework. In the Entity Framework the database is interacted with through a context object. This object provides the connection to the database and implements the logic performing CRUD operations on the data in the database. The context object also performs the mapping between the object model of the Windows Phone app and the tables defined in the database.

The Windows Phone app sends REST requests to the video on-demand service, which validates the requests and converts them into the corresponding CRUD operations against the CMS. All incoming REST requests are routed to a controller based on the URL that the Windows Phone app specifies. The controllers indirectly use the Entity Framework to connect to the CMS database and perform CRUD operations. We implemented the Repository pattern in order to minimize the dependencies that the controllers have on the Entity Framework.

The purpose of the Repository pattern is to act as an intermediary between the ORM layer and the data mapping layer that provides the objects for the controller classes. In the video on-demand service, each repository classes provides a set of APIs that enable a service class to retrieve a database-neutral object from the repository, modify it, and store it back in the repository. The repository class has the responsibility for converting all the requests made by a service class into commands that it can pass to the Entity Framework. As well as removing any database-specific dependencies from the business logic of the controller and service classes, this approach provides flexibility. If we chose to switch to a different data store we could provide alternative implementations of the repository classes that expose the same APIs to the service classes.

For more information about the video on-demand service and its use of the Repository pattern see Appendix A – The Contoso Web Service.

Summary

This blog post has discussed why we chose to store the CMS database in the cloud as an Azure SQL database. It has explained how the web service connects to the database by using the Entity Framework, and how the Repository pattern is used to abstract the details of the Entity Framework from the business logic of the video on-demand service. For more information see Building an On-Demand Video Service with Microsoft Azure Media Services.

In my next blog post I’ll discuss how the Windows Phone app uploads video to the video on-demand service.