I always consternate over what the ‘Preset’ setting should be when doing H.264 encodes with Handbrake. It’s always tempting to slide right on over to ‘placebo’ to, in theory, ensure you’ve got the best possible encoding. And in my experience that at least roughly works – file size decreases (marginally) as you use more time-consuming encoding Presets, for equivalent quality.
Now that I’m transitioning to H.265 instead, I thought I’d do a ‘quick’ experiment to see how it behaves in comparison, encoding from a ProRes 422 4000×3000 timelapse at constant quality 22. A 270° rotation was performed in the process. No audio.
The result is baffling.
| Preset | File size (MiB) | Encode time (Hours) |
|---|---|---|
| Placebo | 329 | 16.65 |
| Veryslow | 218 | 3.70 |
| Slower | 219 | 2.75 |
| Slow | 183 | 0.93 |
| Medium | 185 | 0.53 |
| Fast | 156 | 0.36 |
| Faster | 155 | 0.31 |
| Veryfast | 155 | 0.31 |
| Superfast | 129 | 0.23 |
| Ultrafast | 83 | 0.22 |
The outputs should all be visually essentially identical, by virtue of constant-quality encoding with the same quality factor. However, they are not – there’s a small but quite visible difference in quality, with the slower-encoded versions having progressively more detail retained, while at the other end, the faster encodings, it looks like a strong noise reduction pass has been applied (which isn’t literally what’s happened, I assume, but rather the consequence of a lower-quality encoding).
Regardless of the specifics, this shouldn’t be happening. ‘Constant quality’ seems quite self-explanatory.
Note also how the encoding times go up exponentially – ‘placebo’ was really gruelling, as the equivalent H.264 encode would have been an order of magnitude shorter, and that’s what I’d budgeted my time from.
So I guess the moral of the story is… leave ‘Preset’ on its default value for now, until it stops misbehaving? Choose it based primarily on your encode time constraints, or file size concerns – whichever is highest priority? Frustrating.
Note: I used the Handbrake Nightly build as of mid-November 2017 (version 20171113130119-17a4bb7-master), as the latest released version (1.0.7) produces H.265 files that macOS High Sierra refuses to play. Apparently it’s using a different codec tag – ‘hev1’ instead of ‘hvc1’ – from what Apple’s expecting (see for example this thread). I have no idea which is correct, or maybe both are in some contexts… either way it’s a concern for ongoing H.265 device compatibility.
