Introduction

It’s desirable in some cases to have a video source as the background in a mosaic. This is especially true in cloud playout where the redundant playout systems are running in different Availability Zones or Regions in the cloud and the customer wants the video tiles for both systems on the same mosaic.

Implementing Video as a Background in a Mosaic

There are two steps to making this work: create the desired backgound mosaic on the first instance and output it, then bring this output into the second instance as a source and assign it to a mosaic’s background.

For this example, we’ll be running two playout systems in AWS, one in the Blue availability zone and the other in the Green availability zone. We’ll stand up a TAG MCM in each availability zone to provide redundancy. In the end, each TAG MC will output the same mosaic, interleaving the Blue and Green tiles from the playout systems running in both availability zones.

Open

Create the background video

The first step is to create a layout with just the sources from the playout channels in that availability zone. In this example we’ll be creating the mosaic in the Green AZ TAG instance with the 8 Green playout channels:

Open

To stream this mosaic to the other AZ, we’ll want to use the lowest latency encoding possible so that both blue and green tiles are as close to sync with each other as possible for the operator. CDI does not transit between Availability Zones, the process to sending NDI between AZs has not yet been defined by TAG, and JPEG XS output is still in R&D. So the only remaining choice is H.264 with low GOP. We’ll also need to send this via SRT to protect the transit between AZs as the AWS network between AZs is basically public internet.

Use this mosaic as a background in the other instance

On the Blue TAG instance, scan and receive the Green mosaic we created above as a source and give it a meaningful name. I might help to name both the Green mosaic output on the green instance and the corresponding input on the Blue instance with the same name, something like “Green to Blue BG”. (of course, your Availability Zones are not likley to be called Green and Blue). Get the UUID of this source as you’ll need it below.

On the Blue instance, create a mosaic output with just the Blue playout sources:

Once tested, then create a copy of this layout. You’ll need two versions of this layout assigned to separate output encoders. One will be used for the composite layout to send to the operator, and the other will be sent to the other TAG MCM as a background

For the layout and output where we want to composite the blue and green tiles on a single mosaic, we’ll set the “green to Blue BG” mosaic and input from above as the background:

On the mosaic layout editor (output/layout editor), click the edit icon to open in edit mode. In the background, enter either of the following:

You should now have a mosaic that looks like this with the blue and green tiles interleaved:

Configure this mosiac’s output encoder to send the mosaic to the operator position.

Configure the other Blue-only mosaic output the same way you configured the Green-only mosaic output encoder above to send it to the Green TAG MCM instance.

Cloud Playout without TAG background

The normal way to do this would be to have each playout channel create 3 outputs:

1. The main playout signal to air

2. Copy to TAG in Green AZ

3. Copy to TAG in Blue AZ

The problem with this model is that many playout systems can’t provide SRT or other protection to the signal that feeds TAG between AZs, causing the signals to become impaired. This model also requires a 3rd output from each playout system consuming expensive cloud resources. For redundant TAG instances, each one would need 16 sources almost doubling their capacity requirements.

Recommended Cloud Playout Model with TAG Background

The design proposed and detailed above looks something like this:

With the background video model above, each source is only output once by a playout system to TAG. The TAG instances are substantially smaller in size. TAG protects the signals as they transit between AZs with SRT, something the playout systems might not be able to do.

The downsides to this model:

1. If a TAG instance fails, visibility into all of that AZ’s playout channels are lost and the operator is forced to run off of the backup playout servers and TAG instance. A lambda watchdog that could monitor the TAG instance and relaunch it in case of failure is recommended.

2. There is latency between the Blue and Green tiles caused by the background encoding and decoding. NDI or JPEG XS could significantly reduce this once available, although SRT would still be needed between AZs.

Once released, the TAG Bridge Technology could also be used to send individual tiles instead of a background, although it would be more complicated to setup and as it requires SRT would not improve on the latency.

Troubleshooting

The most common problems when implementing this architecture are related to AWS IAM permissions. remember that SRT is a bidirectional protocol (it needs to send missing packet request back to the sender) so ports need to be opened in both directions between the AZs and VPCs.