2 October 2026

Video Quality Metrics Explained: VMAF, SSIM and PSNR (2026 Guide)

A property window shows you a bitrate and a resolution. Neither one tells you whether the picture got worse. That is the gap video quality metrics fill: they compare a compressed file against its original and return a number you can trust more than your memory of how the footage looked last Tuesday.

The three names you will meet most are PSNR, SSIM and VMAF. Each measures the same thing from a different angle, and each one can fool you if you read it alone.

You probably do not need any of them for a single export at a sensible setting. They earn their keep in three places: choosing between two encoders, checking whether an aggressive compression pass actually damaged the picture, and settling an argument about which of two exports looks better.

The Direct Answer: Which Video Quality Metric Should You Use

Reach for VMAF when your build has it, SSIM to compare two encodes of your own footage, and PSNR only as a rough alarm. None of the three is a taste test, but that order follows how closely each one tracks what a viewer notices.

Metric	Scale	What it compares	Best used for
PSNR	Decibels, higher is better	Squared difference between pixel values	A fast warning light; spotting catastrophic damage
SSIM	0 to 1, higher is better	Local brightness, contrast and structure	Comparing two encodes of the same source
VMAF	0 to 100, higher is better	A model learned from human viewing tests	Judging perceived quality, especially at low bitrates

PSNR works in decibels and counts the squared difference between pixels, so it reacts to any value that changes and knows nothing about whether the change is visible. SSIM walks over the frame in small windows and compares local brightness, contrast and structure, which is a closer model of the eye. VMAF goes further and predicts a rating learned from human test panels.

The practical consequence is blunt. A PSNR figure that falls from 45 dB to 38 dB can describe damage you cannot see, while the same file’s SSIM barely moves.

Before You Measure: What You Need in Place

Two inputs and one command are the whole setup, but the inputs have to be honest.

You need a reference file you trust, preferably a lossless or near-lossless master. You also need a test file that shares the reference’s resolution, pixel format and frame count, so that the only difference between them is the setting you are judging. Change one variable at a time.

For the command line you need an FFmpeg build with the SSIM and PSNR filters, which almost all modern builds include. VMAF is the exception and has to be compiled in. Check what your build carries before you plan around it:

ffmpeg -hide_banner -filters | grep -E "ssim|psnr|libvmaf"

If you are choosing a setting rather than an encoder, the trade-off you are actually measuring is the one covered by constant quality and average bitrate modes, which decide how the encoder spends its bits in the first place.

Method 1: Measure Video Quality Metrics With FFmpeg

FFmpeg ships both SSIM and PSNR as filters, so the whole job runs from one terminal in three steps: build a reference, encode a test file, compare the two. If the flags look unfamiliar, the everyday FFmpeg commands cover the same syntax with worked examples.

First, make a reference copy of the source that carries no compression loss. For H.264 that means the -qp 0 setting, which turns off quantisation entirely:

ffmpeg -i source.mov -c:v libx264 -qp 0 -pix_fmt yuv420p reference.mp4

Second, encode the test file at the setting you are weighing. Keep the geometry identical to the reference:

ffmpeg -i source.mov -c:v libx264 -crf 23 -preset medium -pix_fmt yuv420p test.mp4

Third, compare them. The ssim and psnr filters each take both videos and print a result to the log, and the full syntax is documented in the FFmpeg filter documentation:

ffmpeg -i test.mp4 -i reference.mp4 -lavfi "[0:v][1:v]ssim;[0:v][1:v]psnr" -f null -

Read the SSIM All figure and the PSNR average. SSIM also prints a value per channel, which is how you catch a problem that lives only in the colour. The first input is the file being judged and the second is the reference; swap them and the scores stop meaning anything.

To show what the output looks like, here is the same three-second 720p clip at four CRF settings, each measured against a lossless reference on this machine:

CRF	File size	SSIM (All)	PSNR (average)
18	6.91 MB	0.9400	41.18 dB
23	1.10 MB	0.9212	39.41 dB
28	0.51 MB	0.9138	37.27 dB
35	0.21 MB	0.8986	34.47 dB

The interesting column is the one that hardly moves. Dropping from CRF 23 to CRF 18 multiplies the file size by 6.3 and buys 0.019 SSIM and 1.8 dB. Going the other way, CRF 23 to CRF 35 cuts the file by 81 percent and costs only 0.023 SSIM and 4.9 dB. The same arithmetic sits behind every compress a video without losing quality decision.

These are one clip’s numbers on grainy synthetic footage, which compresses differently from a talking head, so treat the shape as the lesson rather than the exact figures. The general finding holds: past a certain point you spend enormous amounts of storage for a change the eye will not register.

A second measurement matters more than the ladder. Take an already-encoded file and encode it again at the same setting, and the loss compounds while the size does not shrink:

Pass	File size	SSIM (All)	PSNR (average)
First encode	1.10 MB	0.9212	39.41 dB
Second encode	1.13 MB	0.9194	38.73 dB
Third encode	1.11 MB	0.9182	38.32 dB

The file did not get smaller. It got slightly larger and measurably worse. That is the usual result of re-encoding a compressed file at a similar setting: you pay in quality and save nothing.

Codec choice shows up here too. At CRF 23 the x264 encode scored 0.9212 SSIM at 1.10 MB, while an x265 encode at CRF 24 landed at 0.9212 SSIM in 0.98 MB, about 11 percent smaller for the same measured quality.

Push x265 to CRF 26 and the file slips to 0.76 MB with SSIM easing to 0.9197. The saving is real, but it is a slice rather than a halving, and the cost of H.264 and H.265 trade-offs elsewhere, such as playback support, is not in these numbers at all.

Method 2: VMAF, and the Free Shortcuts in Your Existing Tools

VMAF is the metric most people want and the one most likely to be missing. It was built at Netflix and published as open source, so the reference implementation lives in Netflix’s VMAF repository, and FFmpeg can call it only when the build was compiled with libvmaf.

If the filters command returned nothing for libvmaf, the filter is not there. The FFmpeg build on this machine lists psnr, ssim, vif and xpsnr but not libvmaf, which is exactly why the measurements here are SSIM and PSNR rather than VMAF. You can install a build that includes it, or work with the filters you already have. Once the filter exists, the command mirrors the one above:

ffmpeg -i test.mp4 -i reference.mp4 -lavfi libvmaf -f null -

Your editor is the third route, and usually the least useful. Most timelines show none of these numbers, and the ones that do tuck them into an export report or a quality panel. That is not much of a loss. If you are judging one export rather than a hundred, your eyes at full size on a decent screen remain the most honest instrument you own.

What Video Quality Metrics Actually Do, and What They Miss

Every metric here is full-reference, which means it can only answer a comparison, never a verdict. You cannot ask whether a file is good without an original to measure against, and the answer changes with the original you pick.

They are also brutal about alignment, and this is the trap that catches anyone comparing scores across two tools. Take the reference, shift the whole frame two pixels to the left, and measure again. Nothing in the picture has changed except its position on the grid.

A two-pixel shift scores 0.8038 SSIM and 25.45 dB. A one-pixel shift scores 0.9963 SSIM and 33.64 dB. A PSNR of 25 dB would normally read as badly damaged footage, yet the frame is intact and a viewer would see no difference at all.

So the numbers reward alignment and punish motion a viewer would never notice. They also say nothing about audio, dropped frames, playback support, banding, or whether the content is worth watching. A file can score beautifully and still stutter on the phone it was made for. Scores are not portable either: two encodes measured against different references, or at different resolutions, cannot be lined up next to each other.

Rights and Responsible Use

Measuring the quality of a video is a technical act on a file you hold. It does not change who owns the footage. The clip belongs to whoever created it, and running a comparison on a copy grants you no claim over the original, however many times you re-encode it.

Private study and work on your own material are one thing; republishing someone else’s clip is another. If you benchmark encoders with a video you did not shoot, keep the files and the scores to yourself rather than posting the clip beside your results.

Be careful with web-based quality checkers as well. Uploading a file hands a copy to a third party, and that copy sits on a server you do not control. Where you publish your own work, the destination’s terms set the limits, and YouTube’s Terms of Service are the ones that matter for the most common destination.

Troubleshooting: When a Video Quality Metric Gives a Strange Answer

SSIM reads 1.000000 and PSNR reads inf

You are comparing a file with itself, or with a lossless copy of it. A perfect score is only possible when the two videos are identical frame for frame, so check that the second input is the real reference and not the file you meant to test.

The two files have different frame counts

Frame-by-frame metrics compare position one with position one. A trimmed clip, a variable frame rate recording or a single dropped frame misaligns everything after it, and the score collapses or the filter errors out. Rebuild both files to the same length and cadence first.

FFmpeg says the libvmaf filter does not exist

Your build was compiled without it. Run the filters command to confirm, then either install a build that includes libvmaf or measure with SSIM and PSNR, which are present in most builds.

The score falls off a cliff after a tiny change

The geometry moved. Resizing, cropping or shifting the frame by even a pixel or two destroys alignment, and the metrics punish that far more harshly than they punish visible damage. Only compare files with identical dimensions and framing.

Both files look fine, but the score is poor

The source is grainy or noisy. Fine grain is nearly impossible to reproduce exactly, so the metric counts it as error and the numbers sink even when the picture is faithful. Make sure the reference is the true source and not a re-encode, or you are measuring two losses instead of one.

The “original” you measured against was already compressed

Then you measured generation loss, not your own encode. A compressed reference sets a low ceiling and makes every test file look worse than it is. Always compare against a lossless or near-lossless master.

Frequently Asked Questions

What are video quality metrics in simple terms?

They are scores that compare a compressed video against its original to estimate how much visible quality was lost. PSNR counts pixel differences, SSIM compares local structure, and VMAF predicts what a human panel would say.

Is a higher PSNR always better?

No, and PSNR is the weakest of the three. It reacts to any pixel change, visible or not, so it can read as badly damaged on a file that merely moved a couple of pixels, while a genuinely watchable encode of a noisy source can look poor. Treat a PSNR figure as a warning light, not a verdict.

What counts as a good SSIM score?

There is no fixed pass mark. On my grainy test clip, scores near 0.92 looked correct, so the useful signal was the gap between two encodes of the same source, not the absolute number. Compare your own exports against each other rather than against a figure you read somewhere.

What VMAF score is good enough?

Higher is better on the 0 to 100 scale, and VMAF is designed to track human judgement more closely than the other two. I could not measure it here, because this machine’s FFmpeg build has no libvmaf, so treat any exact threshold you see quoted as a convention to test on your own footage.

Can I measure video quality without installing anything?

Often, yes. FFmpeg includes SSIM and PSNR in most builds, and some encoders print an SSIM or PSNR figure in their own log at the end of an export. VMAF is the one that usually needs a special build.

Why do the scores disagree with my eyes?

Because the metrics are not watching the video; they are doing arithmetic on pixels. They do not know about banding that shows only in gradients, audio that drifts out of sync, or a file that will not play on the target device. When the number and your eyes disagree, trust your eyes.

Does a smaller file always mean worse quality?

No. A better encoder can deliver the same measured quality in a smaller file. In my test, x265 matched x264’s SSIM in about 11 percent less space, and the setting you choose matters far more than the codec badge on the container.

Which Video Quality Metric Should You Use?

Use the cheapest one that answers your question. If you are choosing an export setting and only need to confirm that nothing broke, SSIM and PSNR from FFmpeg cost you two lines of shell and nothing else. If you are tuning an encoder or comparing codecs seriously, run VMAF alongside SSIM and compare the same clip across settings, never across clips.

And if you are exporting one video for one destination at a sensible CRF, skip the metrics entirely. Your eyes on the finished file at full size are quicker, and they are the only instrument on this list that can also tell you whether the audience will enjoy it.