Microsoft Azure Media Services common scenarios
Update your Azure Media Services REST API and SDKs to v3 by 29 February 2024. Version 3 of Azure Media Services REST API and client SDKs for .NET and Java offers more capabilities than version 2. We’re retiring version 2 of the Azure Media Services REST API and client SDKs for .NET and Java.
Action Required: To minimize disruption to your workloads, review the migration guide to transition your code from the version 2 API and SDKs to version 3 API and SDK before February 29th, 2024. After February 29th, 2024, Azure Media Services will no longer accept traffic on the version 2 REST API, the ARM account management API version 2015-10-01, or from the version 2 .NET client SDKs. This includes any 3rd party open-source client SDKS that may call the version 2 API. Learn about the latest version, starting with the Media Services v3 Overview.
Microsoft Azure Media Services (AMS) enables you to securely upload, store, encode, and package video or audio content for both on-demand and live streaming delivery to various clients (for example, TV, PC, and mobile devices).
This article shows common scenarios for delivering your content live or on-demand.
An Azure account. If you don't have an account, you can create a free trial account in just a couple of minutes. For details, see Azure Free Trial.
An Azure Media Services account. For more information, see Create Account.
The streaming endpoint from which you want to stream content has to be in the Running state.
When your AMS account is created, a default streaming endpoint is added to your account in the Stopped state. To start streaming your content and take advantage of dynamic packaging and dynamic encryption, the streaming endpoint has to be in the Running state.
Commonly used objects when developing against the AMS OData model
The following image shows some of the most commonly used objects when developing against the Media Services OData model.
Click the image to view it full size.
You can view the whole model here.
Protect content in storage and deliver streaming media in the clear (non-encrypted)
Upload a high-quality media file into an asset.
Applying the storage encryption option to your asset in order to protect your content during upload and while at rest in storage is encouraged.
Encode to a set of adaptive bitrate MP4 files.
Applying the storage encryption option to the output asset in order to protect your content at rest is also encouraged.
Configure asset delivery policy (used by dynamic packaging).
If your asset is storage encrypted, you must configure asset delivery policy.
Publish the asset by creating an OnDemand locator.
Stream published content.
Protect content in storage, deliver dynamically encrypted streaming media
- Upload a high-quality media file into an asset. Apply storage encryption option to the asset.
- Encode to a set of adaptive bitrate MP4 files. Apply storage encryption option to the output asset.
- Create encryption content key for the asset you want to be dynamically encrypted during playback.
- Configure content key authorization policy.
- Configure asset delivery policy (used by dynamic packaging and dynamic encryption).
- Publish the asset by creating an OnDemand locator.
- Stream published content.
Deliver progressive download
- Upload a high-quality media file into an asset.
- Encode to a single MP4 file.
- Publish the asset by creating an OnDemand or SAS locator. If using SAS locator, the content is downloaded from the Azure blob storage. You don't need to have streaming endpoints in started state.
- Progressively download content.
Delivering live-streaming events
- Ingest live content using various live streaming protocols (for example RTMP or Smooth Streaming).
- (optionally) Encode your stream into adaptive bitrate stream.
- Preview your live stream.
- Deliver the content through:
- Common streaming protocols (for example, MPEG DASH, Smooth, HLS) directly to your customers,
- To a Content Delivery Network (CDN) for further distribution, or
- Record and store the ingested content to be streamed later (Video-on-Demand).
When doing live streaming, you can choose one of the following routes:
Working with channels that receive multi-bitrate live stream from on-premises encoders (pass-through)
The following diagram shows the major parts of the AMS platform that are involved in the pass-through workflow.
For more information, see Working with Channels that Receive Multi-bitrate Live Stream from On-premises Encoders.
Working with channels that are enabled to perform live encoding with Azure Media Services
The following diagram shows the major parts of the AMS platform that are involved in Live Streaming workflow where a Channel is enabled to do live encoding with Media Services.
For more information, see Working with Channels that are Enabled to Perform Live Encoding with Azure Media Services.
Azure Media Services provides the tools you need to create rich, dynamic client player applications for most platforms including: iOS Devices, Android Devices, Windows, Windows Phone, Xbox, and Set-top boxes.
Enabling Azure CDN
Media Services supports integration with Azure CDN. For information on how to enable Azure CDN, see How to Manage Streaming Endpoints in a Media Services Account.
Scaling a Media Services account
AMS customers can scale streaming endpoints, media processing, and storage in their AMS accounts.
Media Services customers can choose either a Standard streaming endpoint or a Premium streaming endpoint. A Standard streaming endpoint is suitable for most streaming workloads. It includes the same features as a Premium streaming endpoints and scales outbound bandwidth automatically.
Premium streaming endpoints are suitable for advanced workloads, providing dedicated and scalable bandwidth capacity. Customers that have a Premium streaming endpoint, by default get one streaming unit (SU). The streaming endpoint can be scaled by adding SUs. Each SU provides additional bandwidth capacity to the application. For more information about scaling Premium streaming endpoints, see the Scaling streaming endpoints topic.
A Media Services account is associated with a Reserved Unit Type, which determines the speed with which your media processing tasks are processed. You can pick between the following reserved unit types: S1, S2, or S3. For example, the same encoding job runs faster when you use the S2 reserved unit type compare to the S1 type.
In addition to specifying the reserved unit type, you can specify to provision your account with Reserved Units (RUs). The number of provisioned RUs determines the number of media tasks that can be processed concurrently in a given account.
RUs work for parallelizing all media processing, including indexing jobs using Azure Media Indexer. However, unlike encoding, indexing jobs do not get processed faster with faster reserved units.
For more information see, Scale media processing.
You can also scale your Media Services account by adding storage accounts to it. Each storage account is limited to 500 TB. For more information, see Manage storage accounts.