Split lines better

Author: shssoichiro

encoding/codecs/x264.md

@@ -3,7 +3,7 @@
 H.264 has been the de facto standard video format
 across the internet for the past decade.
 It is widely supported for playback in all modern browsers
-and many hardware devices such as gaming consoles.
+and many hardware devices such as gaming consoles and phones.
 It provides better video quality at smaller file sizes
 compared to its predecessors.
 
@@ -17,8 +17,8 @@ To get started, you'll need two things:
 
 - A video to encode--for the examples,
   we will pipe in a video from VapourSynth,
-  which you should be able to do if you've been following
-  the previous sections of this guide
+  which you should be able to do
+  if you've been following the previous sections of this guide
 - The x264 encoder
 
 Here's how we get a copy of the x264 encoder:
@@ -39,15 +39,19 @@ Here are a few examples:
 
 ## Getting Started
 
-x264 is very configurable, and the options may seem overwhelming.
-But you can get started encoding by using the presets x264 provides
+x264 is very configurable,
+and the options may seem overwhelming.
+But you can get started encoding
+by using the presets x264 provides
 and understanding a few basic concepts.
-We'll walk through those concepts with the following examples.
+We'll walk through those concepts
+with the following examples.
 
 ## Example 1
 
 Open up a terminal window,
-and navigate to the folder where your VapourSynth script lives.
+and navigate to the folder
+where your VapourSynth script lives.
 Let's run the following command:
 
 `vspipe --y4m myvideo.vpy - | x264 --demuxer y4m --preset veryfast --tune animation --crf 24 -o x264output.mkv -`
@@ -56,22 +60,27 @@ Let's run through what each of these options means:
 
 #### `vspipe --y4m myvideo.vpy -`
 
-This portion loads your VapourSynth script and pipes it to stdout,
+This portion loads your VapourSynth script
+and pipes it to stdout,
 adding y4m headers that x264 can decode.
-If you use Linux, you're probably familiar with how piping works.
-If you're not, it's basically a way of chaining two commands together.
+If you use Linux,
+you're probably familiar with how piping works.
+If you're not,
+it's basically a way of chaining two commands together.
 In this case, we want to chain `vspipe`,
 the program that reads VapourSynth scripts,
 with x264, our encoder.
 
 #### `--demuxer y4m`
 
 This tells x264 that we're providing it with a y4m file.
-This matches up with the `--y4m` flag that we gave to the `vspipe` command.
+This matches up with the `--y4m` flag
+that we gave to the `vspipe` command.
 
 #### `--preset veryfast`
 
-x264 has a set of presets to switch between faster encoding, or higher quality.
+x264 has a set of presets
+to switch between faster encoding, or higher quality.
 The full list of presets, from fastest to slowest, is:
 
 - ultrafast
@@ -89,13 +98,17 @@ You will almost never want to use the very extreme settings,
 but generally, if you want good quality
 and don't care about how long the encode takes,
 `slower` or `veryslow` are recommended.
-In this example, because we are just demonstrating how x264 works,
+In this example,
+because we are just demonstrating how x264 works,
 we want a fast encode and have chosen `veryfast`.
 
-For the curious, you can see a full list of the settings
-enabled by each preset by running `x264 --fullhelp | less`.
+For the curious,
+you can see a full list of the settings enabled by each preset
+by running `x264 --fullhelp | less`.
 However, this probably won't mean much at the moment.
-Don't worry, this guide will explain later what all of those settings mean.
+Don't worry,
+this guide will explain later
+what all of those settings mean.
 
 #### `--tune animation`
 
@@ -111,7 +124,8 @@ The following tunings are generally the most useful:
 - `grain`: Recommended for particularly grainy films.
 
 You don't need to use a tuning,
-but it generally helps to produce a better-looking video.
+but it generally helps
+to produce a better-looking video.
 
 #### `--crf 24`
 
@@ -120,25 +134,30 @@ In layman's terms,
 this means that we don't need the output to meet a specific filesize,
 we just want the output to meet a certain quality level.
 CRF ranges from 0 to 51,
-with 0 being the best quality and 51 being the smallest filesize,
+with 0 being the best quality
+and 51 being the smallest filesize,
 but there is a certain range of CRF settings
 that are generally most useful.
 Here are some guidelines:
 
 - CRF 13: This is considered visually lossless to videophiles.
   This can produce rather large files,
   but is a good choice if you want high quality videos.
-  Fansubbing groups often use this for Blu-ray encodes.
+  Some fansubbing groups use this for Blu-ray encodes.
 - CRF 16-18: This is considered visually lossless to most viewers,
-  and leans toward high quality while still providing a reasonable filesize.
+  and leans toward high quality
+  while still providing a reasonable filesize.
   This is a typical range for fansub encodes.
 - CRF 21-24: This provides a good balance between quality and filesize.
-  Some quality loss becomes visible, but this is generally a good choice
-  where filesize becomes a concern, such as for videos viewed over the internet.
-- CRF 26-30: This prioritizes filesize, and quality loss becomes more obvious.
-  It is generally not recommended to go higher than CRF 30 in any real-world
-  encoding scenario, unless you want your videos to look like they were made
-  for dial-up.
+  Some quality loss becomes visible,
+  but this is generally a good choice
+  where filesize becomes a concern,
+  such as for videos viewed over the internet.
+- CRF 26-30: This prioritizes filesize,
+  and quality loss becomes more obvious.
+  It is generally not recommended to go higher than CRF 30
+  in any real-world encoding scenario,
+  unless you want your videos to look like they were made for dial-up.
 
 #### `-o x264output.mkv -`
 
@@ -153,15 +172,21 @@ which tells x264 to use the piped output from vspipe.
 
 ## Example 2
 
-For the next example, let's say we want to make sure our encode
-fits onto a single 4.7GB DVD. How would we do that in x264?
+For the next example,
+let's say we want to make sure our encode
+fits onto a single 4.7GB DVD.
+How would we do that in x264?
 
-First, we'll need to figure out what bitrate our encode should be,
-in **kilobits per second**. This means we'll need to know a couple of things:
+First, we'll need to figure out
+what bitrate our encode should be,
+in **kilobits per second**.
+This means we'll need to know a couple of things:
 
 - The length of our video, in seconds.
-  For this example, let's say our movie is 2 hours (120 minutes) long.
-  We'll convert that to seconds: 120 \* 60 = **7200 seconds**.
+  For this example,
+  let's say our movie is 2 hours (120 minutes) long.
+  We'll convert that to seconds:
+  120 \* 60 = **7200 seconds**.
 - Our target filesize.
   We know that this is 4.7GB,
   but we need to convert it to kilobits.
@@ -183,24 +208,30 @@ The `--bitrate` option, by itself,
 says that we want to do a 1-pass, average-bitrate encode.
 In other words, the encoder will still give more bits
 to sections of the video that have more detail or motion,
-but the average bitrate of the video will be close to what we requested.
+but the average bitrate of the video
+will be close to what we requested.
 
 ## Example 3
 
 So far, we've only done 1-pass encodes.
-While using CRF 1-pass is great when you don't have a target bitrate,
-it's recommended not to use 1-pass for targeted-bitrate encodes,
+While using CRF 1-pass is great
+when you don't have a target bitrate,
+it's recommended not to use 1-pass
+for targeted-bitrate encodes,
 because the encoder can't know
 what's coming ahead of the current section of video.
 This means it can't make good decisions
 about what parts of the video need the most bitrate.
 
-How do we fix this? x264 supports what is known as 2-pass encoding.
+How do we fix this?
+x264 supports what is known as 2-pass encoding.
 In 2-pass mode, x264 runs through the video twice,
-the first time analyzing it to determine where to place keyframes
+the first time analyzing it
+to determine where to place keyframes
 and which sections of video need the most bitrate,
 and the second time performing the actual encode.
-2-pass mode is highly recommended if you need to target a certain bitrate.
+2-pass mode is highly recommended
+if you need to target a certain bitrate.
 
 Here's how we would run our first pass:
 
@@ -214,8 +245,10 @@ which x264 will use in the second pass:
 You'll notice all we had to change was `--pass 1` to `--pass 2`. Simple!
 
 Although x264 will automatically use faster settings for the first pass,
-it should be no surprise that 2-pass encoding is slower than 1-pass encoding.
-Therefore, there are still certain use cases where 1-pass, bitrate-targeted video
+it should be no surprise
+that 2-pass encoding is slower than 1-pass encoding.
+Therefore, there are still certain use cases
+where 1-pass, bitrate-targeted video
 is a good fit, such as streaming.
 
 ## Recap