| 16 | | The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn't technically lossless. |
| 17 | | |
| 18 | | The range is exponential, so increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value. |
| 19 | | |
| 20 | | {{{ |
| 21 | | #!div style="border: 1pt dotted; margin: 1em; background-color: #fffff9;" |
| 22 | | '''Note:''' The CRF quantizer scale mentioned on this page only applies to 8-bit x264 (10-bit x264 quantizer scale is 0-63). You can see what you are using by referring to the `ffmpeg` console output during encoding (`yuv420p` or similar for 8-bit, and `yuv420p10le` or similar for 10-bit). 8-bit is more common among distributors. |
| 23 | | }}} |
| 24 | | |
| 25 | | |
| 26 | | === 2. Choose a preset === |
| | 18 | The range of the CRF scale is 0–51, where 0 is lossless, 23 is the default for x264, and 51 is worst quality possible. A lower value generally leads to higher quality, and a subjectively sane range is 18–28. Consider 18 to be visually lossless or nearly so; it should look the same or nearly the same as the input but it isn't technically lossless. |
| | 19 | |
| | 20 | The range is exponential, so increasing the CRF value +6 results in roughly half the bitrate / file size, while -6 leads to roughly twice the bitrate. |
| | 21 | |
| | 22 | Choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value. If it looks bad, choose a lower value. |
| | 23 | |
| | 24 | {{{ |
| | 25 | #!div style="border: 1px solid #e5e5c7; margin: 1em; background-color: #ffd;" |
| | 26 | '''Note:''' The 0–51 CRF quantizer scale mentioned on this page only applies to 8-Bit x264. When compiled with 10-Bit support, x264's quantizer scale is 0–63. You can see what you are using by referring to the `ffmpeg` console output during encoding (`yuv420p` or similar for 8-Bit, and `yuv420p10le` or similar for 10-Bit). 8-Bit is more common among distributors. |
| | 27 | }}} |
| | 28 | |
| | 29 | |
| | 30 | === 2. Choose a preset and tune === |
| 30 | | The general guideline is to use the slowest preset that you have patience for. Current presets in descending order of speed are: `ultrafast`,`superfast`, `veryfast`, `faster`, `fast`, `medium`, `slow`, `slower`, `veryslow`, `placebo`. The default preset is `medium`. Ignore `placebo` as it is not useful (see [#FAQ FAQ]). You can see a list of current presets with `-preset help` (see example below), and what settings they apply with `x264 --fullhelp`. |
| 31 | | |
| 32 | | You can optionally use `-tune` to change settings based upon the specifics of your input. Current tunings include: `film`, `animation`, `grain`, `stillimage`, `psnr`, `ssim`, `fastdecode`, `zerolatency`. For example, if your input is animation then use the `animation` tuning, or if you want to preserve grain then use the `grain` tuning. If you are unsure of what to use or your input does not match any of tunings then omit the `-tune` option. You can see a list of current tunings with `-tune help`, and what settings they apply with `x264 --fullhelp`. |
| | 34 | Use the slowest preset that you have patience for. The available presets in descending order of speed are: |
| | 35 | |
| | 36 | * `ultrafast` |
| | 37 | * `superfast` |
| | 38 | * `veryfast` |
| | 39 | * `faster` |
| | 40 | * `fast` |
| | 41 | * `medium` – default preset |
| | 42 | * `slow` |
| | 43 | * `slower` |
| | 44 | * `veryslow` |
| | 45 | * `placebo` – ignore this as it is not useful (see [#FAQ FAQ]) |
| | 46 | |
| | 47 | You can see a list of current presets with `-preset help` (see example below). If you have the `x264` binary installed, you can also see the exact settings these presets apply by running `x264 --fullhelp`. |
| | 48 | |
| | 49 | You can optionally use `-tune` to change settings based upon the specifics of your input. Current tunings include: |
| | 50 | |
| | 51 | * `film` – use for high quality movie content; lowers deblocking |
| | 52 | * `animation` – good for cartoons; uses higher deblocking and more reference frames |
| | 53 | * `grain` – preserves the grain structure in old, grainy film material |
| | 54 | * `stillimage` – good for slideshow-like content |
| | 55 | * `fastdecode` – allows faster decoding by disabling certain filters |
| | 56 | * `zerolatency` – good for fast encoding and low-latency streaming |
| | 57 | * `psnr` – ignore this as it is only used for codec development |
| | 58 | * `ssim` – ignore this as it is only used for codec development |
| | 59 | |
| | 60 | For example, if your input is animation then use the `animation` tuning, or if you want to preserve grain in a film then use the `grain` tuning. If you are unsure of what to use or your input does not match any of tunings then omit the `-tune` option. You can see a list of current tunings with `-tune help`, and what settings they apply with `x264 --fullhelp`. |
| 74 | | {{{ |
| 75 | | ffmpeg -y -i input -c:v libx264 -preset medium -b:v 2600k -pass 1 -c:a aac -b:a 128k -f mp4 /dev/null && \ |
| 76 | | ffmpeg -i input -c:v libx264 -preset medium -b:v 2600k -pass 2 -c:a aac -b:a 128k output.mp4 |
| 77 | | }}} |
| 78 | | |
| 79 | | {{{ |
| 80 | | #!div style="border: 1pt dotted; margin: 1em; background-color: #fffff9;" |
| 81 | | '''Note:''' Windows users should use `NUL` instead of `/dev/null`. |
| 82 | | }}} |
| 83 | | |
| 84 | | As with CRF, choose the slowest preset you can tolerate. |
| 85 | | |
| 86 | | In pass 1 specify a output format with `-f` that matches the output format in pass 2. Also in pass 1, specify the audio codec used in pass 2; in many cases `-an` in pass 1 will not work. |
| 87 | | |
| 88 | | {{{#!comment |
| 89 | | In which cases is the above true? |
| 90 | | }}} |
| 91 | | |
| 92 | | See [http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html Making a high quality MPEG-4 ("DivX") rip of a DVD movie]. It is an MEncoder guide, but it will give you an insight about how important it is to use two-pass when you want to efficiently use every bit when you're constrained with storage space. |
| | 102 | For two-pass, you need to run `ffmpeg` twice, with almost the same settings, except for: |
| | 103 | |
| | 104 | * In pass 1 and 2, use the `-pass 1` and `-pass 2` options, respectively. |
| | 105 | * In pass 1, output to a null file descriptor, not an actual file. (This will generate a logfile that ffmpeg needs for the second pass.) |
| | 106 | * In pass 1, you need to specify an output format (with `-f`) that matches the output format you will use in pass 2. |
| | 107 | * In pass 1, specify the audio codec used in pass 2; in many cases, `-an` in pass 1 will not work. |
| | 108 | |
| | 109 | For example: |
| | 110 | |
| | 111 | {{{ |
| | 112 | ffmpeg -y -i input -c:v libx264 -b:v 2600k -pass 1 -c:a aac -b:a 128k -f mp4 /dev/null && \ |
| | 113 | ffmpeg -i input -c:v libx264 -b:v 2600k -pass 2 -c:a aac -b:a 128k output.mp4 |
| | 114 | }}} |
| | 115 | |
| | 116 | {{{ |
| | 117 | #!div style="border: 1px solid #e5e5c7; margin: 1em; background-color: #ffd;" |
| | 118 | '''Note:''' Windows users should use `NUL` instead of `/dev/null` and `^` instead of `\`. |
| | 119 | }}} |
| | 120 | |
| | 121 | As with CRF, choose the slowest `-preset` you can tolerate, and optionally apply a `-tune` setting and `-profile:v`. |
| 113 | | Note that lossless output files will likely be huge, and most non-FFmpeg based players will not be able to decode lossless, so if compatibility or file size issues you should not use lossless. If you're looking for an output that is roughly "visually lossless" but not technically lossless use a `-crf` value of around 17 or 18 (you'll have to experiment to see which value is acceptable for you). It will likely be indistinguishable from the source and not result in a huge, possibly incompatible file like true lossless mode. |
| | 141 | Note that lossless output files will likely be huge, and most non-FFmpeg based players will not be able to decode lossless. Therefore, if compatibility or file size are an issue, you should not use lossless. |
| | 142 | |
| | 143 | {{{ |
| | 144 | #!div style="border: 1px solid #c7e5c7; margin: 1em; background-color: #ddffdd;" |
| | 145 | '''Tip:''' If you're looking for an output that is roughly "visually lossless" but not technically lossless, use a `-crf` value of around 17 or 18 (you'll have to experiment to see which value is acceptable for you). It will likely be indistinguishable from the source and not result in a huge, possibly incompatible file like true lossless mode. |
| | 146 | }}} |
| 144 | | In the above example, `-bufsize` is the "rate control buffer" so it will enforce your requested "average" (1 MBit/s in this case) across each 2 MBit worth of video. So basically it is assumed that the receiver/end player will buffer that much data so it's ok to fluctuate within that much. |
| 145 | | |
| 146 | | Of course, if it's all just empty/black frames then it will still serve less than that many bits/s but it will raise the quality level as much as it can. |
| | 177 | In the above example, `-bufsize` is the "rate control buffer", so it will enforce your requested "average" (1 MBit/s in this case) across each 2 MBit worth of video. Here it is assumed that the receiver / player will buffer that much data, meaning that a fluctuation within that range is acceptable. |
| | 178 | |
| | 179 | CBR encodes are usually inefficient if the video is easy to encode (e.g., empty or black frames). |
| 234 | | It helps at most ~1% compared to the `veryslow` preset at the cost of a much higher encoding time. It's diminishing returns: `veryslow` helps about 3% compared to the `slower` preset, `slower` helps about 5% compared to the `slow` preset, and `slow` helps about 5-10% compared to the `medium` preset. |
| | 267 | It helps at most ~1% in terms of quality, compared to the `veryslow` preset at the cost of a much higher encoding time. It's diminishing returns: `veryslow` helps about 3% compared to the `slower` preset, `slower` helps about 5% compared to the `slow` preset, and `slow` helps about 5-10% compared to the `medium` preset. |
| | 268 | |
| | 269 | === How do the different presets influence encoding time? === |
| | 270 | |
| | 271 | This depends on the source material, the target bitrate, and your hardware configuration. In general, the higher the bitrate, the more time needed for encoding. |
| | 272 | |
| | 273 | Here is an example that shows the (normalized) encoding time for a two-pass encode of a 1080p video: |
| | 274 | |
| | 275 | [[Image(encoding_time.png)]] |
| | 276 | |
| | 277 | Going from `medium` to `slow`, the time needed increases by about 30%. The same goes for going from `slow` to `slower`. `veryslow` needs about 45% more time compared to `slower`. |
