Outputs are one of the core components of M2A Connect, providing the user with the means to route streams out of Connect’s directly managed infrastructure to external services – including, potentially, other M2A Cloud products, services or components. As such, Outputs are the canonical means of accessing media once it has been ingested into Connect.
Outputs can be found on the Routes page of the M2A console. An Output can be in a different AWS region from the receiving Source, enabling global transportation of broadcast quality transport streams. As a single entity within M2A Connect, an Output can even have multiple AWS Regions from which streams may be delivered to Destinations. Outputs may be assigned to separate receiving organisations (ie Subscribers), or they may be handed-off points to your own organisation.
An Output represents the hand-off to the Subscriber and can specify the type of protocol used to deliver the stream and its Destination.
An Output is only active when a Source is logically routed to it and a Destination is present. If one or neither condition is met, the Output will be inactive and underlying resources may be deactivated to minimise running costs.
Creating an Output
On the “Routes” page in console, click on the button on the top right corner to create a new Output:
A new window will appear:
Cross-region routing
This feature can be enabled or disabled.
- If disabled, Destinations can only be created in the same AWS region as the Source.
- If enabled, Destinations can be created in other AWS regions as well.
AWS regions limit
If cross-region routing is enabled, the “AWS regions limit” feature limits the number of Output regions that can be used from the Destination’s (ie the Subscriber or receiver) point of view. For example: if 4 regions are selected in a given output, but the AWS regions limit is set up as “2”, only two of the four regions will be able to deliver the flows.
Available AWS regions
A drop-down menu to select AWS regions to route the flows.
AWS regions currently available:
- ap-east-1 (Hong Kong)
- ap-northeast-1
- ap-northeast-2 (Seoul)
- ap-south-1 (Mumbai)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- eu-central-1 (Frankfurt)
- eu-north-1 (Stockholm)
- eu-west-1 (Dublin)
- eu-west-2 (London)
- eu-west-3 (Paris)
- sa-east-1 (São Paulo)
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-1 (N. California)
- us-west-2 (Oregon)
Availability Zones
A drop-down menu allows the selection of AZs in the region(s) selected.
VPC Interfaces
This allows the communication between the Output and Destination to be via a VPC interface.
Available Protocols
One or more protocols can be selected when creating/updating an Output. These are the allowed protocols of the Output and determine how Destinations can be set up. As with Sources and their inputs, the receiving device or account (the Destination) must be set up separately to comply with the parameters set on the Output:
Protocols currently available:
- Zixi-pull
- Zixi-push
- SRT Listener
- SRT Caller
- Entitlement
- RTP
- RTMP
Address Durability
Persistent addressing
Persistent addressing implies that an endpoint address should never change for the lifetime of the output. In this set up, a rendezvous flow is provisioned for each region the Output is available in and which shares the life-cycle of the Output itself. It is on the new flows where the physical routes are created. The egress from the Source is connected to this type of Output as an input so that media flows between them. Like the egress of a Source itself, a rendezvous flow of an Output is only started when a Source is actively routed in.
As these rendezvous flows share the life-cycle of the Output itself, the address remains constant so long as the Output exists.
Ephemeral addressing
With Ephemeral addressing, physical routes are created on the egress flows for the Source routed into an Output. As a consequence, the address of the Output will change as the routing configuration changes – e.g. because Events starting and stopping – or as a consequence of the flows underpinning a Source changes. However, in the absence of routing configuration changes the address of the Output should be unchanging.
Under this addressing scheme, the user accepts that the address may change in a generally predictable manner. It is the responsibility of the user to ensure they have up-to-date knowledge of the address. However, the key benefit of Ephemeral addressing is cost is reduced because it requires fewer standing resources. It is therefore suitable for fixed relationships between Sources and Outputs, or relationships that only rarely and always predictably change.
Output Labels
If label(s) are present at the Source, the same label(s) need to be added to the Output at “Source query” field. If they are not present at the Output, it won’t be possible to create Destinations.