To Cloud, or Not to Cloud? A Live Streaming Producer's Dilemma
Streaming is all about using the internet to distribute a program to the masses. An extension of the internet is "The Cloud." We use this ethereal phrase "the cloud" as if it magically provides a solution. If we can put it in "the cloud" we can all access it remotely. This will make things easier, cheaper, more efficient. Yay!
Moving live production to the cloud seems to have a lot of sparkle at the moment. I will admit I do see successful cloud productions, and I know producers who are successful at leveraging the cloud as a process for their productions. In fact, Vizrt just announced that the venerable TriCaster is now conveniently available as an app in the AWS Marketplace. Easily deployed, for the nominal cost of $2/hr via the specific "g4dn.4xlarge" instance size they recommend. Wow!
For those that don't have any idea what that alphaneumeric jumble means: AWS enables you to configure as big or as small a cloud computer ("instance") as you want. While g4dn.4xlarge is what's recommended, users can build a smaller or more powerful configuration as they see fit. Is this the configuration that can handle up to 44 video/audio sources and 8 outputs? I'm not quite sure. 2 cameras and a still image will require a lot less horsepower than 18 cameras, 24 videos, 4 MEs and 4 graphics layers. So it's up to the user, you, to configure, and then thoroughly test the build, so you can make sure it works.
$2 an hour for the hardware seems like an absolute steal when it comes to leveraging the venerable, work-refined TriCaster interface for your production. You may want to consider adding one of the expensive control surfaces to make it very familiar for the technical director to operate. But don't overlook the actual cost of activating the switching software license. The VAR I asked said the Tricaster in the cloud (Vectar) license is $11,400 a year.
If that still sounds good, now you face the two biggest issues I see when going to "the cloud."
1. How do you ingest 44 cameras? Actually, it doesn't matter if it's AWS at all. It could be Sony M2 Live, TVU Networks, or any other desktop video production app hosted in the cloud, like vMix, OBS, Wirecast, Livestream, ManyCam, Streamlabs, etc. Let's say you're at the stadium, with 8 SDI cameras. What do you plug them into?
One way to ingest video inputs is through business chat applications like Teams or Zoom, which have their own issues, and I would not rely on them for broadcast quality video. There's some purpose-built I/O hardware for this, like the $12,000 NewTek NC2/Connect Studio I/O module. You can configure it as 8 x 3G-SDI (HD), or 2 x 12G-SDI (4K). It provides NDI to "the cloud." These 8 inputs will need this $12,000 piece of I/O hardware. You'll also need a second computer to use NDI KVM to manage it. Somewhere else, the director will need a 3rd computer to access the 4th computer in "the cloud" that's doing the actual mixing of your 8 HD inputs. Okay. We got this.
2. But how do the camera inputs actually get TO "the cloud"? What kind of pipe do you need? Well, as I dug into it for this column, the only mention of bandwidth I could find was the 10 GbE on the NC2. So I expect that you'll need multiple gigabits of reliable up and down speed to get the cameras into your cloud computer. This amount of bandwidth can be a real challenge for many small producers, and / or locations in terms of cost, if it's even available at all.
You'll also need an experienced team on the ground to set this up because networking isn't as simple as connecting an SDI cable and it works. You'll need some racks for video and networking gear, some local monitoring. Uninterruptible power supplies, patch panels, etc. Your crew will ensure the networking all works properly. Don't forget the the coms for the camera operators. Then also connect coms to the cloud as well, since the actual director may not be on site. Maybe make that on a secondary connection, in case the primary goes down. Consider SDI to fiber converters if there's some distance involved. Spools of fiber. Camera cases. Tripods and other supports, etc. It's really looking like a production truck of stuff.
The Director and maybe the Technical Director (who pushes the buttons) can be in other cities. Graphics can be created in the cloud as well, audio can be heard and managed remotely. But wait... if they're all remote to the switcher, why does the switcher need to be in "the cloud"? What if we just put the switcher in... "the truck."
Then instead of a massive pipe to send all those high-bandwidth camera feeds to "the cloud" we're only sending the computer screen. We wouldn't need 5 Gbits upload speed because the camera switch happens locally. Avoiding the camera to NDI conversion and transmit to the cloud makes it a frame or three faster. Graphics can come down to us from the cloud. In fact, it seems a lot easier and simpler to put the switcher in the truck and make everyone who's remote, just remote into "the truck." The local team for the truck doesn't even have to change very much.
Is it easier to just remotely control the local switcher and skip "the cloud" altogether? If there are major connectivity issues, someone can switch and record the entire production locally. You can still leverage remote teams for audio, graphics, etc, but the bandwidth needed is much lower and that makes redundancy much easier. All this dramatically reduces bandwidth, and cloud costs, while increasing adaptability and reliability.
Maybe we've been looking at "the cloud" all wrong. It doesn't have to be some 3rd party place we push everything to. Let's start looking at the production space right in front of us as "the cloud" and see what opportunities that opens up. What do you think?
Related Articles
Eyevinn Technology, leading video streaming technology consultants, launches Open Source Cloud. A software as a service based on open source with a unique transparent model where revenue is shared with the open source authors. Open Source Cloud offers media industry companies a quick way to incorporate open source in their solutions and the option to run the same software in-house as the source code is publicly available.
12 Mar 2024