Best practices for MediaConnect

Ensure you have set up your transport stream flows with an aggregate output bandwidth of up to 400 Mb/s. MediaConnect is designed to work with an aggregate output bandwidth of 400 Mb/s.

aggregate output bandwidth = (bitrate of the source) x (number of outputs)

For example, if your flow has a source with a bitrate of 80 Mb/s and 5 outputs, the aggregate output bandwidth is 400 Mb/s. Likewise, a flow that has a source with a bitrate of 20 Mb/s and sends content to 20 outputs also has an aggregate output bandwidth of 400 Mb/s.

You can set up transport stream flows with bitrates up to 120 megabits per second (Mb/s) with mezzanine-quality live video.

Monitor the performance of your MediaConnect flow as you scale NDI outputs. In particular, watch for signs of over-subscription, such as:

If you notice these issues, consider reducing the number of outputs or investigating ways to optimize your workflow.

Calculate the aggregate bandwidth of your NDI outputs and ensure it fits within the total throughput capacity of your MediaConnect flow size. The large flow size supports up to 2.5 Gbps of aggregate throughput.

Use descriptive naming conventions for your NDI outputs to make it easier for production systems to quickly discover and connect to the correct sources.

Consider segmenting your NDI outputs across multiple MediaConnect flows, rather than concentrating all outputs in a single flow. This can help distribute the resource load. However, keep in mind that using multiple NDI flow outputs will generate multiple NDI sources, each with their own unique machine name and program name. This will need to be accounted for in your overall workflow.

Test your full NDI workflow, including connecting multiple receivers, to understand the performance characteristics and limits for your specific use case.

Limit your NDI configuration setup to a single interface adapter per VPC. Each VPC interface has its own private IP address. When you use multiple VPC interfaces, this can confuse the NDI discovery server and lead to unexpected routing behavior.

You can use up to 10 outputs for CDI flows. In addition, 4Kp60 CDI flows support 10 ST 2110 JPEG XS outputs, but only 4 CDI outputs.

The API can be used to start multiple bridges at one time. If you are starting multiple bridges using the API, we recommend starting no more than 10 at one time. If you need to start more than 10 bridges, use multiple requests.

You can use managed outputs to send content exclusively between MediaConnect flows and MediaLive channels. For instructions on creating these output types, see Setting up for a MediaConnect input in the MediaLive User Guide.

For flows with managed output types, we recommend an aggregate bitrate limitation of 160 Mbps. For example, if a flow has a source bitrate of 4.5 Mbps, the total number of managed outputs shouldn't exceed 35.

For flows with both managed outputs and transport stream outputs, apply the same 160 Mbps aggregate limitation.

To minimize packet loss, use Forward Error Correction (FEC) or automatic repeat request (ARQ) based protocols such as the Zixi or RTP-FEC protocol. These protocols are designed to minimize packet loss between the source and destination devices.

Because packet loss is present on any network, even in fully managed networks such as the AWS Cloud, you should create and manage redundant connections throughout your workflows. In MediaConnect, there are multiple ways to add redundancy to your workflow:

We recommend that your organization create a VPC specifically for all AWS Media Services. A single VPC will help to ensure the availability of IP addresses, help in setting up appropriate rules in the security groups, and help to ensure that a network administrator doesn't accidentally delete elastic network interfaces.

Set up Amazon CloudWatch metrics and alarms to track the health of your source. For information about which metrics to monitor, see Monitoring and tagging.

The CIDR block on the flow source should be as precise as possible. Include only the IP addresses that you want to contribute content to your flow. If the CIDR block is too wide, it allows for the possibility of outside parties sending content to your flow.

When you create a new SRT password to encrypt an SRT output, you must create that password in AWS Secrets Manager. AWS Secrets Manager does not enforce a specific password policy. However, we recommend the following password policy: