How to Read a BD-Rate Curve and Compare Two Codecs Honestly

A BD-rate number is the single most cited figure in codec comparison, and it is one of the easiest to quietly rig. "15% BD-rate improvement" sounds definitive. Whether it means anything depends on questions the headline never shows: which metric, which bitrates, which decoder, at what latency.

BD-rate itself is a sound, well-defined tool. The dishonesty, when it happens, is in the setup around it. A comparison can be technically correct and still misleading if the two codecs were not run under conditions a user would ever face.

This piece explains what BD-rate measures, the specific ways benchmarks mislead, and the checks that separate a real result from a flattering one. It is written from the position we hold ourselves to when we publish our own numbers.

Key Takeaways

• BD-rate is the average bitrate difference between two codecs at equal quality, measured as the area between their rate-distortion curves (Bjontegaard, 2001).
• A negative BD-rate is good: it means fewer bits for the same quality. The sign convention trips up almost everyone at first.
• The number is only as honest as its setup: the quality metric, the bitrate range, and whether bitrate was really coded or merely estimated.
• The most common distortion is ignoring the latency tax: a codec that wins on quality but decodes too slowly to deploy has not won anything usable.
• Compare like with like. Same content, same metric, real coding, and speed measured on the same hardware.

What does BD-rate actually measure?

BD-rate measures the average difference in bitrate between two codecs at matched quality. You encode the same content at several quality points with each codec, plot quality against bitrate for both, and compute the area between the two curves. The result is expressed as a percentage: how many more or fewer bits one codec needs for the same quality.

The method comes from Gisle Bjontegaard's 2001 proposal to the ITU-T video coding group, which is why it carries his initials (Bjontegaard, VCEG-M33, 2001). It integrates the gap between the curves so a whole quality range collapses into one comparable figure.

The sign convention is the first trap. A negative BD-rate is the good result: it means one codec achieves equal quality at lower bitrate. A "minus 15% BD-rate" is a 15% bitrate saving, not a loss. Getting this backward is the single most common misreading, and it rests on the rate-distortion curve explained in rate-distortion theory for practitioners.

Why can two BD-rate numbers disagree?

Because BD-rate is a function of choices, and different choices give different numbers on the same codecs. The quality metric, the range of bitrates tested, and the number of points all change the result. Two honest teams measuring the same pair of codecs can report different figures simply because they set up the curves differently.

The quality metric is the biggest lever. A BD-rate computed against peak signal to noise ratio can look very different from one computed against a perceptual metric, because the two disagree about what quality even is. A codec tuned to win on PSNR may lose on a metric that tracks human vision, and vice versa. That gap is the subject of PSNR vs SSIM vs looks good to humans and why SSIM falls short of human vision.

A BD-rate figure with no stated metric, no bitrate range, and no content set is not a weak result. It is not a result at all. The number without its setup is a marketing artifact, and treating it as comparable to a fully specified figure is the error the setup is designed to exploit.

How do benchmarks mislead without lying?

By choosing conditions that favor one codec and omitting the conditions that would show the cost. Nothing in the numbers is false. The distortion is in what surrounds them: cherry-picked content, a metric the winner was tuned for, a bitrate range that hides where it falls apart, and, most often, a decode speed nobody reports.

The pattern we watch for most is the estimated-bitrate shortcut. Some comparisons do not actually code the bitstream. They estimate what the rate would be from a model or a proxy, then plot that estimate as if it were a coded file. Estimated bitrate flatters, because it skips the real cost of entropy coding and the overhead a deployable decoder must handle. We only trust curves built from real coding, actual encoded files at actual sizes, which is a rule we state plainly in our benchmark methodology.

The fix for the reader is a habit, not a formula. Ask what content, what metric, what bitrate range, real or estimated bitrate, and what hardware. If any answer is missing, the comparison is not yet one you can act on. The same content-dependence that breaks single quality settings, covered in why blanket compression hurts your CMS, also lets a benchmark pick its battlefield.

What is the latency tax, and why does it decide the winner?

The latency tax is the decode and encode time a codec costs, and it routinely decides whether a quality win is usable. A codec can post a beautiful BD-rate and still be undeployable because it decodes too slowly for the target, whether that is a web page, a live stream, or a device. Quality per bit is only half the trade. Time per frame is the other half.

This is where many neural codec claims quietly fall apart. Impressive rate-distortion results are sometimes produced by models that take far longer to decode than the adaptive codec they beat, so the comparison holds quality constant while hiding a speed regression the user would feel immediately (JVET, Versatile Video Coding overview, 2020). A win that cannot ship at the required latency is not a win.

Honesty here means reporting speed alongside quality, on defined hardware, at a latency the deployment actually requires. This is exactly why we frame our own results around deployable latency rather than an unconstrained quality ceiling, and it connects to the difference between neural and adaptive compression and the cases in when neural compression fails.

How do we hold our own Epiron benchmark to this bar?

By stating every condition the number depends on and refusing the shortcuts above. When we say Epiron beats H.266/VVC on BD-rate, we mean real coding at deployable latency, not estimated bitrate and not an unbounded quality target. The comparison runs all-intra, so every image is coded on its own, which is the correct setting for image mode and the fairest basis for an image-quality claim.

The decode-speed claim carries its own caveat, and we state it rather than bury it. Our decode-speed advantage is measured against the neural field, other neural approaches, on the same hardware. It is not a claim that we decode faster than a CPU implementation of H.266, which would be a different and easier contest against a different opponent. Naming the opponent is part of the honesty.

Under the hood, the Neural Media Orchestrator evaluates each asset and routes it across 352 possibilities, reaching up to 95% neural compression savings on photographic sources while holding structural similarity at or above 0.975 against the original, and remaining Pareto-safe by routing so no result exceeds the strongest adaptive baseline. The full setup, content, metrics, and hardware, is published in the Epiron benchmark and our benchmark methodology hub. The color-detail dimension of a fair image comparison is in chroma subsampling explained.

Frequently Asked Questions

What is a good BD-rate value?

A negative BD-rate is good because it means fewer bits for the same quality. A result of minus 15% means one codec reaches equal quality using 15% less bitrate than the other. The sign matters: positive BD-rate means the codec needs more bits, which is worse.

Does BD-rate depend on the quality metric used?

Yes, heavily. BD-rate measured against PSNR can differ substantially from BD-rate against a perceptual metric, because the metrics disagree about what quality means. A codec tuned for one metric may lose on another. A BD-rate figure is only interpretable when its quality metric is stated.

What is estimated bitrate and why is it a problem?

Estimated bitrate is a modeled guess of a file's size rather than the size of an actually coded bitstream. It flatters results because it skips the real cost of entropy coding and decoder overhead. Honest benchmarks use real coding: actual encoded files at their actual sizes, not estimates.

What is the latency tax in codec comparison?

The latency tax is the encode and decode time a codec costs. A codec can win on BD-rate yet decode too slowly to deploy, making the quality win unusable. Honest comparisons report speed alongside quality, measured on defined hardware at the latency the real deployment requires.

How should I compare two codecs fairly?

Use the same content, the same quality metric, and real coded bitstreams rather than estimates, across a bitrate range that covers real use. Report decode and encode speed on the same hardware. If any of these conditions is missing or differs between the two codecs, the comparison is not yet trustworthy.

The point

BD-rate is a good tool wrapped in easy dishonesty. The number is well defined, but its meaning lives entirely in the setup: which metric, which content, real coding or estimates, and at what latency. Strip those away and a confident percentage tells you nothing you can act on.

Reading one honestly is mostly a matter of asking for the conditions and declining to be impressed until they arrive. That is the standard we hold our own numbers to, which is why every Epiron claim travels with its metric, its all-intra setting, its deployable-latency constraint, and a named opponent for the speed comparison. The complete setup is in the Epiron benchmark and our benchmark methodology.