
PSNR is the metric everyone learns first, and the one working streaming engineers mostly stopped trusting. It compares pixels mathematically and correlates with what a human actually sees only loosely, somewhere around 0.6 to 0.7 on a 0-to-1 scale in Netflix's own validation testing. VMAF was built to fix that gap, and it now shows up directly inside AIOZ Stream's own quality-of-experience formula, not just in Netflix's encoding pipeline.
TL;DR:
PSNR measures the mathematical difference between a compressed frame and its source, pixel by pixel. That's a fine engineering signal for some purposes, but it doesn't know that a small amount of blur in a busy, high-motion scene is nearly invisible to a viewer while the same numeric error in a static closeup on skin tone is glaring. SSIM improved on this by comparing local structure and contrast instead of raw pixel values, and it's a real step up, but it still isn't trained on what people actually report seeing, it's still a mathematical proxy for perception rather than a measurement of it. Netflix's own published validation puts PSNR's correlation with human subjective scores at roughly 0.6 to 0.7, which is usable for rough comparisons but not reliable enough to make a real per-title encoding decision on.
VMAF doesn't invent a new way of comparing pixels; it combines several existing ones and lets a trained model decide how much weight each deserves. The elementary features feeding in include VIF (Visual Information Fidelity, computed at four different spatial scales), ADM (Detail Loss Metric, which separates loss of detail from added noise), and a temporal feature that tracks frame-to-frame motion. Those features get fed into a regression model, originally a support vector machine with a radial basis kernel, more recently a random-forest variant in Netflix's newer bootstrap models, that was trained against real subjective scores. Netflix's own lab collected those scores by showing viewers clips on a calibrated 1080p display at a fixed viewing distance and having them rate quality directly, the same kind of panel testing broadcast standards bodies have used for decades. The model then learns the mapping from "these feature values" to "how a real panel of people actually rated this," which is the part PSNR and SSIM never do.
The output is a single number from 0 to 100, where 100 means the encode is perceptually indistinguishable from its reference and 0 means it looks nothing like it. The scale is built to line up with a five-point subjective rating panel, "bad, poor, fair, good, excellent," with "bad" mapped to roughly 20 and "excellent" to 100. Streaming Learning Center's own best-practices testing found a score around 70 lands between a "good" and "fair" vote under the standard 1080p viewing condition, and scores in the mid-90s land solidly in "excellent." Common encoding guidance built on that same scale treats 90-95 as excellent for a large screen, 80-89 as good enough for social or fast-moving content, 70-79 as acceptable under real bandwidth constraints, and anything below 70 as noticeably degraded, though none of that is an official Netflix cutoff, it's downstream engineering practice built on top of the score.
The practical use of those bands shows up most directly in per-title encoding: picking the top rung of a bitrate ladder. Rather than encoding every title at the same fixed top-rate bitrate, an encoder can search for the lowest bitrate that still clears a target VMAF score, commonly somewhere in the 93-95 range for the highest rendition, and stop there instead of spending bits the metric says aren't buying any visible improvement. A slow-moving talking-head video might clear that target at a noticeably lower bitrate than a fast-motion sports clip, and a fixed one-size-fits-all top rate either wastes bandwidth on the easy content or shortchanges the hard content. That's the actual economic reason this metric matters beyond a QA checkbox: it turns "what bitrate is good enough" from a guess into a measurable target.
A VMAF score isn't portable between viewing conditions the way a resolution or bitrate number is. Netflix's own model documentation ships a default model built around 1080p viewed at three times the screen height, a separate 4K model built around a much closer 1.5x-screen-height viewing distance, and a phone-specific model, because the same distorted video is perceived as higher quality on a small screen held close than on a large TV. Comparing a 4K-model score against a 1080p-model score, or quoting a bare number without saying which model produced it, isn't a small omission, it changes what the number actually means. In practice this trips up exactly the teams who should know better: a QA pipeline that runs the default 1080p model against 4K masters, or benchmarks a mobile-first product against the TV-viewing model, will report quality problems that don't exist for the audience actually watching, or miss real ones that do. The fix isn't complicated, just consistent, pick the model that matches the actual target screen and viewing distance for the content in question, and record which model produced a given score anywhere the number gets reported or compared later.
Two limitations are worth taking seriously rather than glossing over. First, VMAF scores aren't comparable across different source content, only between different encodes of the same source. Netflix's own writing on the metric gives a clean example: a stream generated from a standard-definition source scoring 99 out of 100 doesn't mean it looks as good as an HD source scoring 99, both are near-perfect reproductions of very different starting points, not equally good pictures. Second, VMAF can be gamed, intentionally or not, by enhancement filters. A sharpening pass can push a VMAF score up without making the video genuinely closer to a clean, high-quality source, since sharpening changes exactly the kind of detail-edge information VMAF's ADM feature is sensitive to. Netflix built a "No Enhancement Gain" (NEG) variant specifically to strip that effect out for codec-versus-codec comparisons, where you want to know how well a compression algorithm performs, not how much a pre-processing filter flattered it.
This isn't purely academic for anyone building on AIOZ Stream specifically. The platform's own documented quality-of-experience model expresses QoE as perceived quality, measured via VMAF, minus a rebuffer penalty and a startup penalty, plus a stability term for how often the player switches renditions, with a stated target of "high and steady rather than chasing the maximum." AIOZ Stream's docs are explicit that VMAF isn't a mandatory input, a team can run the platform without ever computing it, but they frame it as the best available proxy for what a viewer's eyes actually register, which matches how the wider industry treats it. The QoE article covers the full six-metric formula and its startup/rebuffer targets in depth; this one is about the single term inside it that does the heaviest lifting on picture quality specifically.
Is a higher VMAF score always better?
Within the same source and same viewing model, yes. Across different sources or different VMAF models (1080p vs 4K vs phone), scores aren't directly comparable, so a higher number in a different context doesn't mean better quality.
What VMAF score should I target for a top-quality encode?
Industry encoding guidance built on Netflix's scale generally treats 90-95 as excellent and anything above 95 as visually transparent for most viewers, though this is downstream practice, not an official Netflix threshold, and depends on which VMAF model is used.
Can VMAF be fooled by sharpening filters?
Yes. Sharpening can raise a VMAF score without a genuine quality improvement, which is why Netflix built the No Enhancement Gain (NEG) model variant specifically for fair codec comparisons.
Is VMAF the same as PSNR or SSIM?
No. PSNR and SSIM are mathematical comparisons between two images. VMAF fuses several such features (including VIF and ADM) through a model trained on real human subjective ratings, which is why it correlates with perceived quality far better.
Does AIOZ Stream require VMAF to be computed?
No. AIOZ Stream's own documentation describes VMAF as "not mandatory" within its QoE composite model, while still treating it as the primary picture-quality proxy when it is available.
Why does the viewing distance matter for a VMAF score?
Because the same encode looks different at different viewing distances and screen sizes. Netflix ships separate models tuned for 1080p television viewing, 4K television viewing, and phone screens for exactly this reason.

AIOZ's Audio API stores, transcodes, and streams audio well. It has no RSS feed generation, the actual mechanism Apple Podcasts and Spotify require.

Three codecs solve the same problem. Which one wins in practice depends on patent licensing and hardware decode support as much as compression efficiency.

Resolution and codec live inside a qualities array. H.264 caps at 4K on AIOZ Stream, so an 8K output needs H.265, and the compute cost isn't small.

AWS states an exact 11-nines durability figure. Decentralized networks prove durability differently, and don't all use one method. Here's how each actually works.

AIOZ Stream splits uploads into 50-200MB parts across three API calls. Here's the raw chunking loop, and what the docs don't say about resuming a failed one.

A fixed ladder wastes bits on simple content and starves complex content. Here's how per-title and per-shot encoding actually build a better one, with real numbers.