Insights · Measured

Statmux vs CBR: measured VMAF on a live MPTS

3 August 2026 · 8 min read

Every vendor claims their statistical multiplexer improves quality. Almost none of them show you a number. So we measured it — same content, same encoder, the same total bitrate, split two ways — and then ran it at production scale. Here is what statmux actually buys you.

The question, stated precisely

A transport stream has a fixed bitrate budget. You can divide that budget two ways. CBR (constant bitrate) gives every channel an equal, fixed slice, whatever it is showing. Statmux (statistical multiplexing) hands the bits around in real time: a channel showing a still studio set gives bits back, a channel showing fast sport takes them — the peaks of one fill the valleys of another, and the aggregate stays inside the same transport budget.

The theory is old and uncontroversial. The useful question for an operator is narrower: on real content, at a realistic budget, how much quality does statmux actually move — and where? The only honest way to answer that is to measure it with a perceptual metric, not to assert it.

The test

We took a lossless 12-second excerpt of three 1080p services from a live MPTS and encoded it twice, with an identical total budget of 6 214 kbps. In the CBR run every channel got an equal share. In the statmux run the same 6 214 kbps was allocated by scene complexity. Then we scored both with VMAF — Netflix's perceptual quality model, which correlates with what viewers actually notice far better than PSNR.

Crucially, the per-channel complexity used to split the statmux budget was measured independently, at CRF 23, rather than taken from the live allocator's own decisions. That avoids a circular result where the multiplexer is graded against its own assumptions.

The numbers

Same content, same encoder, same 6 214 kbps — the only difference is how the bits are split.

ChannelVMAF · CBRVMAF · statmuxΔ
Jednotka 2071 → 1320 kbps82.2779.88−2.39
RTVS Šport 2071 → 2260 kbps66.9767.56+0.59
Dvojka 2071 → 2633 kbps61.8965.87+3.98
Worst channel61.8965.87+3.98
Spread across channels20.3814.0131% tighter
Mean70.3871.10+0.73
Three 1080p services, identical 6214 kbps budget. Model vmaf_v0.6.1, x264 preset medium, identical settings for both variants.

Read the mean and you would shrug: +0.73 VMAF is nothing. That is exactly why the mean is the wrong number to look at.

Why the average lies

Statmux did something specific. It took bits away from the easy channel — Jednotka, a low-motion service — and gave them to the hard ones. Jednotka dropped 2.4 points, to 79.9. But 79.9 VMAF is comfortably inside the range where no viewer notices anything; it gave away bits it could not use.

Those bits went where they mattered. The hardest channel, Dvojka, gained a full 4 points. And the spread between best and worst channel tightened by 31%.

Subscribers don't judge you on the average. They judge you on the worst channel in the line-up — and that is the one that improved most.

A subscriber flips through the whole bouquet. One channel that visibly falls apart during a match is the one that generates the support call and the churn — not the twelve channels that all look fine. CBR spends the budget as if every channel were equally demanding at every moment, which is never true. Statmux spends it where the picture is actually at risk. The right way to read the table is not "+0.73 on average" but "+4 on the channel that would have failed."

At production scale

The three-channel test isolates the mechanism. The real system runs it under full load: a production MPTS of 13 services plus a playout channel — 14 encoder sessions on a single RTX 5070 Ti, a consumer card — sampled over three minutes.

98.4%Transport filled by services — minimal null padding
14Encoder sessions on one RTX 5070 Ti · 33% GPU average
5.6 msAverage encoder latency
±6 bpsMPTS stability at a 37.99 Mbps aggregate

And here is the quality that run actually delivered — every one of the 13 services scored by VMAF over 2 400 frames. Mean 91.1, eight of thirteen above 90, all on one consumer GPU.

ChannelVMAF · meanWorst 5%kbps
JOJ Plus96.9991.693034
TA395.3293.642458
Auto Moto und Sport93.5983.173119
Jednotka92.7985.773333
Doma92.1082.842800
ČT2490.4581.032589
Dvojka90.4068.823281
JOJ90.2072.842736
Markíza Klasik89.7579.372692
RTVS Šport89.4077.722906
Markíza88.3066.723023
JOJ Svet87.9955.583218
JOJ Šport87.6576.832695
Mean · 13 services91.137.9 Mbps
Measured on tsc01, 2026-08-03 — 13 services in one MPTS, 2 400 frames each, model vmaf_v0.6.1. "Worst 5%" is the 5th-percentile frame (hardest motion, where any encoder dips); the mean is what a viewer sees across the programme.

Per-channel bitrate swung up to 1.86× and spread 1.94× across the pool — one service moved from 2.13 to 4.13 Mbps as its scenes demanded, while the aggregate held to within a few bits per second of target. The transport ran 98.4% full of actual picture: almost every bit that was not overhead was spent on video, not on null padding. That is the other half of the statmux argument — CBR leaves stuffing in the pipe; statmux does not.

And it did all of that on a €-few-thousand consumer GPU doing work that would otherwise call for a Tesla A16 or an RTX 6000 Pro. The 28-channel version of these VMAF figures is embedded live on our statmux page — measured on the running production encoder, updating itself.

What it means for spectrum and cost

Fit more channels into fewer, fuller muxes and two things follow. You occupy a smaller, contiguous slice of spectrum instead of spreading QAM-256 across the whole band — which means you can spend the freed spectrum on a more robust modulation (deeper guard interval, DVB-T2) instead of demanding a perfect plant end to end. And you carry the same line-up on less hardware: fewer transponders, fewer muxes, one GPU doing the encoding.

For a spectrum-scarce estate — an MMDS licence that gives you five or six usable carriers, or three DVB-T2 multiplexes and that is the whole plant — this is not an optimisation. At five carriers it is the difference between a line-up subscribers will pay for and one they will not.

Methodology, in full

  • Source: a 12-second lossless excerpt of three 1080p services from a live MPTS.
  • Budget: identical 6214 kbps total for both variants; only the per-channel allocation differs.
  • Complexity: measured independently at CRF 23, not taken from the live allocator, to avoid a circular result.
  • Metric: VMAF model vmaf_v0.6.1; x264 preset medium; identical encoder settings for CBR and statmux.
  • Production run: 13 services + 1 playout channel, 14 NVENC sessions on one RTX 5070 Ti, sampled over 3 minutes; the 28-channel figures are measured live on the production encoder.

Numbers without a method are marketing. The method is here so you can argue with the numbers — that is the point.

See it running

The 28-channel VMAF figures above are embedded live from the production encoder on the statmux page — they update themselves from the running system.