‘Setting Of The Month’: Bandicam’s Xvid Implementation (with Screenshots and Quality Analysis)

- It was requested by you readers! Over the first half of the year, I run a Poll here at the Blog (it is located on the top right panel area) and currently, the single most popular Requested Topic For Future Posts is “Tips and Tricks of Video Capturing and Editing”. Therefore, as part of answering that call ‘by popular demand’, by my respected readers, I want to share as a ‘Tip’ what settings I have been using of late to capture – not to tell you ‘what to use’, but to simply give everyone a suggestion – perhaps even a place to start from, when recording or editing their gameplay adventures.
- I see ‘settings’ asked about a lot, everywhere. Whether it is in game forums, technical forums, video editing and recording application forums, or even in my Inbox once in a while, people are constantly asking what settings to use, or “what settings do you use” – and that’s great! I’m glad to see helpful replies of others (and sometimes short explanations on how someone is using a specific setting and why). As anyone who has asked me directly knows, I enjoy helping others with suggestions on settings and usually try to explain why I am using one setting over another.
This Month’s Featured Setting
![]() |
Bandicam’s Xvid Codec |

If you’ve were computing through the 1990’s, you may have heard about the Xvid codec. A competitor to the DivX codec around the turn of the millennium, I am actually going to skip over the history of the Xvid codec [other than this one paragraph]. Parts of such history may actually be a ‘dark affair’ (depending on who you talk to), worthy of it’s own short documentary, as the DivX vs XviD history has some aspects in common to the history of other products and companies that were popular over time [with Saturday Night Television Specials such as “Apple vs Microsoft”, “Xerox vs Apple” and more..]. As with many companies and products in popular use today, they all have “Origin Stories” that you won’t find on The Internet and never will… And Now, Back To Your Regularly Scheduled Program
The Xvid codec is a version of MPEG-4 (it is MPEG-4 Part 2 or “H.263/ASP”), so it is directly related to it’s younger-but-bigger brother, AVC (which is MPEG-4 Part 10 or “H.264/AVC”). As such, Xvid [ASP] does not have many of the functions that are found in H.264 [AVC], such as Deblocking, where the codec will try to ‘hide’ some compression artifacts that occur due to over-compression; but Xvid is still a great codec to record with, it’s main strength being speed. Because it doesn’t have many of the processing functions of it’s more recent and bulkier MPEG-4 versions, it can ‘figure out a frame and save it to a file’ very quickly – which is essentially what is happening, technically, when game recording.
Recording with Bandicam’s Default settings for their implementation of Xvid [designated herein as “Xvid(b)”**, to show that it is the “Bandicam-Optimized Version of Xvid”] will give you a Quality Setting of 80%. The capturing framerate, by Default, is set at 30 fps (Frames-Per-Second). The audio format, in this Default setting, is compressed “MPEG-1 Layer 2” format (MP2) for the Audio. Here is a screenshot showing what all of Bandicam’s Default settings, for their implementation of Xvid, looks like in one image:
![]() |
The ‘Setting Of The Month’: Bandicam’s Version of Xvid, included with Bandicam (Default Settings) Click to see Full Size |
Below, are a sampling of a handful of games and the framerate performance hits that were seen while recording with these Default Xvid(b) settings (i.e. the differences between ‘playing the game and not recording’ versus ‘playing the game and recording at the same time’):
table.tableizer-table { border: 1px solid #CCC; font-family: Arial, Helvetica, sans-serif font-size: 12px; } .tableizer-table td { padding: 4px; margin: 3px; border: 1px solid #ccc; } .tableizer-table th { background-color: #104E8B; color: #FFF; font-weight: bold; }
Recorded Game Title | Resolution | Performance Hit (Δ) |
---|---|---|
Hitman: Absolution Benchmark | 1366×768 | ~ 2 fps |
Hitman: Absolution Benchmark | 2560×1440 | ~ 4 fps |
FurMark (Full Run) | 1366×768 | ~ 2 fps |
FurMark (Full Run) | 2560×1440 | ~ 0 fps |
Unigine Valley Benchmark | 1366×768 | ~ 6 fps |
Unigine Valley Benchmark | 2560×1440 | – |
Batman: Arkham City Benchmark | 1366×768 | ~ 4 fps |
Batman: Arkham City Benchmark | 2560×1440 | ~ 9 fps |
Skyrim (Introduction) | 1366×768 | ~ 0-8 fps |
Skyrim (Introduction) | 2560×1440 | – |
Minecraft | 1366×768 | ~ 0 fps |
Minecraft | 2560×1440 | ~ 0 fps |
table code created by Danny Sanchez (journalistopia.com)
As you can see in the table above, the difference in framerate between ‘Playing’ and ‘Playing While Recording’ is very minimal [the performance ‘drain’ being accentuated in higher resolutions for most games]. Although only a handful of games were tested, I did try testing both spectra of resolutions possibly in use by the average gamer today, by recording with an ‘enthusiast’ resolution (2K/1440p) as well as a commonly-run laptop/notebook resolution (1366×768) which could also be run by older or less-capable systems. Bandicam’s optimized Xvid performs very well in the tests, with almost as low of a performance change as the ‘super-light-performance-hitting’ MJPEG codec.
Like MJPEG however, Xvid’s weakness is the lack of tools to compensate for compression. Again, I mention here the MPEG-4/AVC ability to somewhat ‘hide’ compression artifacts, with code for utilities such as “Deblocking” built into the codec, where the edges of areas that the codec is making its calculations in are ‘softened’, so that the ‘blocky’ effect of high compression (called Macroblocking) is less visible. In Xvid, there is no such utility, so if too high a compression level is attempted [too low a bitrate is stipulated], then these ‘block’ artifacts can easily be seen, especially in ‘flatter’ areas of a frame (portions of the screen with less color and/or changes happening), as seen in the below frames, extractions from the actual recorded video frames themselves:
[In the examples below, when the compression artifacts aren’t as obvious, I will show the entire screenshot in compressed JPG format, then underneath I ‘zoom in’ to show the compression artifacts from the codec as magnified extractions from the original video frames, in BMP (BitMaP) format. I use sampled areas for that, as full 1440p Screenshots in an uncompressed format would be over 10MB each]
![]() |
Xvid(b)** at 90% Quality [altered from Default 80% Quality Setting], Battlefield 3. Click to see Full Size |
The result when recording at 90% Quality (up from the Default of 80%) was very satisfactory, with only ‘nit-pickable’ parts to show the codec’s weaknesses, like the Upper Left area of this scene above (with the dark interior areas). Some artifacting can also be seen in the Middle Top area (slightly obvious even in this compressed JPG), where the plain sky areas take the brunt of the compression of this frame taken from the original game recording video produced by Bandicam.
|
Xvid(b)** at Bandicam’s Default of 80% Quality, Battlefield 3. Click to see Full Size |
The above image is taken from a game recording of Battlefield 3 that had some pistol action going on, with an explosion caught in the background. The quality of Bandicam’s Default setting isn’t too bad and high action scenes can actually look quite acceptable. For example, in this frame above, with the explosion occurring on an upper walkway, only the Right Edge of the explosion (with the debris) has obvious Macroblocking – and the sidewalk [and foliage] macroblocks had to be ‘looked for’ here – and are less noticeable in the moving video. The ‘flatter area’ (with less colour variations) in this scene, is the poster advertisement, which the codec punishes with compression, leaving colour banding and macroblocks evident. The rest of scene is more complicated material and demands the codec to utilize more bitrate, ending up looking not too bad at all, when VBR is used (Variable BitRate, “changing data rate”) mode).
|
Xvid(b)** at Bandicam’s Default setting for Xvid of 80% Quality, the Batman: Arkham City Benchmark. Click to see Full Size |
The above image is an extracted frame from a recording of the Batman: Arkham City Benchmark. A very difficult scene for any codec (unless you tell it to ‘keep all quality, use 100%’ and then don’t mind the larger file size that will be created) it is hard for a codec to decide what to compress and what not to, as particles fly all over the place and light and dark areas shift around as the Benchmark runs through this area with changing levels/regions of Luma [lightness, brightness]. Bandicam’s Xvid did a good job trying to keep the text sharp at 1440p – but at 80% Quality, macroblocks are everywhere (those present in the screenshot above are not from the JPG compression, they were present in the game recording itself). At 80% Quality, anything with subtle gradient colour changes are absolutely tortured by the codec, seen especially in the change from light to dark in the Center Top light fixture area and the Left Lower curtain region. Bright areas however, such as the light fixtures themselves and almost all of the particles flying around, are judged by the codec to be ‘important to human eyes’ and detail is kept high for those objects.
|
Xvid(b)** at Bandicam’s Default setting of 80% Quality, Minecraft. Click to see Full Size |
The above frame is taken from a recording of the Minecraft Demo starting shoreline, originally captured at 1440p (the image is resized down to 1280×720). I was interested in how Xvid would handle Minecraft, a difficult game to capture and compress, as hard edges and lines are everywhere. Bandicam’s version of Xvid did surprisingly well, as the video recording itself is a joy to watch, with compression artifacts barely noticeable (recording at higher resolutions helps with that, but uses more disk space for the game recordings). Magnification of the original video frame is just below (next image):
|
These two sampled regions are magnified to 200% (doubled in size). They were extracted from the game recording frame above, which itself came from the original game recording produced by Bandicam and the built-in Xvid codec. Click to see Full Size |
Regardless of some of Xvid’s compression shortcomings illustrated above, with the speed that it performs at, along with the ability to turn up the Quality setting in Bandicam, these artifacts shown will not occur as often in higher quality settings – and then Xvid can be a nice codec to run with, especially if a system cannot handle a codec that does higher processing on the frames [taking more time to do calculations on them and saving them to a file, creating ‘lag’]. Older systems or laptops that do not have the hardware to utilize GPU-accelerated game recording (with codecs such as NVIDIA’s CUDA and NVENC, AMD’s App Acceleration and Intel’s Quick Sync) can utilize Xvid as a less-taxing codec to record with [as another option on the Utility Belt of Game Recording Codecs to choose from]. Indeed, it is almost as speed efficient as the ever-compatible MJPEG codec, for capturing, editing and compression.
![]() |
Although originally captured for an article on the Xvid codec here (which can potentially also experience the issue mentioned in the above paragraph) this image shows an example of what the “trails” or “glitchy-ness” will look like, as it was captured from a video with a Large GOP (large keyframe interval) output produced by Vegas. (Click to see Full Size) |
When editing a video with a large GOP, the video editing application must ‘seek’ to the next Keyframe whenever it has to process a request and calculate/build all of the frames from there (which slows things down and delays processing and editing). Also, depending on the application, with some programs video can only be ‘cut’ on keyframes (unless an application is coded to create keyframes where needed). All of these steps and problems created by ‘Long-GOP’ video can be avoided [when using the above-mentioned video editing programs] by simply adjusting the Keyframe Interval in the Xvid settings to “1”.
One caveat to keep in mind, with setting a Keyframe Interval of “1”: although it will now make for speedy/easier/morecompatible editing with many video editing applications, the codec will not have as much ‘headroom’ to work with, when compressing your game recording material.
What this means is, that instead of only keeping track of the changes between frames (say, a person running by down the side of the screen), where the codec will literally only save those ‘differences’ in the file; it now has to save every single portion of the viewable screen in every single frame, complete and independent in ‘stand-alone’ frames (the KeyFrames), and while the video will be much faster in seeking and have increased editing compatibility, the codec requires much more bitrate now, to save ‘everything’ in every single frame.
The result: your video file size will end up larger than before. However, you can now edit the video in Vegas, Premiere, Lightworks and more… the choice of how to go about this aspect then, is up to you [whether to use a GOP of 1 for easier editing, or not]. If you do not use these specific video editing programs (perhaps instead, you are using PowerDirector or VideoStudio Pro or Movie Maker, which to not have as much trouble with ‘Long-GOP’ material, not needing the GOP to be one frame) or you are not having problems with whatever editor you are currently using, there is no need to make this change to the Xvid recording settings in Bandicam [this is why there is no green indicator arrow in my ‘Suggested Settings’ illustration coming up in a little while, for this option]
Recorded Game Title | Resolution | BitRate (Mbps, GBph) |
---|---|---|
Hitman: Absolution Benchmark | 1366×768 | ~ 34 Mbps, 0.97GB/hour |
Hitman: Absolution Benchmark | 2560×1440 | ~ 83 Mbps, 2.4GB/hour |
FurMark (Full Run) | 1366×768 | ~ 44 Mbps, 1.2GB/hour |
FurMark (Full Run) | 2560×1440 | ~ 45 Mbps, 1.2GB/hour |
Unigine Valley Benchmark | 1366×768 | ~ 37 Mbps, 1.06GB/hour |
Unigine Valley Benchmark | 2560×1440 | – |
Batman: Arkham City Benchmark | 1366×768 | ~ 20 Mbps, 0.57GB/hour |
Batman: Arkham City Benchmark | 2560×1440 | ~ 54 Mbps, 1.5GB/hour |
![]() |
Comparison between varying Quality settings, for Bandicam’s version of Xvid (from Left to Right; Quality at 40%, 60%, 80% and 100% Quality). The JPG compression used for this composite [the four videos side-by-side] did not overly affect the Macroblocking occurring – the ‘blockyness’ seen in these frames is almost untouched, even though the videos from the original Unigine Valley Benchmark recordings were converted into this JPEG image – this is very close to how it looked in the video (although slightly more noticeable as still images). Click to see Full Size |
![]() |
The ‘Setting Of The Month’: Bandicam’s Version of Xvid, included with Bandicam (Suggested Settings): Quality is at 90%, PCM (“Uncompressed”) Audio is selected [mainly for editing compatibility], a higher compression (“Smaller file Size” option) is chosen (and a Keyframe interval of “1” is suggested for compatibility with editing applications such as Vegas, Premiere, Lightworks, etc. if required [only change if needed as it increases file size, no green arrow indicator is shown on the Keyframe Interval]) Click to see Full Size |

Personal Short Version/Opinion:
Last Remarks (in addition/continuation to the Prologue of this article):
Another thing to keep in mind is, that my settings (both for Recording and Editing/Rendering) change slightly over time… I may have been able to purchase a new disk drive recently for instance, so then I will allow my recordings to take up more space [for a while anyway]. I may be trying out a Demo/Trial of a new version of a Video Editing Application, so I have been experimenting with some different Rendering settings. Perhaps a videocard driver or codec was updated, so now I will experiment a bit with the recording application settings, seeing if I can squeeze a little more Quality out of my recordings, while keeping the Performance high. All of these reasons and a few more, are why my settings constantly change over time. Don’t worry, I’ll try to remember to come here and share them with you, anytime I find a “Good Combination” that works well for either High Quality or Fast Performance, the ‘Holy Grail’ of course being a Perfect balance of both.
As I have begun more dedicated testing over the past few years, I have found that specific games themselves ‘prefer’ certain recording and rendering settings over others. What I mean by “prefer” is: as new game rendering engines are written, hardware architectures change, and programmers utilize ‘something over another’ in general during a game’s development, this affects what settings a game ‘works better with’, whether it is a specific game recording program, hardware/GPU, or specific recording and rendering settings; hence my usage of the word “prefer”.
This is why, for example, some games will perform better on an AMD/ATi-based videocard in Benchmarks and Reviews than an NVIDIA-based GPU – and then other games will have better results on an NVIDIA-based videocard over an AMD/ATi-based GPU – those games were simply being developed [the programmers wrote the code] on a system with that certain GPU installed in it at the time. This also means there is a chance of specific optimizations in programming that slightly favour one brand of GPU over another [and they may even have been ‘compensated for their efforts’ by that respective company, but *shhh* these things aren’t spoken of outside Mordor].
In regards to the above and game recording, I have found that some games will have better performance with different game recording applications as well. For example, one game may have less of a performance hit while recording with Dxtory and then another game will have better performance recording with Bandicam [as an example] – it all depends on the code and how it is written and being rendered. That’s why I ‘change it up’ so often, altering my recording settings (and rendering settings) as each game I play exposes its nuances. That’s what I mean if I ever say a game ‘seems to prefer’ recording with one game recording program over another.
Keep this all of the above in mind then and also remember dear reader, that I am never telling you “you should use this”, I am always suggesting only a possibility in my posts, and it is always up to you to try it out and decide if you want to use a recommendation of mine or not.
[I encourage everyone to always take the good ideas from others and leave the bad, making up a composite of their own liking and preferences and what they want to utilize – whether it is with game recording and editing, or Life In General – but, that last part is for another blog…]
+-+Chinatown+Celebration+with+Duck+-theGTAMblog+.jpg)
**[designated as “Xvid(b)”, to show that it is the “Bandicam-Optimized Version of Xvid”]