Wednesday, 28 May 2014

Architecture of a video on-demand service that uses Azure Media Services

Previously I’ve explained that Azure Media Services provides everything you’ll need to build and operate video on-demand services to multiple devices and platforms, including all the tools and services you’ll need to handled media processing, delivery, and consumption.

In this blog post I’ll examine the architecture of a video on-demand service created with Media Services for the Building an On-Demand Video Service with Microsoft Azure Media Services project. As the guide focuses on the Windows Store app developed for the project, I’ll focus on the Windows Phone app.

Understanding the video on-demand service architecture

Building and hosting a video on-demand service can be a major undertaking and can require a significant investment in hardware, management, and other infrastructure resources. Connectivity and security are also major concerns because users require timely and responsive access, and at the same time the system must maintain the integrity of the data and the privacy of users’ information. To support a potentially large number of concurrent users against an ever-expanding video collection, we chose to implement the video on-demand service by using Azure Media Services. Media Services allows you to build scalable, cost effective, end-to-end media distribution solutions that can upload, encode, package, and deliver media to a variety of devices and platforms. In addition, the Azure environment provides the necessary scalability, reliability, security, and performance necessary for supporting a large number of concurrent, distributed users.

The following diagram shows a high-level overview of the video on-demand service.

Client apps communicate with the video on-demand service through a REST web interface. This interface allows the apps to retrieve, upload, and publish videos. When a video is uploaded for processing by Media Services it is stored in Azure Storage, with the video details being stored in a Content Management System (CMS). It’s then encoded to a set of adaptive bitrate MP4s, which can be converted by dynamic packaging to smooth streaming, HLS, or MPEG-DASH, on demand.

When a video is consumed by apps, its URL is retrieved from the CMS and returned to the app. The app then requests the URL content from the Media Services Origin Service, which processes the outbound stream from storage to client app.

There are three main components to the video on-demand service:

  • The client apps, which allow users to browse videos and control the playback of videos. In addition the apps allow users to capture and upload new videos for encoding by Media Services, which can then be consumed from the CMS once encoding has completed. This series of blog posts will focus purely on the Windows Phone app.
  • The business logic, implemented as a web service. This web service exposes the data and operations that it supports through a REST interface. Separating the business logic in this way decouples it from the client apps, minimizing the impact that any changes to the implementation of the apps will have on this business logic.
  • Data storage, provided by an Azure SQL database, and by Azure Storage. The CMS, which stores details of videos and encoding jobs, is implemented as a Azure SQL database. However, uploaded videos and encoded videos output by Media Services are stored in Azure Storage.

Understanding the Windows Phone app architecture

We used a modified version of Prism for the Windows Runtime to build the Windows Phone app. Prism includes components that provide support for MVVM and the core services required in Windows Phone apps.

The following diagram shows the architecture of the Windows Phone app and the web service in more detail. Grey items are provided by the modified version of Prism for the Windows Runtime, with blue items being created by the development team.

The advantage of this architecture is that it helps to produce flexible, maintainable, and testable code, by separating the concerns of presentation, presentation logic, and entities through support for MVVM.

The Windows Phone app uses the Unity dependency injection container to manage the instantiation of the view model and service classes in the app. Dependency injection enables decoupling of concrete types from the code that depends on these types. The UnityContainer object holds a list of registrations and mappings between interfaces and abstract types and the concrete types that implement or extend these types. The App class instantiates the UnityContainer object and is the only class that holds a reference to this object. Types are then registered in the InitializeContainer method in the App class. For more information about using Unity, see Unity Container.


This blog post has introduced the architecture of the video on-demand service, and the Windows Phone app that consumes the video on-demand service through a REST interface. Media Services is used to encode and package video into the required formats for consumption across a variety of platforms and devices. For more information see Building an On-Demand Video Service with Microsoft Azure Media Services.

In my next blog post I’ll discuss the development of the CMS which stores details of videos and encoding jobs.

No comments:

Post a Comment