|
| 1 | +# Encoding with x264 |
| 2 | + |
| 3 | +H.264 has been the de facto standard video format |
| 4 | +across the internet for the past decade. |
| 5 | +It is widely supported for playback in all modern browsers |
| 6 | +and many hardware devices such as gaming consoles and phones. |
| 7 | +It provides better video quality at smaller file sizes |
| 8 | +compared to its predecessors. |
| 9 | + |
| 10 | +x264 is a mature, free, open-source encoder |
| 11 | +for the H.264 video format. |
| 12 | + |
| 13 | + |
| 14 | +## Prerequisites |
| 15 | + |
| 16 | +To get started, you'll need two things: |
| 17 | + |
| 18 | +- A video to encode—for the examples, |
| 19 | + we will pipe in a video from VapourSynth, |
| 20 | + which you should be able to do |
| 21 | + if you've been following the previous sections of this guide |
| 22 | +- The x264 encoder |
| 23 | + |
| 24 | +Here's how we get a copy of the x264 encoder: |
| 25 | + |
| 26 | + |
| 27 | +### Windows |
| 28 | + |
| 29 | +Official Windows builds are available |
| 30 | +[here](https://download.videolan.org/pub/x264/binaries/win64/). |
| 31 | + |
| 32 | + |
| 33 | +### Linux/macOS |
| 34 | + |
| 35 | +Generally, x264 will be available |
| 36 | +through your distribution's package manager. |
| 37 | +Here are a few examples: |
| 38 | + |
| 39 | +- **Ubuntu/Debian**: `sudo apt install x264` |
| 40 | +- **Arch Linux**: `sudo pacman -S x264` |
| 41 | +- **macOS**: `brew install x264` |
| 42 | + |
| 43 | + |
| 44 | +## Getting Started |
| 45 | + |
| 46 | +x264 is very configurable, |
| 47 | +and the options may seem overwhelming. |
| 48 | +But you can get started encoding |
| 49 | +by using the presets x264 provides |
| 50 | +and understanding a few basic concepts. |
| 51 | +We'll walk through those concepts |
| 52 | +with the following examples. |
| 53 | + |
| 54 | + |
| 55 | +### Example 1: General-Purpose Encoding |
| 56 | + |
| 57 | +Open up a terminal window, |
| 58 | +and navigate to the folder |
| 59 | +where your VapourSynth script lives. |
| 60 | +Let's run the following command: |
| 61 | + |
| 62 | +``` |
| 63 | +vspipe --y4m myvideo.vpy - | x264 --demuxer y4m --preset veryfast --tune animation --crf 24 -o x264output.mkv - |
| 64 | +``` |
| 65 | + |
| 66 | +Let's run through what each of these options means: |
| 67 | + |
| 68 | + |
| 69 | +##### `vspipe --y4m myvideo.vpy -` |
| 70 | + |
| 71 | +This portion loads your VapourSynth script |
| 72 | +and pipes it to stdout, |
| 73 | +adding y4m headers that x264 can decode. |
| 74 | +If you use Linux, |
| 75 | +you're probably familiar with how piping works. |
| 76 | +If you're not, |
| 77 | +it's basically a way of chaining two commands together. |
| 78 | +In this case, we want to chain `vspipe`, |
| 79 | +the program that reads VapourSynth scripts, |
| 80 | +with `x264`, our encoder. |
| 81 | + |
| 82 | + |
| 83 | +##### `--demuxer y4m` |
| 84 | + |
| 85 | +This tells x264 that we're providing it with a y4m file. |
| 86 | +This matches up with the `--y4m` flag |
| 87 | +that we gave to the `vspipe` command. |
| 88 | + |
| 89 | + |
| 90 | +##### `--preset veryfast` |
| 91 | + |
| 92 | +x264 has a set of presets |
| 93 | +to switch between faster encoding, or higher quality. |
| 94 | +The full list of presets, from fastest to slowest, is: |
| 95 | + |
| 96 | +1. ultrafast |
| 97 | +1. superfast |
| 98 | +1. veryfast |
| 99 | +1. faster |
| 100 | +1. fast |
| 101 | +1. medium |
| 102 | +1. slow |
| 103 | +1. slower |
| 104 | +1. veryslow |
| 105 | +1. placebo |
| 106 | + |
| 107 | +You will almost never want to use the extreme settings, |
| 108 | +but generally, if you want good quality |
| 109 | +and don't care about how long the encode takes, |
| 110 | +`slower` or `veryslow` are recommended. |
| 111 | +In this example, |
| 112 | +because we are just demonstrating how x264 works, |
| 113 | +we want a fast encode and have chosen `veryfast`. |
| 114 | + |
| 115 | +For the curious, |
| 116 | +you can see a full list of the settings enabled by each preset |
| 117 | +by running `x264 --fullhelp | less` (Linux/Mac) |
| 118 | +or `x264 --fullhelp | more` (Windows). |
| 119 | +However, this probably won't mean much at the moment. |
| 120 | +Don't worry, |
| 121 | +this page will explain later |
| 122 | +what all of those settings mean. |
| 123 | + |
| 124 | +*Disclaimer: |
| 125 | +x264's `fullhelp` is not guaranteed to be up-to-date.* |
| 126 | + |
| 127 | + |
| 128 | +##### `--tune animation` |
| 129 | + |
| 130 | +Beyond the preset chosen, |
| 131 | +x264 allows us to further tune the encoding settings |
| 132 | +for the type of content we're working with. |
| 133 | +The following tunings are generally the most useful: |
| 134 | + |
| 135 | +- `film`: Recommended for live action videos. |
| 136 | +- `animation`: Recommended for anime or cartoons with flat textures. |
| 137 | + For 3D animation (e.g. Pixar movies), |
| 138 | + you may find better results with `film`. |
| 139 | +- `grain`: Recommended for particularly grainy films. |
| 140 | + |
| 141 | +You don't need to use a tuning, |
| 142 | +but it generally helps |
| 143 | +to produce a better-looking video. |
| 144 | + |
| 145 | + |
| 146 | +##### `--crf 24` |
| 147 | + |
| 148 | +CRF is a constant-quality, 1-pass encoding mode. |
| 149 | +In layman's terms, |
| 150 | +this means that we don't need the output to meet a specific filesize, |
| 151 | +we just want the output to meet a certain quality level. |
| 152 | +CRF ranges from 0 to 51 (for 8-bit encoding), |
| 153 | +with 0 being the best quality |
| 154 | +and 51 being the smallest filesize, |
| 155 | +but there is a certain range of CRF settings |
| 156 | +that are generally most useful. |
| 157 | +Here are some guidelines: |
| 158 | + |
| 159 | +- CRF 13: This is considered visually lossless to videophiles. |
| 160 | + This can produce rather large files, |
| 161 | + but is a good choice if you want high quality videos. |
| 162 | + Some fansubbing groups use this for Blu-ray encodes. |
| 163 | +- CRF 16-18: This is considered visually lossless to most viewers, |
| 164 | + and leans toward high quality |
| 165 | + while still providing a reasonable filesize. |
| 166 | + This is a typical range for fansub encodes. |
| 167 | +- CRF 21-24: This provides a good balance between quality and filesize. |
| 168 | + Some quality loss becomes visible, |
| 169 | + but this is generally a good choice |
| 170 | + where filesize becomes a concern, |
| 171 | + such as for videos viewed over the internet. |
| 172 | +- CRF 26-30: This prioritizes filesize, |
| 173 | + and quality loss becomes more obvious. |
| 174 | + It is generally not recommended to go higher than CRF 30 |
| 175 | + in any real-world encoding scenario, |
| 176 | + unless you want your videos to look like they were made for dial-up. |
| 177 | + |
| 178 | + |
| 179 | +##### `-o x264output.mkv -` |
| 180 | + |
| 181 | +This last portion tells which files to use for the input and output. |
| 182 | +We use `-o` to tell which filename to write the encoded file to. |
| 183 | +In this case, x264 will write a file at `x264output.mkv` |
| 184 | +in the current directory. |
| 185 | + |
| 186 | +The last argument we are passing to x264 is the input file. |
| 187 | +In this case, we pass `-` for the input file, |
| 188 | +which tells x264 to use the piped output from vspipe. |
| 189 | +The input argument is the only positional argument, |
| 190 | +so it does not need to be last; |
| 191 | +x264 will recognize it |
| 192 | +as the only argument without a `--` flag before it. |
| 193 | + |
| 194 | + |
| 195 | +### Example 2: Targeted File Size |
| 196 | + |
| 197 | +For the next example, |
| 198 | +let's say we want to make sure our encode |
| 199 | +fits onto a single 4.7GB DVD. |
| 200 | +How would we do that in x264? |
| 201 | + |
| 202 | +First, we'll need to figure out |
| 203 | +what bitrate our encode should be, |
| 204 | +in **kilobits per second**. |
| 205 | +This means we'll need to know a couple of things: |
| 206 | + |
| 207 | +- The length of our video, in seconds. |
| 208 | + For this example, |
| 209 | + let's say our movie is 2 hours (120 minutes) long. |
| 210 | + We'll convert that to seconds: |
| 211 | + 120 minutes \* 60 minutes/second = **7200 seconds**. |
| 212 | +- Our target filesize. |
| 213 | + We know that this is 4.7GB, |
| 214 | + but we need to convert it to kilobits. |
| 215 | + We can do this with the following steps: |
| 216 | + |
| 217 | +``` |
| 218 | +4.7GiB * 1024MiB/GiB = 4812.8MiB |
| 219 | +4812.8MiB * 1024KiB/MiB = 4928307.2KiB |
| 220 | +4928307.2KiB * 8Kbits/KiB = 39426457.6Kbits |
| 221 | +``` |
| 222 | + |
| 223 | +Now we divide the kilobit size we calculated by our video length, |
| 224 | +to find our kilobit per second target bitrate: |
| 225 | + |
| 226 | +``` |
| 227 | +39426457.6Kbits / 7200 seconds = 5475 Kbps |
| 228 | +``` |
| 229 | + |
| 230 | +And here's how we could add that to our x264 command: |
| 231 | + |
| 232 | +``` |
| 233 | +vspipe --y4m myvideo.vpy - | x264 --demuxer y4m --preset veryfast --bitrate 5475 -o x264output.mkv - |
| 234 | +``` |
| 235 | + |
| 236 | +The `--bitrate` option, by itself, |
| 237 | +says that we want to do a 1-pass, average-bitrate encode. |
| 238 | +In other words, the encoder will still give more bits |
| 239 | +to sections of the video that have more detail or motion, |
| 240 | +but the average bitrate of the video |
| 241 | +will be close to what we requested. |
| 242 | + |
| 243 | + |
| 244 | +### Example 3: 2-Pass Encoding |
| 245 | + |
| 246 | +So far, we've only done 1-pass encodes. |
| 247 | +While using CRF 1-pass is great |
| 248 | +when you don't have a target bitrate, |
| 249 | +it's recommended not to use 1-pass |
| 250 | +for targeted-bitrate encodes, |
| 251 | +because the encoder can't know |
| 252 | +what's coming ahead of the current section of video. |
| 253 | +This means it can't make good decisions |
| 254 | +about what parts of the video need the most bitrate. |
| 255 | + |
| 256 | +How do we fix this? |
| 257 | +x264 supports what is known as 2-pass encoding. |
| 258 | +In 2-pass mode, x264 runs through the video twice, |
| 259 | +the first time analyzing it |
| 260 | +to determine where to place keyframes |
| 261 | +and which sections of video need the most bitrate, |
| 262 | +and the second time performing the actual encode. |
| 263 | +2-pass mode is highly recommended |
| 264 | +if you need to target a certain bitrate. |
| 265 | + |
| 266 | +Here's how we would run our first pass: |
| 267 | + |
| 268 | +``` |
| 269 | +vspipe --y4m myvideo.vpy - | x264 --demuxer y4m --preset veryfast --pass 1 --bitrate 5475 -o x264output.mkv - |
| 270 | +``` |
| 271 | + |
| 272 | +This creates a stats file in our current directory, |
| 273 | +which x264 will use in the second pass: |
| 274 | + |
| 275 | +``` |
| 276 | +vspipe --y4m myvideo.vpy - | x264 --demuxer y4m --preset veryfast --pass 2 --bitrate 5475 -o x264output.mkv - |
| 277 | +``` |
| 278 | + |
| 279 | +You'll notice all we had to change was `--pass 1` to `--pass 2`. Simple! |
| 280 | + |
| 281 | +Although x264 will automatically use faster settings for the first pass, |
| 282 | +it should be no surprise |
| 283 | +that 2-pass encoding is slower than 1-pass encoding. |
| 284 | +Therefore, there are still certain use cases |
| 285 | +where 1-pass, bitrate-targeted video |
| 286 | +is a good fit, such as streaming. |
| 287 | + |
| 288 | + |
| 289 | +## Recap |
| 290 | + |
| 291 | +We covered the basics of how to encode in x264, |
| 292 | +including speed presets, tunings, and three different encoding modes. |
| 293 | + |
| 294 | +Here is a summary of when to use each encoding mode: |
| 295 | + |
| 296 | +- 1-pass Constant Quality (CRF): |
| 297 | + - Good for: General-purpose encoding |
| 298 | + - Bad for: Streaming; obtaining a certain file size |
| 299 | +- 1-pass Average Bitrate: |
| 300 | + - Good for: Streaming |
| 301 | + - Bad for: Everything else |
| 302 | +- 2-pass Average Bitrate: |
| 303 | + - Good for: Obtaining a certain file size |
| 304 | + - Bad for: Streaming |
| 305 | + |
| 306 | + |
| 307 | +## Advanced Configuration |
| 308 | + |
| 309 | +Coming Soon |
0 commit comments