This overview explains key concepts frequently referenced across RMS Documentation. Each term is concisely defined to help you understand the Media API’s functionality and usage.
The table has the following columns:
-
Name: a concept with a linked AMS overview.
-
Usage in RMS: The RMS API mirrors the AMS API with 99% accuracy. Any differences or usage recommendations are noted in this column.
-
Considerations: Key aspects of the concept for a basic understanding.
| Name | Usage in RMS | Considerations |
|---|---|---|
| Transforms & Presets |
RMS generates a list of files for a specified transform, similar to what AMS does: the same file names, bitrates, and sizes. However, RMS only uses the files essential for its operations. RMS supports 15 built-in presets, plus custom ones. |
Transforms configure common tasks for encoding videos. Each describes a workflow for processing media. A preset is a way to instruct how to process input files. |
| Jobs |
Since there’s no technical need to migrate jobs, the migration process excludes them. Instead, the process migrates transcoded data to ensure all necessary media content stays available in RMS. |
A Job is a request to apply a transform to input media. Once created, you can submit jobs through APIs or SDKs, specifying input/output locations. |
| Assets | RMS makes no changes to input assets. The content is used for re-encoding. | An Asset is a media container that can be used for input, output, or publishing.
An Asset is mapped to a blob container in the Azure Storage account and the files in the Asset are stored as block blobs. |
| Use RMS Console to create an account. |
A Media Services account is the foundation of every action for Media Services. It is the parent account for:
|
|
| OData filters | Filtering, ordering, and paging in the RMS API mirrors AMS behavior. You can also filter assets and jobs using AMSE. | OData filters can be added directly to REST API requests. They refine data by specifying parameters like creation date or job state. These filters support ordering and pagination, and can be integrated into SDKs to automate query processing. |
| Dynamic filters |
Asset filters are not supported. RMS supports the following account filters:
|
Configured through the API or portal for each account individually. Unlike OData filters, dynamic filters apply server-side and allow for real-time adjustments to content delivery, such as trimming media fragments or applying specific quality parameters. These filters are ideal for controlling streaming sessions. |
| Streaming endpoint |
RMS does not support full streaming endpoint functionality. It contains only one non-removable streaming endpoint. By default, RMS streaming endpoint uses the same domain name as API and Console. Learn how to consider the endpoints in the migration process in the Complete Migration Guide. |
A Streaming Endpoint dynamically packages and delivers live/on-demand content using protocols like HLS or DASH, supporting just-in-time encryption. In the media streaming industry, this service is commonly referred to as a Packager or Origin. |
| Streaming locator | Unlike AMS, RMS does not support specifying start and end times, which restricts user access to content within a defined time window. |
To make videos available for playback, create a Streaming Locator and build URLs by combining the Streaming Endpoint host name with the Streaming Locator path. The process of creating a Streaming Locator is called publishing. |
| Event Grid | RMS supports all job-related event types from AMS. Reuse event handlers without modification by migrating Event Grid subscriptions, learn more. | Event Grid allows applications to react to events (e.g., job state changes) through Azure Functions, Logic Apps, or Webhooks. RMS schemas are fully compatible with AMS, with minimal migration effort. |