Yesterday, JP joined the panel — the closing session of Streaming Media Connect's 20th edition — moderated by Bhavesh Upadhyaya (SVTA), to talk through scaling live streaming infrastructure from on-prem to hybrid to cloud-native. He proposed a framework to break "scale" down into the dimensions that actually matter, and Ben Ratner (LiveU) and Lukas Navickas (Servers.com) kept adding their own layers on top of it.
Four Dimensions, Moving Independently
| Dimension | What It Measures | Why It Matters |
|---|---|---|
| Viewership, on delivery | Concurrent viewers | The number everyone quotes |
| Streams, on ingest and processing | How many streams come in, regardless of how many people watch them | UGC platforms like Twitch or Kick run thousands of simultaneous streams — there, you're scaling for contributors, not viewers |
| Diversity | Regions, networks, renditions, formats, devices | Can quietly kill you if you want to be on every platform and every device |
| The human component | How many streams or regions one operator can hold in their head | Defines how the operation itself is designed |
Ben added a fifth layer from the production side: scaling also means the content and people behind it, often within the same broadcast — 16:9 and 9:16 running in parallel, alternate-commentary feeds like the "Manningcast," graphics and play-by-play in different languages.
Lukas works from a different angle: label the expected load as predictable or unpredictable, then size for it — bandwidth capacity and ISP over-provisioning at the edge, channel counts at transcoding, ingest and origin.
Where Things Actually Run
The Hybrid Case, With Numbers
Lukas described a cricket OTT platform (IPL), with live and VOD content, heavily seasonal — demand spikes only during the league's months. They started on a hyperscaler, and as the platform scaled, noticed the bill wasn't climbing because of compute — it was egress.
"As the platform scaled, they realized that the bills we get every single month are steeping up — and it's not just from the compute layer, but it's actually the egress that really gets you is what we find."
The fix was a hybrid redesign: the predictable, year-round base load moved to bare metal, cheaper for constant demand. Only when the season kicks in do they burst that extra load into the hyperscaler.
| Before | All compute on the hyperscaler, year-round, regardless of actual demand |
| After | Predictable base load on bare metal; burst to the hyperscaler only during the league's season |
| Result | 30–35% lower spend, month over month |
"The way we like to look at it is like a fancy five star hotel. But if you actually expect high amounts of viewers, do you really need to stay there?"
Over the past eighteen months he's seen the same pattern repeat across the industry: platforms moving back toward on-prem or hybrid for load they can predict. The exception is real too — a platform streaming once a year for a couple of Saturdays isn't a fit for dedicated compute: "in some cases we almost have to walk away."
Opex vs. Capex, Design vs. Runtime
Ben framed the same decision from another angle — sometimes the deciding factor isn't technical but accounting.
"There's always the big debate about opex and capex. For a control room that could be a hundred thousand dollars, it could be a million dollars — and you've got that one control room. Or do you need something with more flexibility, that you could spin up for a couple bucks an hour? And have as many of those control rooms as you need."
Some organizations simply can't operate outside capex, and that decides the architecture before any technical consideration does. JP's version is the rule Qualabs builds by:
"Scalability is a design problem more than a runtime problem. It's going to be a runtime problem if you didn't design it well. You design for the future, but you build for the present."
Scaling People, Not Just Infrastructure
Ben's insight flips the usual intuition: you scale up the number of productions by scaling down the complexity of each one. For tier 2 and 3 leagues, one camera and a solid graphics package often beats a ten-camera setup nobody can afford — the audience wants access to the game and a good story, not ten camera angles. That also changes who does the work: productions that used to need a director, technical director, and engineer now often run with producers and talent instead, and Ben's found people experience that shift as empowering rather than burdensome.
Lukas was candid that scaling their own operation means more engineers, not fewer — racking hardware, networking, automation — and pushed back gently on automating everything: "we do prefer to keep that human touch alongside a customer journey, rather than push them through a ticketing system."
Green Dashboards Lie
The scenario the moderator set up: Ben's multiview looks fine, Lukas's servers are healthy, and yet one TV model, in one country, on one OS version, is failing. How do you find it?
"You're in the middle of an event, server side everything looks green, everything is running. The edge is returning 200s, the origin is healthy. You look at the aggregated error rate and it's flat. But then you have a specific slice of the audience that is stalling: one device class, one region, one ISP."
JP splits the observability problem in two:
- The data pipeline is a different beast from the video pipeline. Video goes from one origin to millions of destinations; telemetry runs the opposite direction — "it's not going to be one-to-many, it's many-to-one."
- Data has to be actionable, not just available. You can have a VMAF that comes from CMSD, CMCD, the VQA path — what does a VMAF of 30 versus 85 mean? It has to be shown in a way that triggers the right runbook. (VMAF: a 0–100 perceptual quality score. CMCD/CMSD carry client- and server-side data between player and CDN.)
The real case JP shared: during the World Cup, very specific errors affecting a small number of users turned out to trace back to one CDN, one server, returning 404s — minimal against the total volume of the tournament. His close on this block: understand the end-to-end topology, measure everything, but also understand the operator's point of view, so the data triggers a concrete action.
Ben splits monitoring into quantitative (is the signal arriving, is bandwidth sufficient — easier to automate) and qualitative (does it look good, is it doing its job — still needs human eyes): "that's where scale hits its ceiling, for now at least." Lukas's layer is physical: redundancy across the system, constant monitoring against multiple ISPs — with an honest limit, since the last mile is out of his control.
Shared Responsibility Across Vendors
With three or more vendors in a chain, where does each one's responsibility end? Lukas's team integrates their monitoring tools with the client's own, so both sides can act when something breaks on their side of the line. Ben got the biggest laugh of the panel with his first answer — "I think we just blame the other vendors and call it a day" — before landing the real point: know your signal flow well enough that you can point to exactly where it worked and where it stopped, on paper if you have to.
He also raised a trade-off worth weighing: turnkey systems get you running through a browser but leave you less visibility and less ability to fix things yourself; more traditional systems give you more control at the cost of simplicity. The right choice depends on your team's profile, not on what's easiest to buy.
Rehearse for Failure, Not for the Event
This was arguably the most original block of the hour, and it's JP's.
"Everybody load tests the systems, and it's easy — you can load test a happy path. But you're going to rehearse for degradation. And degradation is what actually happens. You rarely lose everything. You normally lose one region, one CDN, one server."
Rehearsal isn't only technical. It's knowing who's on the bridge, who owns communication, who owns root cause analysis — so the people fixing the problem aren't also the ones fielding questions from leadership mid-incident. That relationship has to be built ahead of time.
Lukas's counterpart is quieter: platforms with fairly deterministic channel counts and expected viewership let his team size compute ahead of time, with a growing share of transcoding moving to ASIC-based hardware for efficiency alongside CPU and GPU.
AI: Deterministic at Runtime, Probabilistic in Root Cause
"At IBC, we see the demos: you can prompt your LLM, it connects to your MCP server, and it tells you what's going on and what went wrong. That's fine, and at the demo, it works. Does it scale? Can you actually have an LLM process hundreds of thousands of logs per second? I don't think so. It's perfect for a demo, perfect for a POC — but that's not how we do it."
For live events, they want to know every possible path in advance — hence the preference for deterministic at runtime. Where AI does earn a place at Qualabs is in root cause analysis: pattern recognition and generating hypotheses for problems that haven't shown up before, augmenting the operator rather than replacing them — with one condition: under pressure, it all has to be rehearsed, with known playbooks and runbooks.
Lukas took the AI question toward cost, not capability: GPU demand is driving up hardware costs across the industry, and in his view that reaches even CDN pricing — he pointed to Akamai's price increase earlier this year as one example (his read from the panel, not an independently verified figure). Ben brought it back down to earth: AI isn't yet a big part of live production today, more useful in pre- and post-production — "but every single time I say that something is never going to happen, it does, like, next week."
The Ad-Break Question
One audience question asked what happens to support services — DRM licensing, monetization calls — when platforms move to lower-latency solutions like Media over QUIC. Bhavesh answered with an example of his own: during NBA Finals coverage, with SSAI in its early years, the first ad break with millions of concurrent viewers triggered an ad auction that needed to resolve in a quarter of a second and took 30 instead. No new segments, the manifest stalled, and roughly two million people lost video.
"The FIFA World Cup is more viewed than the NFL Super Bowl globally, but it's distributed across hundreds of different operators and broadcasters. So from a system standpoint — how many users are hitting your ad server — that's very different in one case or the other. It's not about how many millions are watching."
One million requests hitting a single ad server in the same second is a harder problem than ten million viewers spread across hundreds of servers. You need to trace the entire pipeline, from the camera on the field to the player, to find where the real bottlenecks are.
Closing Thoughts
Lukas asked platform owners to question their own defaults: why do you host the way you host, and does it actually still serve you? Ben pointed back to the audience: start from what people actually expect and want, then figure out the least complex way to deliver more of it.
"Scalability is something you design for, not something you buy later. So the earlier you understand the workflows and the bottlenecks, the cheaper scale gets, and the later you start, the more you pay. Not necessarily in invoices, but for sure in bad nights. You can put all the thought in the world into design and still not know what's going to break at kickoff until you've been there. Whatever you're building, find people who've been in the trenches, and listen to them before the event, not after."
Which loops back to where the panel started: scale was never one number. It's viewership, streams, diversity, and the humans holding it together — and the systems that survive aren't the ones that scored highest on a load test. They're the ones that rehearsed for what breaks.
The Takeaway
- Scale isn't one number. Track viewership, streams, diversity, and the human component separately — they move independently, and optimizing one can starve another.
- Design for scale, don't buy it later. The earlier you understand your workflows and bottlenecks, the cheaper scale gets.
- Rehearse degradation, not the happy path. You rarely lose everything — you lose one region, one CDN, one server. Practice for that.
- Make data actionable, not just available. A metric nobody can act on at 3am is noise.
- Know your signal flow across vendors. With three or more parties in the chain, you need to know exactly where it worked and where it stopped — before the event, not during it.
Thanks to Ben Ratner (LiveU) and Lukas Navickas (Servers.com), to Bhavesh Upadhyaya for moderating it as a conversation instead of three parallel interviews, and to Steve Nathans-Kelly and the Streaming Media Magazine team for the invitation.
The recording will be posted on Streaming Media Magazine's YouTube channel.
