Two files, the same size.
You decide which one is better.
This comparison was chosen because our own metric loses it. VMAF puts plain x264 one point ahead. We publish it anyway, because there is a region where the metric and the eye disagree, and inside it a number cannot make the decision for you.
This page submits nothing. There is no form and no tracking tag. The judgement stays with you.
1. What you are looking at
One 4K nature clip (3840x2160, 20.35 s, 610 frames), encoded two ways to almost the same file size. The only thing withheld is which is which. Every figure is disclosed below. The sizes differ by 4%, and the larger file is also the one with the higher VMAF.
| A | B | |
|---|---|---|
| file size | 8,518,743 B | 8,192,633 B |
| VMAF | 70 | 69 |
| sha256 (first 24) | e2790a054008d018f8bdd73b | 9bb395a09fffb82a9f3f2299 |
What is served here is the measured artefact itself. Nothing was re-encoded for the web — a re-encode would mean the artefacts you see are no longer the artefacts that were measured.
2. Judge from stills (1:1)
720x405 crops taken at the same timestamp (10 s) and the same coordinates, with no scaling. If your browser shrinks them the difference disappears — click an image to view it at native size.
Scree — high-frequency detail
Water — a flat area, where blocking shows
Full frame (context; downscaled to 1280)
3. Judge from motion
What a still shows and what motion shows are not the same thing. Both are here.
4. The answer
Click to reveal
A = plain x264 (VMAF 70, 8,518,743 B) / B = with Norm (VMAF 69, 8,192,633 B)
VMAF says A is one point better. Did your eye agree? Either answer is fine — nothing was collected from you, and one person's impression does not settle a product. The point of the page is narrower: in this region the number cannot make the judgement for you.
5. Why this pair — quoted from the ledger
| ledger id | nature.isosize.control |
|---|---|
| ledger level | measured-on-disk |
| text | nature 4K iso-SIZE ~8MB: plain x264 VMAF70 (8.1MB) vs Norm VMAF69 (7.8MB) — x264 >= Norm at equal size |
| value | x264 VMAF70 >= Norm VMAF69 @8MB |
| artifact | nature_test |
| caveat (from the ledger) | The honest iso-size control for nature, sitting in the SAME folder as the '42%' files. At equal size plain x264 is slightly AHEAD (70 vs 69). This REFUTES a Norm-specific iso-quality win on nature. |
| ledger id | blind.isosize.cityhall.3mbps |
|---|---|
| ledger level | measured-logged |
| text | Blind iso-size still comparison, CityHall 4K60 @ ~3 Mbps, x264(--strength 0) vs norm(--strength 0.30 --adaptive --temporal). Viewer described P as 'sharp but visible blocking on the dark flat car body' and Q as 'softer, less detail'. Reveal: P=norm, Q=x264. The two ARE distinguishable at equal size, and the blocking sits on the NORM side. |
| value | norm = blockier on flat surfaces; x264 = softer |
| artifact | _v051_test/isoblock/iso_{x264,norm}_3000.mp4 ; blind crops + sealed key |
| caveat (from the ledger) | INFORMAL, NOT a result. n=1, the viewer was Claude (not a human), STILLS not motion, ONE operating point at 4K60 3 Mbps where VMAF is ~53 - just above the band PROTOCOL excludes from operational judgement - and the sizes differ by 2.8% (norm larger). Also THREE variables move at once (strength 0.10->0.30, +adaptive, +temporal) so nothing is attributed. The viewer's DESCRIPTION was right but the ATTRIBUTION was backwards, which is why the key was sealed. Must not be rendered as a product claim in either direction. |
6. Reproducing the crops
The crops are reproducible; the timestamp and the coordinates are fixed.
ffmpeg -ss 10 -i <file> -frames:v 1 -vf "crop=720:405:1700:900" scree.png # scree (high frequency)
ffmpeg -ss 10 -i <file> -frames:v 1 -vf "crop=720:405:600:1500" water.png # water (flat area)7. Related
- Product page: SlimeCodec
- Other materials: SlimeCodec resources
- Index: Resources