// Media & Streaming × Real-Time AI Audit
Transcode cost and capacity audit for streaming platforms
A fixed-price audit for an always-on video fleet: what a minute of stream really costs, how many streams a box actually holds, and why the ceiling is rarely CPU.
// The problem
Why this is hard
An always-on fleet breaks the intuitions that a call product teaches you. There is no idle time to amortise, every source publishes twenty-four hours a day whether or not a single viewer is watching, and the two numbers that decide the bill — what a minute costs and how many streams a machine holds — are both routinely wrong in the same direction.
The cost surprise is that most of a real-time video bill is transcode, not bandwidth and not connection time. A quality ladder that is on by default re-encodes every publisher regardless of who watches the extra layers, and on an always-on source that is 43,200 minutes a month, every month, per source.
The capacity surprise is that the ceiling is usually not CPU. Hardware encoders enforce a session cap, and on consumer cards that cap is per system rather than per card — cross it and encoding can fall through to software silently, leaving a box that still works while its cost per stream multiplies. That is why headroom on a dashboard is not capacity, and why this has to be measured rather than modelled.
// How we do it
The approach for this fit
Cost per minute, priced on your path
An always-on source is 43,200 minutes a month. We price your actual configuration against your provider's published rates, so the difference between transcoding, not transcoding, and transcoding selectively is a number rather than an argument.
Cores and memory per stream, measured
On our own bench — a synthetic 1080p25 H.264 source, ffmpeg -benchmark, CPU-seconds per second of video — decode alone cost 0.13 cores, decode plus one small layer 0.30, and a full 1080p re-encode 0.79. Memory runs out on its own schedule: peak RSS was 0.22 GiB on that simulcast path against 1.03 GiB for the full re-encode, and it is the second number that decides how many streams a box holds. We re-run the same method on your hardware, because the ratio is what transfers, not the figure.
The ceiling that is not CPU
Hardware encoders cap concurrent sessions — eight on non-qualified cards, per system rather than per card. We establish where your ceiling sits and whether crossing it fails loudly or degrades in silence, which on our own box it did.
One probe per source, then a routing table
Most of a fleet's surprises are per-source: a codec profile one client class rejects, a level declared higher than a viewer will negotiate. A single probe per camera turns an irreversible-feeling change into rows that say safe, fixable without re-encoding, or keep transcoding.
// Proof
Measured on our own hardware
cores per stream, by path
decode only, decode plus one 360p layer (0.30), then a full 1080p re-encode — one 1080p25 H.264 source through ffmpeg -benchmark on an i9-14900. The spread is the entire economic argument for simulcast.
peak RSS per full re-encode
against 0.22 on the simulcast path. Thirty of them is ~31 GiB before the OS, the application and page cache — which is how a box sized on cores runs out of memory instead.
GPU utilisation at the encoder ceiling
on our own production box, re-verified 2026-08-01, while a live 1080p59 encode ran. Utilisation and session count are unrelated, so a dashboard reading 8% is not headroom.
Not a client outcome and not a vendor figure — numbers we took, on hardware we can name, with the method published in full.
// FAQ
Common questions
// Part of
// Let's build
Building Transcode cost and capacity audit for streaming platforms?
Tell us where you are. We reply within a day with a concrete next step.