What’s sad is that at least partially because of this asshat, a lot of other companies got the idea that they can just fire lots of their staff and let the remaining people pick up the slack (because they should be thankful they even have a job)…I cannot wait for the chickens to come home to roost not only at Xitter, but other companies doing this because he did.

The goal was a livestream, not a fancy video or anything.

The scope here is a live stream to hundreds of thousands of people with modest quality.

So yes, it’s not just fine, it’s good.

Sure

The biggest thing to me is don’t share the Internet connection. Get a separate line turned up to handle the session, with a dedicated firewall (commercial grade, doesn’t need to be a palo alto or anything, but a mikrotik, Cisco fp, etc is fine), connected to a switch for just the zoom machines. No meeting connector or any of those shenanigans - the throughput is dedicated to the session. If it’s the kind of place that can’t do that, get share the pathway as little as possible, and provide that client endpoint with the highest priority. This is, to me, the most important part.

Production Studio will get used, but it’s not really doing any of the lift - it’s a full production studio before it hits that machine (which has a matching spec machine right next to it in case of failure, turned on and ready to go as a co-host machine). All it’s doing is allowing for some border content, some backgrounds for content, session wallpaper, etc. Glorified OBS at that point.

Feeding it is usually a Ross Carbonite or a Grass Valley, but I’ve also done it with a black magic atem, Roland, etc. At this point, all the production is outside of Zoom, so any lower thirds, virtual studio backgrounds, etc. are all handled there. This way, if there is any issue with the main Zoom Prod Studio machine, there’s a second video feed to the backup (co-host) PC. That’s the only advantage/reason why I even bother with Prod Studio over just tossing a zoom room on a PC and walking away.

All production hardware is on a segregated network, no outbound internet or routes, especially if using Dante/aes67, NDI, qlan, whatever. Stacked switches if more than one is needed, no simple uplinks (ie: bottlenecks).

At that point not much else matters, grab your shure lavs (if there is density, axient) and a few wires mic backups, cameras at your preference (honestly a lot of BM Ursa/Studio with good cine lenses, mostly primes), and good to go.

Couldn’t tell you about Discord, sorry, don’t really use it.

Just to mention, smaller scale production takes the same tactics, just without a GV/Ross/etc, more likely a BM ATEM or something. But I don’t deal with that too much these days.

More often than not, I’m designing a studio which can also run webinars. For a presidential candidate, they probably did something similar, maybe making use of a few tools not public yet (though I wouldn’t have risked it with an event like this).

Teams can be much more problematic, it’s like a firehose of traffic, using whatever you give it. Looks good when you have the bandwidth, making the first statement - not sharing the connection - even more important. Zoom is heavy on the compression, but quite stable as a result.

Recordings should be local, with the session also recorded, so the session can be distributed with the local recording edited in for a better quality result. Remote participants, when I have to deal with that, get a full kit including a local recording system (aja mostly), so the drive can be shipped back with the kit for the finals edits.