+---------------------------------------------+ | HTML_ | HTML5_ | EPUB_ | PDF_ | TXT_ | RST_ | +---------------------------------------------+ """""""""""""""""""""""""""""""""""""""""" A Guide to x264, Detail Loss & Desperation """""""""""""""""""""""""""""""""""""""""" (WORK IN PROGRESS) """""""""""""""""" +---------------------------------------------+ | HTML_ | HTML5_ | EPUB_ | PDF_ | TXT_ | RST_ | +---------------------------------------------+ Mosc February 2, 2016 +---------------------------------------------+ | HTML_ | HTML5_ | EPUB_ | PDF_ | TXT_ | RST_ | +---------------------------------------------+ x264 has a ton of configurable settings, which can be quite intimidating if you're just starting out. Luckily, you won't need to change the vast majority of them. Nonetheless, the settings that do matter usually don't have sufficient official documentation. Many guides have tried to demystify the settings, but often end up being outdated, wrong, and/or overly complex. Useful information is scattered over a large number of websites. Here's my (futile) attempt fix this situation, although there's no guarantee it won't suffer from one or more of the same fates. +---------------------------------------------+ | HTML_ | HTML5_ | EPUB_ | PDF_ | TXT_ | RST_ | +---------------------------------------------+ .. contents:: Contents :depth: 2 ======================= Encoding speed settings ======================= Settings in this section are pretty much only dependent on how long you're willing to wait for your encode to finish. Using heavier settings can increase the quality or lower the encode's size at the same quality, but may raise the amount of time the encode takes to an unreasonable amount. Some settings may influence decoding speed as well, but not significantly so. -------- --preset -------- *preset* is a highly under-appreciated setting that helps you reduce the length of your command significantly by setting many speed vs. quality settings at once. *b-adapt*, *direct*, *me*, *subme*, *trellis*? You don't really need to know about any of these (as well as others) because they are handled by *presets*. The ``veryslow`` *preset* is a solid base preset to use for those who care about quality. People with insane machines can go for the ``placebo`` *preset* for that under one percent extra improvement [1]_. The ``slower`` *preset* is pretty decent if ``veryslow`` is not fast enough, and will still pass most trackers' 'gold' requirements (but be sure to check first). If you've read other x264 guides before, you've likely been taught to use a formula to calculate an optimal ref value (related to something called the DPB capacity [2]_). That's not needed when using preset, because it will automatically determine the correct number of reference frames if the level setting is also specified. Much easier. :Default: ``medium`` :Start with: ``veryslow`` :Consider: ``slower``, ``veryslow``, ``placebo`` +------------+---------------------------+ | Default | medium | +------------+---------------------------+ | Start with | veryslow | +------------+---------------------------+ | Consider | slower, veryslow, placebo | +------------+---------------------------+ +------------+---------------------------------------+ | Default | ``medium`` | +------------+---------------------------------------+ | Start with | ``veryslow`` | +------------+---------------------------------------+ | Consider | ``slower``, ``veryslow``, ``placebo`` | +------------+---------------------------------------+ +----------------+---------------------------------------+ | **Default** | ``medium`` | +----------------+---------------------------------------+ | **Start with** | ``veryslow`` | +----------------+---------------------------------------+ | **Consider** | ``slower``, ``veryslow``, ``placebo`` | +----------------+---------------------------------------+ .... .. [1] http://forum.doom9.org/showpost.php?p=1611911 .. [2] https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Decoded_picture_buffering --------- --merange --------- *merange* controls the search distance in pixels to find motion vectors, starting at a predicted motion vector. Slower *presets* will raise the default value of ``16`` to ``24``, but many feel that this is not high enough. The reason for this is that for high video resolutions, objects will typically move more pixels from frame to frame when compared to low resolutions. Using the same logic, we can derive that high-motion movies will benefit more from higher values. This larger search range does come at a significant cost in encoding speed, which is why you don't want to bump this up to something crazy like ``1024`` (which happens to be the limit enforced by x264). An x264 author explains why high values may even hurt quality slightly in some cases [3]_. Extremely high *merange* (e.g. ``>64``) is unlikely to find any new motion vectors that are useful, so it may very slightly decrease compression in some cases by picking motion vector deltas so large that they worsen prediction of future motion vectors in the rare cases they're locally useful, making them worse than useless. The effect is so small as to be near-negligible, though, and you shouldn't be using such insane settings. -- *Dark Shikari, 2011-12-11 (Doom9)* In general, higher values do result in better quality, but with significant diminishing returns. Although it's possible to tweak this value to your video, you'll likely just end up setting this value based on how much extra time you want to allow x264 to spend on the encode. Which is fine. :Default: ``16`` (``24`` for *presets* ``veryslow`` and ``placebo``) :Start with: ``~32`` :Consider: ``24``, ``32``, ``48``, or ``64`` if you are insane +-------------+------------------------------------------+ | Default | 16 (24 for presets veryslow and placebo) | +-------------+------------------------------------------+ | Start with | ~32 | +-------------+------------------------------------------+ | Consider | 24, 32, 48, or 64 if you are insane | +-------------+------------------------------------------+ .. [3] http://forum.doom9.org/showpost.php?p=1544428 ====================== Compatibility settings ====================== The compatibility settings in this section largely decide how compatible your encode will be with decoding software and hardware. Usage of more decoding resources tends to allow for more efficient encoding, and that’s a trade-off that is worth thinking about. ------- --level ------- level refers to the H.264 level specification. Higher levels allow for higher bitrates and more reference frames, but their hardware support is generally not as good. A level of 4.1 is pretty much perfect for high definition encodes: it’s high enough to not significantly impact quality at the resolutions we use, while having very extensive hardware support. It’s the highest level supported for Blu-ray discs as well. A level of 4.0 is fine for standard definition video. It’s generally the lowest level that still allows you to still use all the x264 features you might want. If hardware support is not something you’re worried about, not explicitly setting level has the potential for a small quality boost, as x264 will automatically select an appropriate level based on the resolution and configured reference frames. Be warned that many trackers will not accept encodes with levels past 4.1, which could happen if you don’t limit it yourself. And, as mentioned for the preset setting, if you combine the preset and level settings, the amount of reference frames will be automatically limited to the maximum allowed value. How convenient! Default not set Start with 4.1 for high definition, 4.0 for standard definition Consider 4.1, 4.0, not set ----------------------------- --vbv-maxrate / --vbv-bufsize ----------------------------- VBV stands for video buffer verifier. The actual workings of VBV may not be completely intuitive, but the key point to remember is that there are no optimal values. It completely depends on the specifications of the playback hardware you want your video to be compatible with. An obvious candidate is ``62500 / 78125``. It’s the limit defined by *level* 4.1. Value pairs for other levels can be derived as well [4]_. So why doesn't the level setting in x264 apply this limit automatically, like it does for reference frames? Only because some people didn’t want their bitrates to be limited to these values that are unlikely to be the exact limitations of playback devices [5]_. It’s a bit of a silly argument, but that’s how it is. Another possible combination of values is ``40000 / 30000``. These values are based on the official Blu-ray specification [6]_. The result of this is that compatibility with Blu-ray players should be pretty much guaranteed. ``38000`` ``/ 30000`` is a frequently used alternative, but as far as I can tell, there is no good reason to use that specific combination. Default not set Start with 62500 / 78125 or whatever the limits of your level are Consider 62500 / 78125 or whatever the limits of your level are, 40000 / 30000, 38000 / 30000 if you want to look cool on Awesome-HD, *not set* .... .. [4] Consult Table A-1 in https://www.itu.int/rec/T-REC-H.264-201402-I. MaxBR corresponds to *vbv-maxrate*, and MaxCPB to *vbv-bufsize*. These values then need to be increased by 25% because we are using the ``high`` profile, as per cpbBrVcl Factor in Table A-2. Yes, it's quite strange that *level* limits depend on the *profile*, but whatever. .. [5] http://forum.doom9.org/showpost.php?p=1586636 .. [6] http://forum.doom9.org/showpost.php?p=1399419 ========================= Source-dependent settings ========================= ========= Changelog ========= 2023-01-28: - Started manual converstion of PDF to RST - Hosted to Neocities .. links .. _HTML: https://x264.neocities.org/x264-guide.html .. _HTML5: https://x264.neocities.org/x264-guide.5.html .. _EPUB: https://x264.neocities.org/x264-guide.epub .. _PDF: https://x264.neocities.org/x264-guide.pdf .. _TXT: https://x264.neocities.org/x264-guide.txt .. _RST: https://x264.neocities.org/x264-guide.rst.txt .... Original URL: https://www.dropbox.com/s/hrxjr5xv4q27ipe/x264-guide.pdf