The Comprehensive HandBrake Guide

Created in 2003, HandBrake was originally the brainchild of a single developer: titler. However, after his prolonged absence from the project beginning in May of 2006, Rodney Hester and Chris Long began developing a release of HandBrake supporting the H.264 video codec. Although they made significant advances in stability, interface design, and functionality, they were unable to submit their modified version of HandBrake without the consent of the original creator. Unable to officially commit their revisions as a new version, the two developers created a new project named MediaFork based on the latest release of HandBrake, 0.7.1 at the time. Then, on February 13, 2007, titler resurfaced and contacted Hester and Long. titler expressed his support for their project and encouraged them to continue development. Following the exchange, plans were made to reintegrate MediaFork into the main HandBrake build. And so, in the ensuing version, MediaFork’s code was integrated into HandBrake’s. At the time of this writing HandBrake is in version 0.9.8, released July 18th, 2012.

Don’t let the goofy, pineapple-and-margarita logo fool you: despite its whimsical emblem, HandBrake is regarded as one of the most powerful video conversion applications available. Through the excellent combination of a streamlined interface and extensive control, HandBrake has become increasingly popular amongst video enthusiasts around the world. However, HandBrake’s power comes at the price of simplicity: this is not the easiest program available for the task it accomplishes. Due to that, and the fact that there are few comprehensive guides out there, I decided to write this article in order to provide you with the knowledge to utilize HandBrake to its full potential. The result, this article, contains an explanation of every checkbox, text field, and radio button found in HandBrake.

Getting Started #

HandBrake is relatively easy to install and setup. First, go to the Downloads page and download the version of HandBrake for your operating system. Currently there are versions of HandBrake for Windows, Mac, and Ubuntu. Additionally, you can also opt for the Command Line Interface version should you so desire. Once the installer has downloaded, start it and complete the three-step installation process. HandBrake is now installed on your system.

Before you can begin learning about the interface and converting videos though, an output directory must be specified. The default output directory is the location HandBrake will automatically store output videos once a conversion has finished. HandBrake can also be configured to store copies of the respective video’s log file in this location rather than in the logs directory as is the default. To set a default output directory, open the Tools menu, scroll down to Options, and click it. The HandBrake Options window will pop up containing six tabs. These six tabs — General, Output Files, Preview, Audio and Subtitles, System and Logging, and Advanced — allow you to set some of HandBrake’s environment variables such as the destination folder, done in the “Output Files” tab by clicking the Browse button near the “Default Path” label. Once you have selected an appropriate directory, click Close to save your setting and close the Options screen. You are now ready to begin learning to use HandBrake.

HandBrake's Interface #

HandBrake’s interface is split into seven distinct sections. In order of appearance, these sections are as follows: the menu bar, positioned at the top of the window; the button bar, containing six buttons for HandBrake’s six main functions as well as the Help button; Source; Destination; Output Settings, containing the seven conversion tabs; and Presets, located at the right of the window. Throughout the rest of this article, each interface item and its child elements will be discussed in exhaustive detail.

The Menu Bar #

The menu bar houses two menus: File and Tools. The File menu simply allows you to close HandBrake, whereas Tools contains thee items: Show Queue, Activity Window, and Options. Show Queue causes HandBrake’s encode queue to either come to the front if it has already been opened, or open it if not. A detailed explanation of both this window and Activity Window, the option below Show Queue in the Tools menu, will be provided below.

The Button bar #

Below the Menu bar, the Button bar consists of HandBrake’s six main interface buttons: Source, Start, Add to Queue, Show Queue, Preview, and Activity Window.

The first button in line, Source, is used to select the source video for the conversion. HandBrake provides three different methods for choosing this file, selected from the dropdown menu revealed upon clicking the Source button. The first option, Video File, accepts a single video file as the source. The second, Folder, enables the selection of a DVD’s VIDEO_TS folder as the source, providing the capability to rip a DVD without encryption. Finally, Title Specific Scan is used to rip an encrypted DVD. When a DVD is scanned using the Folder option, HandBrake is often unable to search the entire DVD for the main title due to the precautions taken to combat piracy; however, by using Title Specific Scan and manually inputting the main title’s number, HandBrake is occasionally able to successfully locate, scan, and add the feature film as the source video.

Next to Source, the Start button instantiates the conversion of either the videos in the queue or the video currently open in HandBrake. If there are videos in the queue as well as a video open in HandBrake’s main window, the videos in the queue will be encoded while the video open in HandBrake’s main window will be ignored. Once the conversion has begun, the Start button is replaced with a button labeled “Stop”. Clicking the Stop button will immediately halt the conversion and render the video currently being converted unplayable.

Batch video encodes are often handled in a very similar manner regardless of the application. First, videos are added to the queue. Most applications permit videos to be added one at a time or in batches of up to an entire directory. Once the queue has been populated, a conversion profile can be used to load a collection of settings such as resolution, codec, and frame rate. These are the settings each video in the queue will be converted with. Finally, the conversion is started. This process works exceptionally well if each video in the queue has similar properties. For example, when each video has an aspect ratio of 4:3 and a similar resolution. However, if the queue contains videos of different types, problems begin to arise when the same conversion profile, the same conversion parameters, are applied to each video. For example, converting a queue of 4:3 videos to a smaller resolution with the 4:3 aspect ratio would be perfectly acceptable, but this would not be the case if half the queue had a ratio of 16:9, as converting from a ratio of 16:9 to 4:3 is guaranteed to produce sub-optimal results. The concept of aspect ratios will be discussed in much greater detail later on in the article, so for now bear with me.

The process for setting up a batch encode in HandBrake is very similar to that of most other conversion applications, with one key difference: each video must be added to the queue individually; there is no “batch add” feature in HandBrake. First, a video is opened in the main window. From here the conversion parameters are set either manually or through the application of a preset, which is HandBrake’s equivalent to a conversion profile. Once the conversion parameters are set, the Add to Queue button will append the current video to the bottom of the queue. Since HandBrake does not allow for multiple videos to be opened simultaneously, this process must be repeated for each video added to the queue. To make this process a bit easier though, HandBrake automatically retains conversion parameters such as resolution, codecs, and frame rate within the current session and loads those settings for each new video automatically. Requiring that videos be added one by one eliminates the problems a one-size-fits-all approach such as the one described above creates by allowing for the conversion parameters to be changed depending on the source video; and by retaining conversion parameters between each new video, HandBrake makes the process of adding new videos to the queue quick and easy for videos with similar properties. In combination, these two features make HandBrake’s queue much more powerful than most others.

To open the queue, from which the order can be manipulated, items can be removed, and videos can be re-opened in HandBrake’s main window, click the Show Queue button. Once the Encode Queue window is open, right-clicking any of the listed entries will reveal a context menu containing options to move the selected video up, down, to remove it from the queue, or to edit the video. The Edit command removes the selected video from the queue and opens it in the main window while simultaneously loading its conversion parameters. From there, it is possible to modify the video’s conversion parameters before re-adding it to the queue, done by clicking Add to Queue once again. Note, however, that if a video is appended to the queue, edited, and re-appended to the queue, it will not be in the same place it was prior to being edited. To change an entry’s position, use the Move Up or Move Down command.

Encodes can also be started or paused from the Encode Queue window. Prior to the conversion starting, the Encode button will instantiate the conversion. Once the conversion has started though, HandBrake disables the Encode button and adds a new button to the interface, labeled “Pause”. Clicking Pause during an encode prevents HandBrake from passing any more queue items to the encode, but does not pause the current conversion. To stop the current job, click Stop in the main window, which replaces the Start button once the encode has begun. The Stop button will also stop any subsequent conversion from taking place, and render the video currently being converted unplayable.

Next to the Encode button, the Queue button causes a dropdown menu to appear containing four options: Generate Batch Script, Import Queue, and Export Queue. The first option, Generate Batch Script, creates a batch script containing the necessary commands to convert each item in the queue with the conversion parameters it was added with. Once saved, this script can be executed at any time by double-clicking the .bat script on a Windows machine, or the .sh script on UNIX-based machines. Depending on the operating system, a Command Prompt or Terminal window will appear and the encode will begin, all without the need to open HandBrake’s main interface. Additionally, batch scripts also allow for multiple encodes to take place at once. Be aware, though, that despite the ability to have multiple conversions running at the same time, the encoder will not work any faster. For example, suppose that a computer maxed out at an encoding speed of around 25 to 30 frames per second. Multiple encodes running at the same time simply divides that number evenly for each instance of a conversion. In other words, running three conversions simultaneously on a computer maxing out at 30 frames per second would result in each conversion processing approximately 10 frames per second.

Next in line is Import, but it makes more sense to skip ahead to Export, discuss that option first, and then come back to Import once that is finished. Export takes each item in the queue and generates an XML file with the conversion parameters for each entry — much like the Generate Batch Script tool does. Unlike the batch script though, this file requires that HandBrake be open for it to be of use: once the generated XML file has been saved, Import is used to populate the queue with the items referenced within the XML file. In practice it makes sense to use the Export and Import tools when the need to edit conversion parameters for some or all of the items in the queue may present itself at a later date. Besides editing the Query Editor, there is no way to modify conversion parameters in a generated batch script; however, once a queue is imported using the Import tool, each item can be edited using the Edit function.

Finally, the dropdown menu at the top of the Encode Queue window, labeled “When Done:”, allows for a specific action to be taken once the queue has finished converting. These options include Do Nothing, Shutdown, Suspend, Hibernate, Lock System, Log Off, and Quit HandBrake. Due to the fact that encodes in general and especially those using high-level settings take quite some time to complete, this feature often comes in handy.

Encode Queue’s second section, labeled “Current Job”, contains information pertaining the the current conversion’s progress such as the source and destination location, progress, time remaining, and the parameters the video is being converted with.

The third and final section of the Encode Queue window displays each queue entry. Additionally, this area also displays the status of the current job, the number of chapters in the video, the location of the source and destination files, and the video and audio encoder HandBrake will use during the conversion. Right-clicking any of the entries in this area will cause a dropdown menu to appear containing four of the options discussed above: Move Up, Move Down, Edit, and Delete.

Next to the Show Queue button, the Preview button opens the Video Preview window. From this window a preview of the current source video, with the conversion parameters specified in HandBrake’s main window, can be quickly rendered to test the appropriateness of the output. This tool is especially useful when converting a video with subtitles, for example, to check and see if the video is going to appear as desired before spending an hour on the encode. Within the Video Preview window there are two fields and a few buttons: the first field, labeled “Start at preview:”, is used to select a starting point for the preview. The numbers in the corresponding dropdown menu do not necessarily correspond to seconds or chapters in the source video, they are simply arbitrary beginnings points for the encode. Next, the field labeled “Duration:” defines how long, in seconds, the preview should last. At the bottom of the window, the “Use system default player” checkbox causes the preview video, once encoded, to play using your system default player; otherwise, HandBrake uses VLC. Clicking the Play button to the right of the checkbox will begin encoding the preview video regardless of whether or not a video is already being converted in HandBrake’s main window or from the queue. Once finished, the preview video will be saved to the default output directory, from which it can be dealt with in the same manner a normal video would be. As soon as the preview is rendered, it will begin playing.

Last in line, the Activity Window button either opens or brings the Activity Window to the front. The Activity Window is automatically populated by something called the Scan Log. Every time a video is opened in HandBrake, HandBrake scans it for information to fill the main window with. The queried information includes filename, path (location), duration, video codec, bitrate, frame rate, and practically every other detail one could ever wish to know about a video. Once HandBrake has obtained this information it not only populates the relevant fields in the main window with that information, but also writes that information to the Scan Log. HandBrake saves the most recent scan log to the logs directory, which can be located by right-clicking the scan log’s window and firing on “Open Individual Log File Directory”. As a side note, clicking the “Copy” option, or clicking the “Copy to clipboard” button at the top of the Activity Window, will copy the scan log to the clipboard. The most recent scan log is saved as “last_scan_log1.txt”.

Back in the Activity Window, the dropdown menu currently labeled “Scan Log” contains one other option, allowing for the selection of the Encode Log as the current view rather than the Scan log. Every time HandBrake converts a video, details of the conversion such as path, output directory, and conversion parameters — as well as some of the video’s properties — are saved to the encode log. During the conversion, the encode log also contains information as to the conversion’s progress. Selecting “Encode Log” displays the most recent encode log in the Activity Window. The most recent encode log is also saved to the logs folder, just as the Scan Log is, as “last_encode_log1.txt”. Additionally, previous encode logs are combined with the respective video’s scan log and saved as a single plaintext file in the logs directory. These logs are named after the video from which their information was derived.

The Source Section #

Beneath the button bar, the Source section displays the source video’s name next to the label “Source:”. Additionally, this section also allows for the selection of the title to be used in the conversion, a starting point for the conversion, and an end point for the conversion. The start and end points can be set using chapters, seconds, or frames; be aware, however, that delimiting the conversion by chapters is the only method guaranteed to be consistent; choosing seconds or frames will not produce a consistent result. In my experience, both the Seconds and Frames options have yielded a variation of up to but rarely exceeding around three seconds from the desired end point. Selecting a title to convert is as simple as choosing an option from the dropdown menu labeled “Title:”. For most sources with the exception of DVDs, this menu will only contain one option, which HandBrake will automatically select after scanning the video. Next, the method for selecting the range of the conversion must be chosen. Once chosen, a start and end point can be selected from their respective dropdown menus. Leaving the start and end point fields at the defaults will convert the entire video. Finally, the length of the output video is displayed beside the last dropdown menu, next to the label “Duration:”.

The Destination section #

The Destination Section provides the ability to temporarily change the output directory and file name for the current conversion. The output directory is changed by clicking the “Browse” button and selecting a new directory, and the file name is changed by modifying the value in the text field labeled “File:”. Alternately, the destination location and file name can also be temporarily changed by editing the contents of the text field manually.

The Output Settings Section #

Most videos can be thought of as consisting of multiple levels: the first level is the container format, which is the file seen and interacted with through the file browser. Some common container formats, for example, are MKV and MP4. Within that container file, which functions much like a folder in the sense that it can contain multiple files within itself, resides the video and audio track, as well as any subtitles and metadata such as chapters. Each of these elements are stored as separate sub-files. From this point the various components can be further divided and examined, but for now this article is only concerned with the first level, the container format, and the second level where the audio, video, and subtitles are stored, and how they are stored there. HandBrake has the ability to utilize two container formats): either the MP4 container or the MKV container. Since container formats are simply wrappers for the data stored within them, neither format has any compression or quality advantage over the other. To choose either the MP4 or MKV container, select the desired format from the dropdown menu next to the label “Container:”.

Continuing on in the Output Settings section, there are three checkboxes labeled “Large file size”, “Web optimized”, and “iPod 5G Support”. These three checkboxes allow the conversion to be fine-tuned for one or more of the three scenarios outlined by their names; that is, by ensuring that an MP4 file breaching 4GB is not corrupted, optimizing the video for web-streaming, or forcing compatibility with fifth-generation iPod Nanos, respectively. Note that these options are only valid for the MP4 container though, and thus will be disabled if the MKV container format is selected.

With a source, range, destination, and container format defined, the remaining conversion parameters such as resolution, frame rate, and subtitles are set within HandBrake’s eight tabs: Picture, Video Filters, Video, Audio, Subtitles, Chapters, and Advanced. Each tab is discussed in detail in the order I listed them throughout the following paragraphs, beginning with Picture. However, here is a brief summary of each: the Picture tab controls the output resolution of the video, and defines any cropping applied to the video during the encode. Video Filters allows for the application of various filters to the output video with the intent to improve playback quality. Video, the third tab in line, provides for the selection of the video codec for the conversion, as well as the frame rate and bitrate. Audio, next in line, contains options for choosing the audio track for the encode. Subtitles controls the application of subtitles in the video. Second to last, the Chapters tab displays the chapters of the source video and allows for chapters to be turned off in the output video. Finally, Advanced is used to set various high-level parameters such as the maximum number of reference frames, for example, or the method used for motion estimation. Special attention will be afforded to this tab later on in the article.

The Picture tab consists of two sections: Size and Cropping. To the left, the Size section contains fields and options for customizing the output resolution. On the right, Cropping controls any cropping applied during the encode. By default, HandBrake automatically sets cropping depending on the resolution set in Size; however, selecting “Custom” rather than “Automatic”, the default option, enables cropping to be applied manually. To select an output resolution, first expand the Anamorphic dropdown menu. This menu contains four options: “None”, “Strict”, “Loose”, and “Custom”. “None” allows for both the height and width of the output video to be manually set, thus providing a higher degree of control than “Strict”, which prevents any change in resolution. “Custom” offers the most control of all four options, with “Loose” coming in as a compromise between the four. “Loose” automatically retains the source aspect ratio, a key attribute of a video and a crucial property to retain in order to produce the highest quality result possible, while also allowing for the resolution to be manually set through the modification of the field labeled “Width:”; once this value has been set, HandBrake automatically adjusts the height for the conversion to match the source aspect ratio. At the bottom of this section, the output display size is presented next to the label “Display Size:”.

Next, the Video Filters tab allows for the application of certain filters to a video during the encoding process. Available filters are as follows: Detelecine, Decomb, Deinterlace, Denoise, Deblock, and Grayscale Encoding.

The next tab in line, Video, has two sections: Video and Quality. The Video section is used to select the video codec and frame rate to be used in the output video, while the Quality section contains fields for setting the bitrate.

Earlier I explained that audio and video tracks are stored within container files, though I did not explain how they are stored, simply that they are stored there. To store this media, encoders utilize something called a codec. The word “codec” comes from a combination of the two words “encoder” and “decoder”, and thus is a set of rules defining the manner in which the form of media should be stored (encoded) within the container format, and the manner in which the media should be read (decoded) by the player.

The Video Codec dropdown menu allows you to choose between HandBrake’s four available video codecs: H.264, MPEG-2, or MPEG-4 for the MP4 container, and an additional VP3 codec for the MKV container. Each of these codecs are inherently lossy, which means that they apply some form of compression to the data stream while also removing data deemed to be “extraneous” during the encoding process, all in order to achieve a smaller file size. The combination of compression and data removal results in the loss of some quality, though the decrease in quality depends on a number of factors. Lossless codecs, on the other hand, do apply some compression, but unlike lossy codecs retain all the data in a stream. Lossless codecs therefore produce larger files, but due to the fact that they retain all the information from the source they are the preferred method for storing media in a manner through which to preserve as much quality as possible. It is important to note, however, that just because a codec is defined as “lossy” does not necessarily mean that a video, or any other form of media, stored using that codec will necessarily be of a lower quality than that same file utilizing a losslesss codec: it all comes down to video codec and the settings used to convert the video.

In this case, of the four available codecs, H.264 is by far the best option: supported by both container formats, the H.264 codec is not only more versatile, but also possesses numerous advantages over the MPEG-2, MPEG-4, and VP3 codecs. For example, videos encoded with the H.264 codec are able to achieve higher levels of quality at smaller file sizes than videos utilizing almost any other codec currently available, especially compared to HandBrake’s two alternatives. Additionally, rather than requiring the operating system to decode videos utilizing the H.264 codec, many mobile devices possess built-in hardware chips dedicated to decoding H.264 videos, resulting in lower power consumption during H.264 playback than with other codecs. There are other advantages to using the H.264 codec, such as more accurate motion estimation and interframe prediction, but the two reasons above — high-quality videos at smaller file sizes and decreased power consumption during playback — are arguably the most widely applicable.

Beneath the Video Codec dropdown menu, the frame rate menu contains options for manually selecting a frame rate for the output video, or using “Same as source”. As you may have guessed, “Same as source” uses the original video’s frame rate in the conversion.

Earlier, I mentioned that the detelecine feature has historically caused jumpy playback due to erroneously deeming certain frames as duplicates and removing them. Since videos are simply a collection of similar still images — frames — cycled through your field of vision fast enough to create the illusion of continuity and movement, the detelecine feature was able to cause this effect by disrupting that continuity of movement. A similar effect can be achieved by lowering a video’s frame rate: by lowering a video’s frame rate, data is removed that needs to be there in order to create the fluid movement expected of a video. Similarly, raising a video’s frame rate past the original value simply causes data to be duplicated in order to achieve the new frame rate, thus resulting in a larger file size without any increase in picture or playback quality.

Below the Framerate dropdown menu, the “Constant Framerate” checkbox forces the encoder to use the specified framerate throughout the entire video; “Variable Framerate”, on the other hand, allows the encoder to use lower framerates in scenes where little movement takes place, thereby greatly reducing the output file’s size.

The bitrate is another important factor in the overall quality of your video conversion, and is set within the Quality section of the Video tab. This parameter can be set in one of two ways: by setting the Avg Bitrate (kbps) field, which forces HandBrake to use the given bitrate in the conversion, or through the Constant Quality slider, HandBrake’s default and the recommended method for setting the bitrate.

The Constant Quality slider is automatically set depending on the selected video codec, though it is not required that the default value be used in the conversion. For example, when using the MPEG-4 codec, a QP (quantization parameter) value of 15 is set by default, whereas when using the H.264 codec, an RF (rate factor) value of 20 is used as the default. The QP and RF values are collectively referred to as the Constant Rate Factor, or CRF. I will discuss QP vs RF values in a bit, so for now bear with me.

Though it is possible to modify the default CRF value set by HandBrake, for most applications it is recommended that the default set by HandBrake be used. By moving the Constant Quality slider to the left or to the right, the amount of compression HandBrake will apply during the encoding process is adjusted. A higher CRF value will cause more compression to be applied to the video, while a lower value results in less compression and a higher-quality result, albeit in a larger file size. In fact, a CRF value of zero will apply absolutely no compression at all: it will convert the video in a completely lossless format. However, though this may sound like the ideal setting, the result is simply a massive video file that posses no greater level of quality than it would if it was converted with, for example, an RF value of 20. Note that the value of 20 was arbitrarily chosen to illustrate my point and is not necessarily the value you should select for each conversion. HandBrake’s wiki page on Constant Quality provides some example CRF values for common usage cases: for standard definition videos such as DVDs, it is recommended that an RF value of around 20 be applied. For high definition videos, however, such as Blu-rays, 720p, or 1080p videos, an RF value of approximately 22 is recommended.

Maintaining a constant quantization parameter (QP) value means compressing each frame by the same amount, whereas maintaining a constant rate factor (RF) value tells the encoder to compress different frames by different amounts according to detected motion. This functionality very closely mirrors the variable framerate option discussed earlier, which uses detected motion to determine whether or not the framerate can be safely reduced in any given part of the video without negatively effecting the quality of the result. Put more simply, setting a quantization parameter applies the same level of compression to the entire video regardless of movement or other factors, whereas setting a rate factor tells HandBrake to adjust the compression based on movement in the frame, with more compression being applied to scenes with a greater amount of movement since those scenes require less fine detail, and less compression being applied to scenes with little to no movement. Though it might seem, at first, that using a QP value would be more advantageous than using an RF value — especially for achieving a small output file size — it is, in fact, the opposite: setting an RF value is the preferred method for choosing a bitrate because it not only produces a smaller file, but also produces videos of a higher quality than those converted using a QP value because it applies less compression to frames that are more likely to be scrutinized, and more to frames that are less likely to be closely inspected. This is yet another reason why the H.264 codec, which uses RF compression, produces a higher-quality result at a better size than the MPEG-4 codec, which uses QP compression.

Earlier in my discussion of video codecs, I explained that both audio and video are stored within container formats as separate objects using something called a codec. As you know, HandBrake provides for the utilization of a few different video codecs; similarly, HandBrake offers four different audio codecs for the MP4 container, AAC, MP3, AC3, and DTS, as well as two additional formats for the MKV container: Vorbis and FLAC. For each of these codecs with the exception of Vorbis and FLAC, HandBrake offers multiple choices for audio encoders, such as the LAME encoder for the MP3 codec or the faac and ffmpeg encoders for the AAC codec. Each codec also has another option which, for simplicity’s sake, can be considered an encoder of sorts: passthrough. The passthrough “encoder” simply passes the source audio to the new format without using a separate audio encoder. Thus, whereas each of the available audio codecs with the exception of FLAC are inherently lossy — FLAC stands for “Free Lossless Audio Codec” — their “passthrough” counterparts are, on the other hand, lossless as in the case of the DTS codecs, or virtually lossless as in the case of the other audio formats. In order to retain the highest audio quality possible, it is recommended that one of these lossless formats be used. If you would prefer to use an audio codec with a higher compression ratio though, the AAC audio codec is the next best option as it provides higher quality audio than the MP3 codec at similar bitrates.

Before selecting an audio codec though, a source audio track must be selected. Like choosing a title to encode in the Source section, HandBrake rarely presents more than one audio track; however, when there is, it is extremely important that the correct track is selected. To select the source audio track, simply choose the appropriate option from the first dropdown menu in the Audio tab. If there is more than one option, each entry will generally be labeled with a language. For example, the first entry might read “1 English”, with the second entry labeled “2 Japanese”. Following the track’s name, HandBrake includes the codec it is stored with as well as the number of audio channels. Once an audio track has been selected, choosing an audio codec is as simple as selecting the desired option from the Audio Codec dropdown menu. When choosing an audio codec, keep in mind that while choosing a lossless audio codec such as FLAC or encoding the audio in a lossless manner using one of the passthrough “encoders” is theoretically a better idea than using a lossless format, the difference in audio quality will almost never be noticeable, and will only result in larger output files. Next to the Audio Codec dropdown menu, HandBrake provides six mixers for the audio track: Mono, Stereo, Dolby Surround, Dolby Pro Logic II, and 6-channel Discrete.

Unlike Stereo, the mono mixer is designed to handle single-track audio streams and therefore centers the perspective in the sound field, whereas the stereo mixer uses two or more independent audio channels to produce the illusion of direction and perspective during audio playback. Although mono has largely been replaced by the stereo mixer, some fields continue to use it to this day. Continuing this trend of increasing audio channels, Dolby Surround, HandBrake’s next option for audio mixers, combines three independent audio streams to create an increasingly realistic soundscape. Dolby Pro Logic II takes a stereo track — recall that the stereo mixer uses two audio channels — and processes those two channels into five full-frequency audio streams in order to provide high-quality surround sound. 6-channel Discrete, on the other hand, stores six separate audio channels for use in playback.

Before I finish this section on mixers with my personal recommendations on the topic, let me talk a little bit more about Dolby Pro Logic II and how it works. As I said in the previous paragraph, the Dolby Pro Logic II mixer accepts a two-channel stereo track and, depending on the quality of the source, processes those two channels into five separate streams for surround sound playback. These five streams create the immerse surround sound experience by playing a track through each of the right front, center, left front, right rear, and left rear fields. As an aside, the 6-channel Discrete mixer relegates an audio track to each of these five fields as well as the missing area, center rear, when the audio track provides for this type of playback. The aspect that makes the Dolby Pro Logic II mixer especially interesting is that while other surround sound mixers require that the source already be formatted for surround sound, DPL II processes the much more common stereo audio track into the necessary five channels by extracting the difference between the spatial audio content of the two individual stereo channels. This feature provides for the application of surround sound in an audio stream not previously equipped with such an ability, an impossibility with the other surround sound mixers offered by HandBrake. Fortunately, HandBrake makes the mixer decision an easy one by displaying the number of channels contained within the source audio alongside the name of the track. In the unlikely case that the source audio is single-channel, using anything other than the mono mixer is pointless. In the event that the source audio consists of two tracks, on the other hand, both the stereo mixer or the DPL II mixer are suitable choices depending on whether the need for surround sound presents itself. For 5.1 channel audio tracks, HandBrake automatically chooses Dolby Pro Logic II as the mixer; I recommend leaving this choice as-is.

The sample rate is defined as the number of samples taken from a stream per unit of time. In its most basic form, the sample rate can be thought of as similar to the frame rate: the frame rate is the number of frames you see per second, while the sample rate, in the case of audio encoding, is the number of “frames” you hear each second. Just like when setting the frame rate, using a value as close to the source’s is the best way to produce a crisp and clear result, therefore making “Auto” my recommended setting for this field. Next to the Samplerate field, the Bitrate menu allows you to select a bitrate for the audio track. It is important to note that regardless of the conversion settings you use, the audio in your output video will never be of a higher quality than the source. If the source audio has a bitrate of 128kb/s, using 256kb/s in your conversion will just result in a larger file size, not an increase in quality. Therefore, the best way to set the audio bitrate is to take a look at the audio bitrate for the source video and use a bitrate close to the original’s as the conversion parameter. To check the source file’s bitrate, open the Scan log and browse through it until you find the audio bitrate, which should be around line 36. You can also use Ctrl+F to search the file for the label “Audio:”; the audio codec, sample rate, mixer, and bitrate for the source file will all be located on the same line in the order I just listed them.

Next to the Bitrate field, the DRC — or Dynamic Range Compression — parameter and the audio gain are both set in the Advanced Audio window, opened by clicking the Advanced button towards the right edge of the section. When recording with a microphone, for example, increasing the gain magnifies the amplitude, or signal strength, of the sound currently being processed by the microphone, thereby causing the microphone to become more sensitive to sound and thus making the recording louder; conversely, lowering the gain lessens the signal strength and thus causes the microphone to become less sensitive, making the recording quieter. With this talk of increasing and decreasing the volume of a recording through the modification of gain, it is easy to become confused as to the actual role of gain control in audio processing: the gain should not be used to make a recording louder or softer; that is the job of the volume. Instead, gain should be used to increase the sensitivity of the microphone, thus providing for clearer recording if set correctly. That said, HandBrake implements gain in a manner not exactly synonymous with the widely accepted usage of gain: in HandBrake, gain is actually used to increase or decrease the volume of an audio track. When using the gain to accomplish this task in HandBrake, setting the gain at anything more than +10 is guaranteed to cause the audio track to become distorted during loud parts and virtually inaudible during very quiet scenes.

Below the Audio Gain setting, the Dynamic Range slider makes it possible to manually set the dynamic range of an audio track. The dynamic range is the ratio between the largest and smallest possible values in the audio track. Setting this value manually both increases the volume of quiet sounds and decreases the volume of loud sounds, bringing the waveform closer together. HandBrake’s wiki page on the subject, Dynamic Range Compression, provides examples for suitable values: the default value of 0 prevents HandBrake from applying any dynamic range compression to the audio stream; a value of 1.0 uses compression hints embedded within the audio track; a value greater than 1.0 normalizes the audio stream as described above.

Next in line, the Subtitles tab has three buttons at the top: Add, Remove, and Import SRT. Add and Remove are self-explanatory: they add or remove a subtitle track from a video, respectively. Import SRT, on the other hand, requires a bit of explaining. Before I go into the details though, take a look at an extract from a sample SRT file:

1

00:00:01,000  — > 00:00:05,000

This is the first subtitle

2

00:00:06,000  — > 00:00:10,000

This is the second subtitle

3

00:00:011,000  — > 00:00:15,000

And this is the third subtitle

This snippet of text, which would be saved as a *.SRT file, tells the video player to present “This is the first subtitle” from the first second through the fifth second. After the first subtitle, “This is the second subtitle” would be presented for four seconds, after which “And this is the third subtitle” would be displayed from the 11th through the 15th second. The numbers — in this case 1, 2, and 3 — preceding the timestamp define the subtitle’s number, which allows the player to present the subtitles in the correct order. Beneath the subtitle’s number, the timing is in the format of HH:MM:SS,MS. First, a starting point for the subtitle (the contents of which are defined on the next line) is chosen, followed by “ — >”, then an end point. As I said in the last sentence, the third line in the set is the contents of the subtitle for the given amount of time. This is what makes up an SRT file: a very, very long collection of similar entries to the one above. For most videos, the SRT file is bundled into the container format, though on DVDs, for example, you can often find single SRT files for alternate languages somewhere in the file tree. The Import SRT option allows you to take a standalone SRT file and bundle it together with your output video during the encoding process, thus resulting in that single container format with yet another separate file inside it.

Regardless of whether you are importing an SRT file or not, you need to select the subtitle to add from the “Track” dropdown menu, which is the first menu in the Subtitle tab. Generally, the subtitles listed in this menu will be named something like “English UTF” or “English SSA”. SSA and UTF are the two most common character encodings I have seen subtitles in, though there are many other character encodings available. If you do not see “English character encoding”, there should be an option labeled “Foreign Audio Search (Bitmap)”. If HandBrake cannot identify the subtitle track in the source, this option will attempt to extract bitmap images of the subtitle track from the source file to be used in the output video. If no subtitle track can be found, the Foreign Audio Search (Bitmap) option will still be displayed in the “Track” menu, though selecting it will not cause any subtitles to be added to the output video since they do not exist.

With a subtitle track selected, you have to decide how it will be displayed on your video. To do this, HandBrake provides three checkboxes that decide which and in what manner those subtitles will be presented to you during playback. In order of appearance, the checkboxes are as follows: Forced Only, Burned In, and Default. First, Forced Only tells HandBrake to display subtitles only when they are “forced” in the source video. For example, if you were watching a film mostly in your native language with a few parts in another language, the movie would most likely have subtitles at the parts during which a foreign language was spoken. These are called forced subtitles, and are present whether or not you turn on subtitles for the rest of the movie. Second in line, the Burned In option overlays the subtitle track on the video. At first glance this might seem like a bad idea, but consider the manner in which subtitles are displayed otherwise: if a subtitle track is not burned in to the video, the text will display in a small, opaque bar at the bottom of the screen. The subtitles will display one after another in this manner according to the length they are prescribed to display for — just as they should. However, due to the size of the display bar on some devices, only one line can be displayed at a time. For the most part this is fine, but as soon as multiple subtitles need to be displayed at once — think numerous people speaking at once, for example, or a crowd shouting — you begin running into problems. As soon as more than one line of text needs to be displayed at the same time, the video player will split that text into separate lines and display them individually, which results in either the last subtitle overwriting all previous entries in the set, or each subtitle being displayed for x seconds. But since as far as the video is concerned each of those multiple subtitle lines were displayed at once, the subtitle timing can become offset for the rest of the video. Therefore, Burned In is the best option to use if you know you will have multiple lines of subtitles at any point in the video. You cannot, however, turn off subtitles if they are burned in to the video, so think carefully before you choose this option. Finally, Default causes the subtitle track to appear automatically rather than requiring the viewer to manually turn it on after the video starts playing. If you are using the Burned In option you do not need to check Default.

Next to the three checkboxes explained in the previous paragraph, there are three more fields: Srt Language, Srt Char Code, and Srt Offset (ms). These three fields are only applicable if you import an SRT file, in which case they allow you to select the SRT file’s language, character encoding, and provide an offset in case the timing is somewhat off, respectively.

As soon as you’ve finished customizing your subtitles’ settings, clicking the Add button will add that subtitle track to the video during the conversion. A list of subtitle tracks that will be added during the conversion can be found near the bottom of the Subtitles menu. This area not only displays the track’s name, but also whether or not the specific subtitles track was added with the Forced Only, Burned In, or Default options. To remove a subtitle track from a video, highlight it and click Remove.

Continuing on down the line, the Chapters tab allows you to view, edit, import, and export video chapters, as well as turn them off in the output video. Video chapters are simply logical splits in the video that divide it into sections which can be skipped to during playback. An example of good chapter usage would be a chapter for a show’s introduction, a chapter for the main title, and a chapter for the ending, which could include title credits or a preview of the next show, for example. Various other chapters could be added, but that would be a good example of logical splits in a video using chapters.

If you want to turn chapters off for some reason, simply de-select the checkbox labeled “Create chapter markers” near the top of the tab. If this checkbox is grayed-out, your source video does not have any chapters. Beneath the checkbox, the current chapters are displayed in two columns: Chapter Number and Chapter Name, which contain the chapters’ number and name, respectively. If you would like to view the start and end time of a chapter, open up the Scan log and look for a line resembling this one:

Metadata:

title    : Prologue

Chapter #0.1: start 182.089000, end 271.979000

There will be an entry similar to this one for each chapter in the video. Each entry contains the following information: the chapter’s title, number, and start and end time, in seconds. From this information you can fairly easily discern a chapter’s place in the video, and change the chapter’s name in HandBrake’s main window if you wish. To change a chapter’s name, simple double-click the entry in the Chapter Name column, then type in the desired chapter name.

The last tab in line, Advanced, handles the nitty-gritty details of motion estimation, inter frame prediction, video compression, and many more advanced conversion parameters for the H.264 video. The settings within this tab are automatically set and locked from changes for both the MPEG-4 and VP3 codecs. For customizing the conversion parameters, the settings in this tab are divided into three sections: Encoding, Psychovisual, and Analysis. The Encoding section deals with video compression; Psychovisual toggles the x264 encoder’s DCT-Decimation feature, which prevents the encoder from removing data blocks deemed to contain little or no information; and Analysis manages the encoder’s settings for analyzing the source video.

Encoding #

Interframe prediction is a process that involves storing a fully independent reference frame, called an I-frame, and comparing it to a variable number of subsequent frames. If any similarities are found between the I-frame and those subsequent frames, the duplicate data will not be stored in the subsequent frames and will instead be referenced from the I-frame. Frames that reference data are one of two types: P- or B-frames. P-frames can make references to parts of earlier I- or P-frames instead of storing that information, and on average contain around 50% of the data an I-frame does. B-frames, on the other hand, make references to preceding and succeeding I- or P-frames, and can contain as little as 25% of the data an I-frame stores. Here are a few examples to aid in the comprehension of this concept:

I  I  I  I

This is an example of how videos that do not use interframe prediction store information: each frame as an entirely independent image with no references made to previous (or succeeding) frames regardless of whether or not any duplicate information is present between them. Now if that video were to be converted and the use of P-frames was enabled, it would look something like this:

I  P  P  P

Frame #1 is the I-frame, as the set must start with a full image containing all the information; frames #2, #3, and #4 are all P-frames that reference either the I-frame or one of the preceding P-frames, and only include the information that has changed between its frame and the preceding frame. So, for example, if these four frames were part of a longer video of a person walking to a house, the I-frame would contain everything: the person, the house, and the surroundings. The P-frames, then, would reference the house and the surroundings from the I-frame, as those would remain consistent from frame to frame, and would only include the person’s movement between each frame.

Now think back to my description of P-frames: when I was explaining P-frames, I described them to contain as little as 50% of the data in an I-frame. Even in a four-frame example such as this, the decrease in size is significant. If P- and B-frames are used though, the size decrease becomes even more significant. The resulting video, when played, would look something like this:

I  B  B  P

In this video, the first frame is an I-frame. Then, instead of three P-frames, two B-frames are substituted for the middle P-frames. The video ends with a P-frame due to the B-frames’ requirement of having something to reference both preceding them as well as succeeding them. However, due to the nature of B-frames, the video is actually encoded with this frame order:

I  P  B  B

The frames are stored within the video in this order because B-frames must have a frame to reference both preceding them and succeeding them, so the encoder must first encode the I-frame, then encode a P-frame in order to give those B-frames something to reference in front of and behind them. Once the I- and P-frames have been encoded, the two B-frames are encoded and inserted between those two frames, resulting in what you end up watching: I B B P. Otherwise, if the frames were encoded in the same order as they are perceived, the B-frames would have no succeeding frames to reference, and would therefore be incomplete. But the encoder does not encode the first frame (the I-frame), encode the second frame (the P-frame), and then insert two additional frames between them — that would only result in larger files, not smaller ones. Instead, this is the process the encoder uses:

  1. Encode the first frame in the set. This is the fully-independent I-frame. The video now looks like this: “I”
  2. Jump ahead and encode the fourth frame in the video, totally disregarding frames #2 and #3. Note that it is only the fourth frame in this example and could vary depending on the conversion settings. Now, the video looks like this: “I  P” Where “I” is the first frame, and “P” is actually the fourth frame in the video, not the second; it is only placed in the second’s place for the time being. You can think of the frames in the example above as in this order to make the concept clearer: I _ _ P.
  3. Next, the I- and P-frames are compared: any differences found between them — and there will be quite a few since the first frame is frame #1 and the second frame is actually #4 — are made into B-frames. The number of B-frames used is a parameter for the conversion, and therefore will vary. The finished video looks like this: “I  B  B  P”

In the end, we wind up with a video that, instead of containing four full-image frames, has a single full-image frame followed by three reference frames. By discarding frames #2 and #3 in this example and substituting them with B-frames containing up to 25% of the data the original frames would have, the output video will be much smaller than the original. The use of this sort of compression makes eliminating a great deal of data that does not necessarily need to be there possible, with little cost to the overall quality of the video. However, due to the fact that, in this case, two frames are completely discarded and their contents interpolated from the surrounding frames, there is some decrease in quality.

The Reference Frame setting in the Advanced tab controls the number of reference frames that can be used by the encoder. HandBrake’s default is one, which means that the video encoder will use one P-frame in the conversion, preceded by a variable number of B-frames set in the next field. Currently, the H.264 video codec supports a maximum of 16 reference frames, which means that a maximum combination of 16 P-frames could be used in a video utilizing this codec before a new I-frame would need to be used. The general consensus, though, is to use no more than four reference frames to avoid losing too much quality. HandBrake recommends between 1 and 6 for optimal quality.

Next in line, the Maximum B-Frames setting controls the number of sequential B-frames that can be implemented before a new I- or P-frame must be inserted. The H.264 codec currently supports a maximum of sixteen B-Frames before a new I- or P-frame must be used, though the recommended number is much less: HandBrake recommends between two and five sequential B-frames, though it is generally accepted that no more than three B-frames should be used sequentially in order to achieve the ideal trade-off between quality and file size.

Earlier, when I discussed lossy and lossless codecs, I explained that both types of codecs do compress data; the key difference between lossy and lossless codecs is that lossy codecs discard data deemed to be extraneous. A common example of data that might be discarded by a lossy codec would be sound regarded to be beyond the range of human hearing. Regardless of the type of codec though, lossy or lossless, the data stream is compressed in order to save space. In HandBrake, there are two available compression schemas: CABAC and CABLC. CABAC, short for Context-Adaptive Binary Arithmetic Coding, is known to require less processing power to decode than the CAVLC coder, though compresses data less effectively. CAVLC, short for Context-Adaptive Variable-Length Coding, on the other hand, compresses data streams with better results, though at the cost of decoding speed. To turn on CABAC coding, select the checkbox next to the label “CABAC Entropy Coding”; un-checking this field will cause HandBrake to utilize the CAVLC coder.

Motion estimation is the process of defining motion vectors that describe the transformation of blocks from one frame to another. Motion compensation is the result of this process: by calculating the change between the blocks of two or more adjacent frames the encoder can determine which blocks, if any, are duplicates of the original frame’s whose places were simply shifted. If any duplicates are found that match this criteria, they will be referenced from the original I-frame or a preceding P-frame. In a nutshell, that’s how inter frame prediction works. This process relies entirely on something called macroblocks, which are composed of two or more blocks of pixels. The actual block size varies depending on the video, but here are a few of the more common block sizes (in pixels): 16x16, 8x8, and 4x4. The smaller the block size, the more likely a match will be found between the original frame and subsequent frames, which in turn results in a smaller video since a larger amount of data can be referenced rather than stored. The 8x8 Transform checkbox allows HandBrake to use 8x8 blocks rather than, for example, 16x16 blocks. By using smaller block sizes the encoder can more accurately estimate motion and utilize inter frame prediction, which in turn produces smaller files.

Enabling weighted P-frames, done by checking the Weighted P-frames checkbox, allows the encoder to assign “weights” to reference frames. This feature is especially helpful during fades where one frame is simply darker or lighter than the preceding frame. In most cases the encoder is unable to recognize the similarity between frames in this situation for the simple reason that the entire image is changing. However, by enabling weighted prediction the encoder is more likely to recognize the similarity between frames in a fade-like situation, which means more reference frames. And as you know by now, more reference frames means a smaller file size. Note, though, that not all devices support this feature, so you may want to use the Preview tool to generate a short preview in order to test for compatibility.

Remember back when I was describing B-frames and said that they could not reference other B-frames, just preceding or succeeding I- or P-frames? That is not entirely true: so long as you allow more than one consecutive B-frame, setting the Pyramidal B-frames dropdown menu to “Normal” or “Strict” will enable B-frames to reference other B-frames. By default HandBrake allows this, though you can disable this feature by selecting “Off”; however, as it will decrease the video’s size with little to no loss in quality, if any, I recommend keeping this feature enabled.

Psychovisual #

During the conversion the encoder considers each data block before writing it to the output video. By default, blocks that are deemed to contain little or no data are simply discarded — decimated, one might say. However, by checking the No DCT-Decimate checkbox you can disable this feature, thus allowing even data blocks that contain little or no information to be written to the output video. The encoder is generally pretty good at determining whether a block contains useful data though, so leaving this option at its default, enabled, is recommended, as disabling DCT-decimation will not increase your video’s quality by a noticeable amount and in most cases simply offers a larger file size.

Analysis #

When determining whether to use a B-frame or not, the x264 encoder has a variety of algorithms at its disposal. The Fast mode, HandBrake’s default, takes the same amount of time regardless of the number of B-frames. However, due to its speed the results are often sub-optimal. If you want the best results, the highest quality video at a small size, choosing Optimal is the recommended course of action. By using the Optimal mode the encoder will take longer to convert the video, but the resulting video will be both smaller and of a higher quality. Additionally, Optimal is recommended if the use of pyramidal B-frames is enabled, as B-frames referencing other B-frames can quickly lead to poor quality if not handled correctly.

The Adaptive Direct Mode setting has four options for choosing the manner in which the encoder predicts motion in B-frames: Spatial, Temporal, None, and Automatic. Spatial mode uses the motion vectors from neighboring blocks rather than calculating a new motion vector for each block, thus cutting down on the number of calculations required and speeding up the overall conversion process. The Temporal option compares the current block to the matched block in a succeeding P-frame and uses this measure to estimate the motion rather than calculating it again for each block. None, as you might guess, does not use any prediction, thus causing a motion vector to be calculated for each block. The last option, Automatic, allows the encoder to choose the prediction mode — either Spatial or Temporal — depending on the situation. Spatial is HandBrake’s default and the recommended choice, though Automatic will provide a small compression gain with an accordingly small increase in encoding time.

When estimating motion between blocks, the encoder has a variety of search patterns at its disposal. The Motion Estimation Method dropdown menu within the Analysis section allows you to choose from a list of five different search patterns listed in the order of fastest to slowest, least precise to greatest precision: Diamond, Hexagon, Uneven Multi-Hexagon, Exhaustive, and Transform Exhaustive. Diamond uses a diamond-shaped search pattern for detecting motion, whereas Hexagon is able to produce more accurate results by using a hexagonal search pattern, at the cost of some speed. Uneven Multi-Hexagon uses multiple complex search patterns to more accurately capture complex motion, and is thus slower than each of the previously mentioned settings. Exhaustive does not use a search pattern and instead compares each pixel, significantly lengthening the time required for conversion with a reportedly small compression gain. Finally, Transform Exhaustive is the most accurate setting for estimating motion and requires more time than all the other settings. Transform Exhaustive offers a small compression gain over Exhaustive.

By default HandBrake uses the Hexagon pattern, which is fine for most applications. If you really need the boost in encoding speed, Diamond is your best bet, though it will produce sub-optimal results. Conversely, if the speed of the encode is irrelevant to you, using Transform Exhaustive will produce the clearest video at the smallest file size of all the options presented above.

With motion estimation being one of the greatest advantages of the H.264 video codec over most other codecs, it is not surprising that there is yet another setting for improving the accuracy of motion estimation. Subpixel ME & Mode Decision allows you to set the precision of sub-pixel motion estimation, which allows the encoder to refine motion estimates beyond pixel measurements into fractional measurements. By refining the measurements in this manner a greater amount of compression can be applied to the video. A lower value in this field will result in a faster encode, though at the cost of size and quality. A higher value, on the other hand, will produce a sharper video at a smaller size, though at the cost of conversion speed. HandBrake’s default for this setting is six out of ten: this is acceptable for most applications.

The Adaptive Quantization Strength slider controls how the encoder will distribute bits across each frame. A default value of zero will cause the encoder to distribute bits evenly across the screen, whereas higher values place more emphasis on the center of the frame by placing fewer bits around the edges and increasing the number of bits in the center.

The third and final column in the Advanced tab starts off with the Partition Type setting. This setting controls the number of partitions that will be considered by the encoder during the encoding process. HandBrake automatically turns this feature on, and it is recommended that either the default setting or All be used as this will improve compression.

Turning on Trellis can improve the compression of your video by between 3-5%, though at the cost of encoding speed, especially at higher bitrates. HandBrake provides three settings for the trellis: Off, which turns trellis off for the conversion; Encode Only, allowing trellis only during the video encode; and Always. Always allows trellis to be applied during both the video’s scan and during the encoder, which results in an even greater decrease in size.

The last setting in the Advanced tab helps to smooth out blocking artifacts after each frame is decoded by applying a filter to the video during playback. The aggressiveness of the filter is set with the first dropdown menu, with a lower value corresponding to a small amount of deblocking and a higher value applying a greater amount of deblocking. Below the strength menu, the second dropdown menu allows you to select the number of edges this filter applies to: a lower value means fewer edges, while a higher value means a greater number of edges will be effected. Since this filter is being applied during playback though, it is fairly CPU intensive and therefore not recommended for devices with small processing power such as iPods or other portable media players.

Despite my earlier claim, HandBrake actually contains nine tabs: in addition to the eight described above, one additional tab, Query Editor, can be enabled in HandBrake’s Options screen. Once enabled in “Advanced”, HandBrake will require a restart, and upon opening again will contain the ninth tab: Query Editor. HandBrake is, quite simply, a graphical user interface — a wrapper, if you will, used for setting parameters which are then passed to the command-line interface. The Query Editor tab strips away part of the wall between the two worlds by providing for the manual modification of the CLI query prior to adding a video to the queue. From this view, the CLI query can be edited to suit your needs. Note, though, that none of the changes made in the Query Editor will be reflected in the main interface, and clicking the “Generate Query” button will reset the query to the values set through the GUI. So for example, if you modified the output width in the Query Editor to be 600 pixels instead of the 800 pixels set in the Picture tab, the Picture tab would still contain a value of 800 in the Width field, and clicking “Generate Query” would change the 600 back to 800, as well as undo any other changes made to the CLI query. The Query Editor does, however, override the parameters set through the GUI when adding the video to the queue though: going back to the example of having set a width of 600 pixels for the video in the Query Editor tab, regardless of the Width field’s value, the video will be added to the queue with an output width of 600 pixels.

The Presets Section #

Located on the far right side of HandBrake’s main window, the Presets section contains a list of built-in presets as well as any custom presets you may have created. In HandBrake, a preset is simply a collection of conversion settings that can be loaded with the click of a button. Settings such as resolution, video and audio codecs, and even advanced conversion parameters can all be stored within a preset and applied to any video. The main benefit of a preset becomes apparent when you begin to use HandBrake often: every once in a while opening the Video tab to change the codec, to customize the resolution in the Picture tab, and modify some of the more advanced settings in the Advanced tab is not a big deal; however, doing this more than a few times is both time consuming and annoying. Enter presets: by creating a saving a preset you can automatically load these settings with a single click rather than manually modifying the conversion parameters each time you open HandBrake, saving you both time and frustration. HandBrake comes with a number of built-in presets: seven for converting videos specifically for Apple devices, four for general purpose video conversions, and two presets designed to suit the Android platform.

You are not limited to the presets bundled with HandBrake though. Creating a preset is actually quite easy: simply add a video to HandBrake and change the conversion parameters to match your requirements. Next, click the Add button at the bottom of the Presets section. A window will pop up prompting you to name the preset. Note that custom presets are stored at the bottom of the Presets window, beneath the built-in presets, in alphabetical order, with numerical names first. Once you have decided on and entered a name for your preset there are two more fields to be considered before you click Add at the bottom of the window. The first field, labeled Use Picture Size, has thee options: None, Source Maximum, and Custom. Choose None if you do not want the resolution currently set in the Picture tab to be saved in the preset. If you do want to save the resolution in the preset though, select Source Maximum. Choosing Custom allows you to input a height and width for HandBrake to match whenever this preset is applied. The checkbox beneath the Use Picture Size menu, Save Filter Settings, will, if checked, store the current video filter settings in the preset. Click Add to save the preset. It will now appear in black letters at the bottom of the Presets window.

HandBrake is considered by many to be the most powerful video transcoder available to date. This guide has given you the knowledge necessary to begin using this powerhouse application by teaching you the basics — how to get HandBrake up and running on your machine, and how to use HandBrake to transcode a video. After reading this guide, the reason behind HandBrake’s esteemed position should be very clear: not only does it facilitate for the utilization of the H.264 video codec, considered by many to be the most versatile video codec currently available, but also provides a higher level of control when defining a conversion than any other video transcoder currently available. In combination, these two points, and especially the latter, make HandBrake the application of choice for thousands of people around the world. Check back often for my next article, which should go live within a day or two, and for the next installment of this article when HandBrake eventually adopts H.264’s successor, the H.265 video codec.

Permalink.