Multi-Vendor Cloud Orchestration – GrassValley AMPP & RTS Intercom

Thomas Gunkel

Taking advantage of what the cloud offers to media companies is easier said than done. In this use case, you will learn how DataMiner manages the complete life cycle of your live production, which also requires the spinning up and configuration of resources running in the public cloud.

In our demo, we have integrated with Grass Valley’s cloud-native media processing platform GV AMPP and the RTS VLink Intercom system.

Simply enter your administrative data on an easy-to-use web UI and select the required production resources. DataMiner will reserve the selected resources and right before the production starts, DataMiner will spin them up, start all media applications, configure those, and route all video and audio signals, e.g. to your vision mixer. While the production is ongoing, all resources get monitored constantly. Additionally, let’s not forget that once the production has finished, all cloud resources will be stopped and terminated again.

USE CASE DETAILS

Let's have a look at the workflow now. This screenshot shows one of our new DataMiner user-definable apps to manage your productions. Just use the "New Job" button to plan a new live production.

Now enter administrative data, e.g. job name, start and stop date, and also select the production type. In our example, we go for a remote cloud production.

In the next step, the operator selects the required production resources. For the demo, we kept things very simple. Select your Grass Valley AMPP live feed, a clip player, and an audio mixer and multiviewer from a dropdown list. Nothing can go wrong here, as DataMiner only shows the resources in the dropdown that are available at the specified time. Then indicate the clip you want to play from the selection in the clip player and pick two intercom software panels, where you can pick the name of the operator who will use the panel.

This is the view for people in engineering, where they can see what happens behind the scenes. The production data is already in the system, the service is in "stop" state, and shows a "partial" state for the booking.

And here is the reason for the "partial" state: we have defined a workflow in which the production data needs to be approved first. People entering the administrative data are usually different from the ones managing the production. The data gets entered by the planning team, yet the approval might come from somebody in the MCR.

Once approved, the production goes into a "confirmed" state.

Our engineering view shows that all resources, GV AMPP, RTS, and people have been reserved. At this stage, nothing has been configured yet.

Here we see the GV AMPP setup before our production starts: production 1, which is used for our demo, currently has no signals routed to the mixer, has no clip player, and does not have a multiviewer running yet.

A few minutes before the production starts, DataMiner starts those pre-selected resources and sets the crosspoints to route the signal into the mixer. Clip player 1 and 3, but also the second master control, won't be used.

In our app, you can see that the production is now "ongoing".

As an operator, you just open the GV.UI app and everything is readily set up: the mixer has the live signal and the clip available, and on the right, you can see the multiviewer and the clip player running our selected clip in a loop.

Open the multiviewer on a second screen and run your production.

Alternatively, use the player window to stop the clip, to recue it, etc.

You can also create a DataMiner interface to control your resources, e.g. to change the multiviewer layout or audio levels to operate your production and go straight to the GV user interfaces from there.

Now let's have a quick look at the RTS Intercom, which is running on an AWS EC2 instance. During the pre-roll phase, DataMiner has started and configured the EC2 instance and also configured the two intercom panels.

Here you see the simple panel for David, who can now talk to his colleague Gelber or use the party line button.

Once the production has reached the end, DataMiner will decommission all resources again.

This screenshot shows the AWS EC2 instance for RTS, which is about to stop.

As you can see, all GV AMPP resources are stopping now and signals are disconnected again.

And finally, let's have a quick look at how DataMiner controls GV AMPP. Our DataMiner connectors communicate with the "GV Control" API. An API token is required to establish communication.

DataMiner now exposes all GV AMPP apps. Here is a screenshot of all the clip players that are available. The API also allows you to load a different player, or to start and stop one.

This image is interesting because it shows the GFX engine from Singular. As Singular is a partner in the GV AMPP ecosystem, the GV AMPP Control API allows us to monitor and manage Singular in the same way as we do for each app developed by Grass Valley.

Here is an example of the multiviewer data we are using for this demo.

DataMiner also monitors all GV AMPP apps.

DataMiner is aware of all workloads and their ongoing state in the complete system, and not only the ones we were using in our demo.