The two “cannot run a livestream in the year 2024,” the Harris campaign snarked on X.
Kamala Harris’s presidential campaign has already proven itself adept at baiting Donald Trump and his supporters using the playground-tested technique of calling Republicans “weird.” The campaign, which has proven itself to be Extremely Online through TikToks evoking Trump’s lack of “aura” and hearty embrace of the “brat” label, is now provoking its opponent by pointing out how not online Trump is.
Trump is so out of touch, he can’t work the internet, the Harris campaign posits, pointing to Monday evening’s livestreamed interview between Trump and Elon Musk, which was delayed by some 45 minutes due to technical issues.
“Trump’s entire campaign is in service of people like Elon Musk and himself—self-obsessed rich guys who will sell out the middle class and who cannot run a livestream in the year 2024,” the Harris campaign shared on X (formerly Twitter) after the lengthy conversation between the two. The campaign’s rapid response team addressed the statement to “those unlucky enough to listen in tonight during whatever that was on X.com.”
She better be careful. Live streams are actually hard in 2024 if you’re going for consistent quality under heavy load lol lots of potential failure points that are almost or sometimes even completely out of your hands. It could happen to her!
Still, musk’s livestream failed because he gutted his tantrum-purchased tech company. So there’s no denying this was squarely his dropped ball. DDoS attack lmao can’t believe he thought he could just throw that out there.
She already held the largest Zoom call, with almost 200,000 people joining.
Which, to be fair, crashed. Most of the callers had to be shifted over to YouTube Live. Source: my wife was on the call.
There was no ddos attack. A Twitter employee already confirmed that Elon was full of shit. Twitter just sucks.
Source?
It wasn’t even a video live stream. It was just audio.
Are they really? The tools are there, Zoom (like she already used), Discord, or whatever.
Have you seen popular games on launch day falling down on auth flows? That’s largely just HTTPS text connections via REST. Now add in a binary data stream on top of that (likely RPC, but I’m not sure of Twitter’s implementation).
All that said, Twitter dropped the ball due to Musk’s arrogance. Instead of having limited issues, it was riddled with issues as a result of him firing all the people that could have reduced the issues. As was foretold by our ancestors.
Zoom looks/sounds like shit and makes it very difficult to exercise any control over what is visually taking place. Look up the myriad of posts online with folks trying to troubleshoot a simple OBS->Zoom pipeline. It’s astounding how bumpy that can get.
Discord requires you to join a server and a voice chat channel isn’t remotely equipped with the tools you need to control the stream or participants.
A high quality, produced live stream for millions does not work on these platforms. You’re also depending on their ability to handle the traffic which takes it squarely out of your hands. One more failure point. There are other services where you have more power/say in the infrastructure but these require a lot more technical know how than the consumer platforms you’re pitching here.
Yeah no. It works just fine.
I literally do this for a living. You cannot do a high production value stream on zoom easily. It has a dozen more failure points than any other solution. Every client that wants me to push to zoom we fight tooth and nail to stop them.
Harris used Zoom to speak to hundreds of thousands. I’ve used it for work for years. It’s absolutely fine.
If you have a very narrow scope, single person talking objective with no production value then yes it’s fine.
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.
The goal was a livestream, not a fancy video or anything.
~200,000 simultaneous connections vs ~2,000,000 simultaneous connections is a world of difference.
Additionally, while a successful Zoom call, it still had issues, with a dedicated Zoom support team.
Nothing about either of these events were “easy” or “fine”.
The big difference is that Musk is an arrogant idiot and decided to roll-his-own streaming service with a reduced headcount and a product that that is lacking proper load balancing, reservations, & scaling through load testing & real world tests scenarios that ramp up scale over time.
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.
Zoom is the lowest bitrate of any platform. It’s not a firehouse like traffic out of teams. It’s literally the easiest solution to do this with.
To not, I’ve designed and overseen the implementation of deployments for zoom, teams, pexip, etc, etc, for companies that employ a small country worth of people globally.
“High production” is never easy. But at a certain level, there are additional tools from Zoom (as well as others) that can be used, which even have hooks into production consoles. Mostly cheap ones, but still.
Honest to god I’d love to know how you handle zoom because our experience with their SDK in particular has been terrible. Anything involving multiple people are swapping assets from different people has been a nightmare. I’m so sick of fighting it.
Out of curiosity I’d be interested in hearing how you’d handle discord too. This is not bait, i do think it’s a terrible idea but if it’s viable I’d like to know more.
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.
Man I have to say I was not expecting this conversation to go this direction and I truly appreciate the valuable insight you have given me here I’m taking a lot of notes. We have good bandwidth/not-sharing-internet hygiene when possible (sometimes I have to twist arms to get approval to grab a LiveU unit) but a lot of specifics here that I think we could implement beyond that.
This is definitely a complicated lift but something I think my team can handle.
One question: how do you handle multiple zoom presenters that are not in the same place? Especially if they are all doing their own share screens at different times one after the other. Remote stuff, you don’t have a team there. This is really where I find headaches kick off
I mean, we’ve had a solution to this decades ago - multicast. It would have been perfect exactly for this kind of one-to-many TV-like broadcast.
Too bad greedy ISPs and ISVs killed anything that isn’t HTTP, so smart people had to scramble and find alternate sub-par solutions.
deleted by creator