This article is a Text-Only version, showing how to use a few programs (one of them completely free) to utilize this efficient codec in game recording, using steps and settings that I personally found optimized performance and showing which ones slowed things down when recording.
For a video example of how to set the x264/AVC codec recordings to be editable in
Sony’s Vegas or Adobe’s Premiere video editing applications, see my post about it here:
The MPEG-4 video codec has been around for over a decade now. I remember recording TV shows to watch later on, on a system with an ATI All-In-Wonder videocard (back when videocards had only 8MB of VRAM!) and the joy of the changes I was seeing, going from compressing the shows in MPEG-2 format to MPEG-4 using either Quicktime or DivX (or it’s open-source competitor, XviD). Smaller file sizes and still decent quality? Awesome. Those were MPEG-4 Part 2 or ASP (Advanced Simple Profile) iterations of MPEG-4. Today, we are up to MPEG-4 Part 10 or AVC (Advanced Video Coding) and great times are to be had by all who record their video game adventures, as modern hardware and capturing apps allow not only for h.264/AVC to be used for video compression and archiving – it can also be used for small filesize ‘live’ game recordings and great retainment of detail, if desired.
Dxtory, Bandicam and MSI Afterburner all provide the ability to utilize the various codecs installed on your system to record with (others do as well, I am merely choosing these more popular game recording apps as examples). To record with MPEG-4/h.264/AVC, it is simply a matter of installing that codec on your computer [if it isn’t already], then choosing it inside of whichever game recording app you prefer. The codec’s interface (GUI, Graphical User Interface) will allow you to change whatever settings you wish – but these settings will be quite different from what you may be used to, if you have done any h.264/AVC video compression in the past. Why?
Because we are going to be balancing the settings – not just for retaining quality at a small file size (as you would like to when archiving a movie to keep on your computer) – but now also for recording speed. For instance, if we try to set things for high compression and attempt to keep detail at the same time (as we would for archiving a movie), it simply takes too long to process and compress the changes between frames ‘on-the-fly’ and save them into a file, when attempting to record game output. This would result in the game ‘lagging’ and dropping frames to try and keep up, as it falls behind dealing with analyzing and compressing and then writing the data, resulting in a video with ‘choppy’ playback as well. So, when recording our gameplay ‘live’, we must now consider the various settings and their affect on how fast we can put through the processing of frames and writing it to a file at the same time.
I will be addressing most of the settings in the h.264/AVC codec, but not all of them. I will be concerned mainly with the ones that will slow down processing, so that things do not take too long and fall behind and cause ‘lag’, both in the game and the resulting video file itself. This differs from compressing for archiving our own movies, because instead of being only concerned with Quality (setting everything on ‘high’ and letting it take as long as it needs), we must now balance Speed of the compression as well, being now more concerned with each of these settings and how they can possibly slow things down when recording the ‘live’ game rendering. As is the nature of live recording, we want it to easily and quickly process the frames and save them to a file. I will explain how to do all of this.
Recording with H.264/AVC
“x.264” is a free/open-source utilization of the h.264/AVC codec (the XiWave GNU GPL MPEG-4 Codec). It is normally a command-line driven executable [when you run it, you type things in, to get it to do things], so what we want for game recording with these programs, is a version with an ‘interface’ so that we can just tell our apps what to do with the mouse and buttons/sliders and it translates it into commands for the codec. All we would have to do is choose a few settings and checkboxes (what most people are used to – a nice, easy, graphical user interface).
Doing a search for ‘x264+windows’, there are a few places you can get the installer/setup program for x264 and Windows, here are the main ones:
This is the “Official” Open-Source Video For Windows version of the x264 codec (Red Logo) at the time of this writing:
This official codec is what is covered in the “Easymode” sections of this article
This is an “Unofficial” x264 Video For Windows Codec (Black Logo), at the time of this post, that allows for far more settings to be edited via checkboxes and pulldown menubars, but is more difficult to use (these two links are both the same thing):
This unofficial codec is what is covered in the “Hardmode” sections of this article
Basically, you can see that what we want is a “Video For Windows” version, which (thanks to all those great people that have worked on it over time!) has a nice, easy-to-use interface for picking the settings you want to use, without typing in a long line of commands every time. After installing the codec/interface into Windows, it’s just a matter of opening whatever game recording program you prefer and selecting it to use it.
Here’s how to select it for usage in these three game recording programs:
Recording with x264 and Bandicam
- Once the codec is installed, run Bandicam and go to the Video tab and click on the Settings button
- In here, under the Video category, next to Codec, click on the pull-down menu bar (with a little triangle at the end) and choose External Codec, which allows you to use other codecs installed in your system
- Then, click on the three ellipsis (“…“) button and it will let you “Select external video codec”
- Select the “x264vfw” H.264/MPEG-4 AVC codec from the list and click on the Configure button
- This is the x264vfw configuration interface and in here are all the settings we will talk about next…
Recording with x264 and Dxtory
- Once everything is installed (Dxtory requires dotNET 4.0, a download link is on their main Download page), run Dxtory and click on the Movie settings button (which shows a little handy-cam with it’s lcd screen hanging out the side)
- Under the Video Codec category, next to the word Codec, click the pull-down menu bar (with a little triangle at the end) and choose “x264vfw” H.264/MPEG-4 AVC Codec from the list and click on the little pen icon/button to the right, which opens the Configuration dialog box of the codec
- This is the x264vfw configuration interface and in here are all the settings we will talk about next…
Recording with x264 and MSI Afterburner
- Once the codec is installed, run MSI Afterburner and click on the Settings button at the bottom
- In here, go to the Video Capture tab and under the Video Capture Properties category, click on the pull-down menu bar (with a little triangle at the end) and choose “VFW compression”, which allows you to use the other codecs installed in your system
- Then, click on the three ellipsis (“…“) button and under Compressor, click on the pull-down menu bar (with the little black triangle at the end) and choose “x264vfw” H.264/AVC codec from the list and then click on the Configure button to the right
- This is the x264vfw configuration interface and in here are all the settings we will talk about next…
» Note: To record with x264/h264/AVC and have it easily-importable and recognized properly in NLE’s (Non-Linear video Editing applications, such as Sony’s Vegas and Adobe’s Premiere lines of products [for example]) without having glitches or corruption or other problems, one setting for MPEG-4 codecs must be changed from the Default Setting right from the start. I created a video example of how to change this setting in Bandicam, Dxtory and MSI’s Afterburner and the post with that video can be found here at this blog:
To understand some of the concepts and settings utilized by this codec (and helpful information to know for game recording and video compression in general), a quick word on Bitrate:
[This section is highlighted in green headings for navigation, to assist you whether you are re-reading this article or you feel you know a lot about bitrate in video editing and wish to skip it]
Bitrate (in Layman’s Terms) /start
When talking about game recording, bitrate is an expression of the amount of data we are using to create the recorded file [literally, how many bits of information we are using]. It is usually expressed as how much information per second we are telling the codec to use, to represent the frames that are getting pushed through, and save them to our output video file.
The main thing to remember is that More Bitrate = Bigger Filesize.
For example, if we record using a 1MB per second (1MB/s) setting, then after 2 minutes of recording (120s), our recorded file size will be 120MB. At that bitrate, if we recorded for one hour straight (3600 seconds), our recorded file size will be 3600MB (3.6GB).
If we record using a larger amount, let’s say 2MB per second (2MB/s), then after 2 minutes of recording (120s), our recorded file size will be 240MB. At that bitrate, if we recorded for one hour straight (3600 seconds), our recorded file size will be 7200MB (7.2GB).
It’s that simple. The more bitrate we use, the bigger the recorded file will be.
For those used to video compression and editing, or even general users of multimedia, you may be more familiar with data rates in the realm of:
MP3 (MPEG-3 audio) song bitrates such as: 128kbps, 192kbps, 320kbps
PSP (PlayStation Portable) video bitrates such as: 768kbps, 1500kbps
DVD (MPEG-2) bitrates such as: 8000kbps, 9800kbps
Blu-Ray/HD bitrates such as: 16000kbps, 25000kbps, 50000kbps
All of these are usually expressed as Megabits/Kilobits/bits over time (in seconds), hence the “ps” at the end.
eg. 16 Mbps = 16,000 kbps = 16,000,000 bps (bits per second)
~bits (lower-case ‘b’) and Bytes (upper-case ‘B’) are different~
There are 8 bits (lower-case ‘b’) in 1 Byte (upper-case ‘B’)
8 bits in 1 Byte
8000 bits = 8 kilobits (‘kilo’, which is 1000 Bytes) = 1 KiloByte
8000 kilobits = 8 megabits (‘mega’, which is 1000 KiloBytes) = 1 MegaByte
For example, if you were rendering out a movie to upload to YouTube and you chose an output bitrate of “8000 kbps” in your editing/compression application, that is 8 Mbps (bits, lower-case ‘b’), which means 8 Megabits per second. Converting that into Bytes (upper-case ‘B’), means that video will be running at 1 MBps, which is 1 MegaByte per second (upper-case ‘b’).
At that bitrate (1MB/s), it is the same bitrate as our example above [just under where it says “More Bitrate = Bigger Filesize”] and it will take up roughly 60MB of space on your hard drive every minute of recording. Thus is the interaction between Bitrate and File Size and how to convert between the two. The higher the bitrate setting used, the bigger the output file size will be (the recording).
There is one other formula to remember: More Bitrate = Better Quality. This formula applies to almost everything digital: video (DVD/BluRay), audio (MP3/MP4), pictures (PNG/JPG), any multimedia that is digital. If you allow/use more bitrate, the picture/music/video is represented better [or to be more precise, closer to the original input] because there are literally more bits used to create the picture/sound/etc.
Quick example – think of a square that is divided up into 9 sections. Now pretend it is trying to ‘represent’ a painting, any painting you can think of. With only 9 blocks of data available (each one can only be a certain color), then it would look like nothing but some colored blocks and barely look like the painting at all. Now, imagine a square divided up into 80 sections. Pretend it is trying to represent the same painting. Even though it will be ‘blocky’ still, if each section can be only one color, it will still look ‘more like the original’ than the 9-sectioned block, right?
That’s the interaction of bitrate and quality.
Which means, for digital compression, it is essentially a ‘balancing act’ between Quality and File Size, with Bitrate being the tool to measure with. Do you want a high-quality output? Then turn up the bitrate and you’ll end up with a large file size. Do you want a small file size? Then lower the bitrate and you’ll get lower quality as well. That’s the essence of bitrate, in a nutshell.
Bitrate (in Layman’s Terms) /end
The x264 Interface and Configuration in “Easymode”
(The Official interface with red x264 logo)
With the official version of the interface for using the x264 codec (“x264vfw”), there is only one screen, with pulldown bars to adjust most settings.
The Basic Section
To start with, under the Basic category, there is a Preset setting. This is a very handy setting, which makes many of the more obscure/hidden choices within this codec (there are dozens, behind the scenes) easy to configure. By clicking on the question mark near the bottom right corner (“?”), you can see the intimate details of the different Profiles and Presets that can be selected in these pull-down menu bars within this first “Basic” section of the interface.
For game recording, we are more concerned with speed. We don’t want the codec to break out it’s magnifying glass and scrutinize each frame coming through in strict detail, because that would cause it to slow down, which will cause it to ‘lag’ behind, not only in the game, but in the recorded file itself as well (“choppy-ness”).
So, the first thing to do, when using this codec for ‘live’ game recording, is to change the Preset setting from it’s original default of Medium to “Ultrafast“. This is the fastest option for this setting.
The other options, such as Superfast, can also be used, but be aware that the more you go down the selections available, the more options are being ‘turned on’ behind-the-scenes with this codec, and while some of them do help apparent quality of the video, they are geared more towards a slow, steady, long-term compression session (like when you might archive a video/movie) with high-quality settings and slow, scrutinizing analysis of the frames. While not a bad thing, for game recording, we don’t want that. We want it to save what we are seeing on the screen fast, to a file. We want speed. Feel free to take a look and learn about the various options the other Presets turn on [many of them are covered in this article further down], but for optimal speed, Ultrafast is the setting to use.
The next pull-down set of options to choose from is Tuning. These are also a set of pre-selected options that, depending on which one you choose here, will enable or disable certain functions in the codec. These choices are helpful is easily fine-tuning the codec to compress a movie/video/clip of each certain type, as it enables options in the background that will help with efficient, detail-oriented compression of that certain type of material.
For game recording, again we are more concerned with speed. These options, while helpful in a slow, ‘leave-it-overnight’ compression session of clips or movies of ours we want to save; for live game recording we want to leave it at it’s default setting of “None“, so that the codec keeps it’s magnifying glass put away and doesn’t spend any extra time analyzing the frames coming through.
There are two checkboxes below these first two pull-down menus and they are titled “Fast Decode” and “Zero Latency“:
Fast Decode turns off a few options [behind the scenes] that help by reducing the processing ‘load’ of the video stream, such as CABAC and Deblocking [these are explained in more detail further within this article]. These are options that help keep some quality (especially at lower bitrates), but as the name proclaims [“Fast”], for optimal speed of recording we want this option “Checked“, to enable it (which will turn off these extra options for now).
also turns off a few options behind the scenes, ones that increase compression time, such as B-frames [explained later in this post] and how far to ‘look ahead’ at frames coming in, for analysis. Since we want speed
for recording our game footage and less analysis [remember, more analysis slows things down], we want this option “Checked
” to turn off the extra options that are ‘behind-the-scenes’ with this setting.
The rest of the settings in this Basic section of the interface need not be adjusted for game recording, but a good Wikipedia page, talking about the various Profiles and Levels and their capabilities can be found here:
The Rate Control Section
All of the below paragraphs between these red lines of text is the same for both the Official and the Unofficial versions of the x264vfw interface and is only duplicated for ease of reading their respective sections
The main thing in here (and really the only thing to adjust for game recording in this tab) is the longest bar right in the middle, the main datarate control and compression decision to make, is all in that one bar. I cannot even make a suggestion on what to use [ok, I can actually], since it will partially depend on what type of game you are recording, your hardware, what kind of compression you are looking for and many other factors. I will attempt to simplify it however and give a suggestion at the end. (More importantly for game recording, there is one choice that is slightly faster than all the others).
To begin, since we are going to be using x264 for game recording, we cannot use the Leeloo Dallas Multipass Options. Multiple passes (usually 2 or 3) when compressing/archiving video can greatly increase quality, but that means 2-3 times the analysis, double-checking and then further compression by the codec. Literally processing every frame twice (for 2-passes for example). That’s great when we want to keep a movie in a small, ‘as-good/high-as-we-can-get’ quality, forever. When recording games however, we want [one guess] speed. We can only accept “Single pass” as our option, because we just want the codec to see what frames are coming in, take a quick glance, and compress them into our output video file. One pass.
Starting with ABR (Average BitRate), the “bitrate-based” setting, this setting allows you to punch in the average bitrate you want to record at and it attempts to stick with it (it will go lower, but try to never go higher than what you set here). This setting basically tells the codec, “Keep within this bitrate, I don’t care if the quality goes down”, because as the bitrate ceiling is reached, it will quickly degrade in quality, as more/high movement occurs on the screen/frame. It is good for keeping within a certain file size, if that is your desire, but it also causes a bit of ‘lag’ and is not seemingly optimized for ‘live’ capturing.
CQP (Constant Quantizer Parameter) is a setting where you are basically telling the codec, “Keep this level of Quality”, and it will do it’s best to keep that level of quality for all frames/scenes. However, it will spend more time (and bitrate) on fast-motion/high-action scenes. This is good if you want to keep a movie visible clearly when a lot of things are going on, but it will also result in the higher usage of bitrate, which means larger file sizes. This may sound like a good thing for game recording (and for quality, it is), but the time spent analyzing the faster-motion scenes means that it is actually slowing down (in terms of the codec breaking out it’s magnifying glass and scrutinizing the frames that are passing by), which results in ‘lag’, both in the game and in the recorded video file itself (“choppiness” on playback).
Lossless should attempt to lose no quality, processing only very little and passing all of that nice detail directly to the recorded video output. While sounding good in theory, in practice the utilization of ‘lossless’ in x264 must be geared towards slow, analyzed video compression and not ‘as fast as we can get to avoid lag’ “live” game recording, because the result of this setting [at this time] is actually a lossy, compressed (it does not seem to go far beyond 100,000kbps), low bitrate (compared to ‘true loss-less compression’ which is much higher) capture. It does look decent, but it is also very demanding on the system and causes a large framerate drop for the level of detail that should be coming out of it [and doesn’t]. This codec does not seem to be optimized for lossless recording at this time and I do not suggest using the Lossless setting here.
CRF (Constant Rate Factor) is sort of a combination of ABR and CQP. At any given rate factor, a certain bitrate is maintained, and when the motion on the screen goes very high and the bitrate gets too high to represent what is occurring in the frame (or hits the ‘ceiling’ bitrate that it is restricted to, which can be set), then the quality begins to suffer, as the codec ramps quality down and compresses the fast-moving (“not as easy for the human eye to see”) material, until things settle down on the screen and there is slower motion (such as a person walking). Then the quality ramps back up (the bitrate staying with the specified parameters) to keep the apparent quality high to the human eye. This is how CRF is supposed to work, and it seems to do a good job of that.
Game recording with CRF isn’t as cut-and-dry as slow, long-term video compression/archiving with CRF, where it has time to figure out how to compress the fast/blurry scenes and make the slower/clearer scenes look better and change the bitrate/quantization respectively. Quantization can be thought of as ‘apparent spoilage’ of the material, where a certain amount isn’t even noticeable to most humans, and in some fast-m