The M2A Live service provides an API for creating and managing the resources required to deliver a live streaming video workflow on top of the AWS media services suite, including AWS MediaLive. In this version, the following resources are supported:

• Encoders An encoder resource represents the encoding of a single logical input stream into one or more output renditions that may be distributed to one or more destinations of the same type. Encoders must be created within an M2A Cloud Target Account which has been set up for your your Organisation. Each encoder is associated with a specific AWS region. If multi-region resiliency is required multiple encoders are defined in different AWS regions.

New in version v3 Encoders accept many configuration options in order to control how media should be interpreted from a source stream, transcoded to its desired representation and the manner in which it should be forwarded onto its destination. To make full use of the underlying capabilities of AWS MediaLive the M2A Live Encoder Configuration service exists alongside M2A Live. The configuration service allows the configuration of existing encoders to be imported and stored so that it can be later remixed and reused. To configure an M2A Live encoder, configuration fragments must be first imported into the configuration service. When creating an encoder, these previously imported fragments must be referenced to describe the desired configuration of the new encoder. Fragments are always referenced by their ID. Each fragment has a type which indicates which aspect of an encoder's configuration it pertains to. The correct type of fragment must be referenced when used in this API. For example, only base-typed fragments may be used for specifying the base configuration of an M2A Live encoder. For the most part, viable fragment types correspond with the field name in which they are specified under. For example, either selector:audio orselector:video fragments are suitable for use with the selector field of an assembly. To describe media transformations, sequences of fragment references are arranged into assemblies. Broadly, an assembly describes what media to encode, how to encode it and, where to send it afterwards. One assembly must be specified for each unique path media takes through the encoder pipeline. Meaning that, if there's a single, selected audio track that is to be transcoded into multiple renditions, the same selector fragment would be used referenced by two assemblies. Assemblies bind configuration fragments to the video sources and destinations which are specified during encoder creation through named references. For a fuller description of building encoder configurations, including grouping often repeated assemblies into singular sets, consult the M2A Live Encoder Configuration service's documentation.

Input Specification

In the current version, input sources may be a pre-defined M2A Connect source, an RTP stream (with optional FEC), an RTMP push stream or an MP4 file from AWS S3. For M2A Connect sources, this API must be provided with:

• An M2A Connect source ID * A corresponding AWS MediaConnect flow ARN During encoder start up, AWS MediaLive inputs will be created to match the specified sources, which are then attached to the MediaLive channel. The channel attachments are populated with selectors and other configuration from configuration fragment assemblies described above. For this, each source must be named and then subsequently referenced in one or more of the assemblies. If two sources share a name they will form a failover pair.

Destinations

As the name suggests, destinations describe the location where encoded media should be sent to. Either as a URL or ARN. Each destination must be given a unique name. These names can then be referenced in each configuration fragment assembly. If the destination determines where media is sent, the output fragment of an assembly determines how. As such, it is important to use destinations which correspond to the type of output fragment it is to be bound to. For example, using HTTPS URLs with Smooth streaming outputs and channel ARNs with AWS MediaPackage outputs. Multiple destinations can be configured to support a resilient packaging cluster. In such a configuration, each destination should be separately bound to identical, yet distinct assemblies.

M2A always strive to maintain backwards compatibility with older API clients as new features are added to our services. If a given API is found to have security or performance issues that are unfixable in a backwards-compatible fashion, then new API versions may be introduced in parallel with the older API, but at a new URL. The old API will continue to be supported for a period of time, but customers will be notified of the API deprecation, and in addition the old API will be modified to begin including Deprecation response headers. Client software calling the API should watch for these Deprecation headers on responses, and warn the system operator that deprecated APIs are in use -- if a software change is not made to move away from the deprecate API then the client code will eventually stop working.