TestRun, Video Edition: FRAPS vs DXTORY vs BANDICAM vs PLAYCLAW (Game Recording Comparison I)

Greetings, in this edition of the TestRun series here at The Game Tips And More Blog, we are going to be looking at comparisons between game recording applications and their output. There are many programs out there and everyone has their favorites for differing reasons; but for this article we are going to focus on four of the more popular game recording programs (there are many more, to test in the future..).

The Experiment

For many people, Quality and Filesize are the two Rock'em Sock'em robots in the ring at all times. Whether you edit videos, archive, convert, or just record vacations or games, these are the two concepts you probably fight with constantly. What is the best quality I can get, you might ask? What is the smallest file size I can produce, while the quality is at least something I can tolerate, or share with others? These questions are going to be answered visually in this TestRun, where we are going to be looking at the most common Presets, Defaults and Specific Settings of four game recording applications: Fraps, Dxtory, Bandicam and Playclaw** - and see how each one looks compared side by side - and how big the recordings are for each.
 [**Playclaw was Trial Limited in Quality at the time of this test]

The Test

For this TestRun, the game used is Minecraft. Yes, MC isn't exactly 'high-end-tessa-shadow-bump-mipped', but that's the point. Without taxing the CPU/GPU extensively, more of the power can go towards recording and getting the most 'bang-for-the-buck' from the game recording apps. Also, the sharp edges and movement of groups of pixels, along with solid colors and dark areas, are a good test of compression and will bring out any artifacts that the contending codecs might sweat out.

Options within the game are going to be maxed out (Far Distance, Advanced OpenGL, etc.) and video card settings for Antialiasing and Filtering are going to be either 'Off' or 'Let The Application Decide' (Minecraft doesn't seem to have AA within the game at this time). With these settings, I chose one spot in The Nether that shows both light and dark regions on the screen, high detail distant blocks and lots of smoke/movement within view.

The system running the test is a Desktop system with a six-core AMD CPU and AMD/ATi Radeon 6870 GPU. The system was slightly tweaked to give Minecraft more performance, as 8GB of RAM was on the system at the time and Minecraft was set to utilize 3GB of it with a 64-bit Java startup script and the game itself was running off of a 1GB RAMdrive.

The Data

Here is the resultant video comparing each program and the output that was recorded at each setting mentioned within. The same areas are compared and show the quality and compression between each recorded segment. The size of file produced for each recording is also noted within the Batch portions of the video, on the right hand side:

Recorded with:  Fraps, Dxtory, Bandicam, Playclaw
Resolution:  Slightly higher than HD @ 1920x1096, (Maximized Window @ 1920x1200 Desktop with doubled taskbar), resized to fit into 1920x1080 (1080p HD) video rendered as final video output for upload
Recording Time:  10 seconds or 300 frames, attempt made to record from same location for each segment
Recording Size:  Varies, sizes are included in the video for each recording segment
Codecs utilized:  MPEG, MJPEG, UTyuv422, FRAPS1, various quality settings for all

In general, the recorded segments in the video comparison are shown in order of largest disk space usage per second to the smallest.

The absolute largest file produced when recording the ten second test was Dxtory's High Quality setting, even with Compression turned on. At a whopping 873MB for the 10-second video, data was being streamed into it at over 700Mbps. The recording however, has amazing detail with crisp edges and clear colours. The apparent negative effect on the system was just as large however, taking a 60-100fps game view, without movement, down to about 25-30fps while recording.

Dxtory's Low Quality Preset (with Compression option on) in The Nether, Minecraft. Nice and clear, the Dxtory Codec Medium Quality and High Quality settings all look just as good. Click to see Full Size.

At almost the same weigh-ins; the UT video (YUV422) codec, Dxtory's Medium Quality setting, Playclaw's No Compression setting, and Fraps' Full Size default setting all produced a hefty recorded file size hovering around 500MB. The result for all of them though was a nice, clean video - except for Playclaw, which apparently was restricted to a 1024x576 resolution, that of course resulted in a blurred recording when compared to the other full-size recordings. This is no doubt merely a restriction in the Demo version however and the full/purchased version of Playclaw should be quite capable of the bitrate (and therefore quality [and disk space usage]) of the other applications for game recording.

Fraps screenshot of Minecraft (The Nether) at Full Size. Crisp and clean. Click to see Full Size.

The smallest file sizes produced were all from Bandicam. At various settings and Bandicam's suggested Presets, it produced small file sizes from 100MB down to 10MB, with data streams running at 80Mbps down to 8Mbps. The smallest file produced during these tests was the YouTube480p/Quality80 setting. Unfortunately, although 80% Quality is nothing to sneeze at, when the resolution recorded is only 854x480, 20% detail loss is quite a bit of pixel casualties and the darker areas were noticeably blurry and flat, at least for a game that has large areas of solid colours/pixels, as those areas were compressed more by the codec and they lost finer detail/edges. The 100MB file was from the 'editing-friendly' Vegas/Premiere/Pinnacle setting, which looked pretty clean despite the small file footprint.
[Recording at a higher resolution helps, as compression artifacts will 'seem smaller' as they 'take up less space' on the screen.. See below for some explanation on compression artifacts]

Bandicam's 'Vegas/Premiere/Pinnacle' (editing-friendly) Preset. Screenshot in The Nether (Minecraft). At 80% Quality, some common JPEG issues are lightly seen if looked for: slight chromatic aberration (color leaking at some edges) and some flattening/smoothing of distant, dark areas; but overall still a good quality screenshot/video, especially when it is considered that the file size of the recording was 1/4 the size of most other recordings and 1/8 the size of the largest.

Here is the 4x4 (16-Video) comparison key (it is in order of largest file size produced to the smallest):

A - Dxtory High Quality w. Compression
B - UT video codec YUV 422
C - Dxtory Medium Quality w. Compression
D - Playclaw NoCompression [Trial Version Limited Quality]
E - Fraps FullSize
F - Dxtory Low Quality w. Compression
G - Bandicam MJPEG Quality100
H - Playclaw LowCompression [Trial Version Limited Quality]
I - Fraps HalfSize
J - Bandicam MJPEG Quality80 'Vegas/Premiere/Pinnacle' setting
K - Bandicam MJPEG Quality60
L - Playclaw MJPEGcompression (6 threads) [Trial Version Quality]
M - Bandicam MJPEG Quality40
N - Bandicam MPEG-1 Quality80 'Default' setting
O - Bandicam MPEG-1 Quality80 'YouTube720p' setting
P - Bandicam MPEG-1 Quality80 'HalfSize' setting

When looking at the 16-video comparison, where one section of wall is zoomed in on, the upper tiers are the high-bitrate, large-filesize recordings. The bottom rows are the lower-bitrate (but in most cases Full Resolution) samples. Of the lower sections, segment N seems slightly more 'crisp' among the lower bitrate/compressed crowd. This is Bandicam's Default Preset. While great at saving disk space, it should be noted that if instead of simply recording-and-uploading somewhere, if you plan on doing editing of the video in most editing programs, MPEG-1 isn't the easiest editing codec to work with. This is why most programs offer the ability to choose other codecs, such as MJPEG and YUV subtypes. With these codecs, all frames are recorded independently of each other (so seeking/editing is easier/faster) and they are compressed on a frame-by-frame basis (they are literally a series of JPG pictures, in the case of MJPEG).

The way most MPEG codecs work by default (whether it is a DVD, XviD or h.264/AVC), only the differences between frames are kept, to save space. This means that when seeking within the video for editing, the program must calculate the frame desired by using data from nearby frames, increasing overall editing/seeking time. It is possible to do, only editing these codecs may be slower than using other codecs (such as MJPEG and YUV codecs, for example) which are more 'editing-friendly' by having frames that do not rely on other frames ahead/behind.

As expected, the 'lossy' codecs produced compression artifacts and showed detail loss for areas with low movement and colour. This is to be expected and is one aspect of digital compression, which allows file space usage to be saved when working with video (and the same concept applies to audio); for lossy codecs, areas that have less movement or are black/dark will be compressed more, so that more data per frame can be used in areas that are more complex, such as high-movement areas, edges and keeping fine detail (if told to do so in the codec settings). The higher bitrate codecs, taking up lots of disk space (utilzing lots of data per second/per frame) kept much of the data and video quality from the video input. It can be seen however, that modern lossy codecs (coupled with the processing power of modern computers) have made great strides in apparent detail vs. file size, as even the smaller-sized recordings such as Bandicam's output appear quite viewable in terms of detail, despite the compression involved and small file size of the recording. This is great of course, for gamers and video editors/archivers.


Here is an example of codec compression at work:

Codec Compression Example Still Frames. [Blogspot has resized it down, but details/example is still evident.]
Click to see Full size.

All three samples are 1000x640 screen areas starting in the upper-left quadrant.

Fraps, a high-bitrate codec, is on the left. Even with so many solid edges to attempt represent, and with the moving 'smoke' from the game (pixellated grey shapes in foreground), the high data-per-second allocated to the frame keeps almost all of the detail and crispness of the hard-edged rendering of this game frame. The resultant video, a 10-second recording, is 470MB.

The middle portion is the same view, but taken from a recorded video that utilized the MJPEG codec, with it's Quality setting at 40%. Obviously, a lot of data is going to be lost at this setting, and the detail is going to suffer, but this is done on purpose to show an example of how a 'lossy' codec [COmpressor-DECompressor utility] works and looks. The codec has calculated to smooth out much of the middle area that is darker, as less data is needed to represent it and the result is large, flat, brown/grey areas. In an attempt to represent the hard edges of the 'smoke' from the game, the codec's mathematical calculations has output visual compression artifacts [due to the limitation of the data throughput i.e. the bitrate or data per second] known as "Gibbs Effects" or "Ringing" or "Mosquito Noise", the lines seen around the grey edges of the smoke. All of these compression artifacts are commonly seen in both MPEG video and JPEG picture compression (the effect is exaggerated here for educational purposes). The resultant 10-second recording at this setting is 45MB.

The far right example is again the same view, taken from a recorded video that used the MJPEG codec, but with it's Quality setting at 100%. At this setting, the codec will attempt to keep as much data as possible with no regard to the file output size. As can be seen, the frame is almost identical to the [first] high-bitrate frame, with only slight Chromatic Aberration (colour 'leaking' at the edges/fringes of areas) seen in the 'smoke', for example. The resultant 10-second recording at this setting was 396MB. [At about four times the size of MJPEG at 80% Quality, this setting was utilized merely for example purposes]

The Conclusion

As you can see, there are visible differences between the various programs and the codecs they employ. For the most part it was very simple and expected: the higher settings (higher bitrate, higher resolution) produced superior results over the lower settings/options - albeit at a cost - the space taken up by the recorded files.

This TestRun is a basic example of the weighing that must be done with video recording and editing; questions like "How much quality do I want to keep" vs. "How much space do I want to use up for the recordings". With disk space becoming increasingly larger, this decision is not so important as in the past, but it is a good idea to consider it when looking at how your game recordings are going to turn out.

In general, the formula-that-has-always-been is the same: if you want higher quality, you must use higher-bitrate recordings (more data-per-second) and you will have to work with larger output file sizes. If you want to save disk space, or have a system that cannot handle high-bitrate recording and video, then you must use lower settings and will be able to work with smaller file sizes overall. The balance between these two is the main consideration.

What's the answer? What's the Best Settings? The 'real' answer is that it is different for everyone. For those still reading, what I mean is, is that what one person likes in regards to detail, another person will say it looks bad. Like food, it comes down to personal preference, capacity of the organs involved, and the tools that will be used. Let me explain.

If you are rendering your video out to someone with a PSP or 14-inch CRT TV to watch on, the lower-bitrate/lower-resolution recordings will be fine, as the presentation tools do not have the capacity for showing very fine detail. If you are going to be inviting friends over and watching your gaming experiences on a 50-inch flat screen, capable of high definition and crisp picture, using a low-bitrate/low-quality/low-resolution recording will show up as 'blurry', with less detail, (and may even be less enjoyable to some people).

The next consideration for game recording is the system involved. Perhaps you are using a laptop. Even if it is a desktop system, can it handle recording the screen and pushing all that raw data to a video file without slowing down and becoming too 'laggy'? If not, then try to lower some settings within whatever program you are using, try to lower settings within the game itself (resolution, shadows, special effects, antialiasing, filtering, etc). These things will help a system with less power and capability (especially on newer games). There can be other issues/considerations as well, take a look at our Tips For Game Recording article here:
http://gametipsandmore.blogspot.ca/2012/05/tips-for-game-recording-currently-text.html

Since all of the programs tested were quite capable of recording detail, as well as having settings to save space (or utilize various codecs to do so); the end answer is really for you, yourself, to watch the videos, record your own, do some tests with different settings and see what you think 'looks good enough' for you to watch, while keeping down the file size and processing power usage. Once you find what you are willing/like to record at, then that's one less thing to worry about, and you can start recording and enjoying playing the game - and isn't that the main thing?


Have fun testing and making your own personal decision!





Personal Short Version/Opinion:

As stated in a previous article, an issue for me is hard drive space. I have Terabytes of space, but it is usually filled up with games, screenshots (literally tens of thousands), video recordings and editing projects. When it comes to game recording, I personally balance out recording time/space usage while trying to keep decent quality (I notice, but do not need 'perfect quality').

Here's how I break it down (no pun intended):

If I want 'awesome' quality for a project or for someone else, I would use any one of these programs and put it on the highest setting my system can handle without getting too laggy. Myself, I would use Fraps*, or to save space and record longer, Bandicam at a 90%+ quality setting.
*At the time of this post, Fraps has an issue with video and audio being out of sync for long recordings for many people

If I want 'good' quality, I would personally use Bandicam with a 80%-90% Quality setting, Full Size (recording the full resolution the game is being played at), MJPEG codec (for easy editing) and uncompressed PCM audio (for easy editing). The 'editing' preset ("Vegas/Premiere/Pinnacle") is easy to just click on and I find that the video always looks fine, and from sharing gaming experiences with others, they think it looks fine too.

If I want 'ok/good enough' quality, I will record at lower resolutions (as opposed to lowering the quality of the recording), such as recording at 720p, 900p or even half-size, while playing at a larger resolution like 1920x1080 (if I want the in-game experience to look better to play in). 
I would probably not lower the actual recording Quality much more than 60% no matter what codec I was using and would rather lower the recording resolution to save disk space while still having the recording be 'decent quality'.

The reason for not lowering the % of the quality too much is that the compression artifacts/loss of detail is quite a bit when lowering the quality past say 60%, and when compressing the recorded file to another format/output to share with others or upload to video sharing sites, the artifacts and 'blotchyness' from setting too low a quality is actually kept within the final end video. Even if you use some filtering, some of those 'icky-goopy-looking parts' will be present in the end result! 

What then, is my suggestion for an older system?

If the computer can handle it, I suggest not going below 60% quality, no matter what recording application you choose, as I feel the quality of the recording becomes far too low beyond that. I would then suggest lowering settings on the video card (like filtering and antialiasing) or settings within the game itself. Playing at a lower resolution like 1280x720 instead of 1920x1080, or turning down effects like shadows and particles will all help the game to run smoother on a less-capable system and the recording will run smoother then, too. See our article in the link at the bottom of this post for Tips on Game Recording.

As with all advice I give, do your own tests to make your own decision on what balance/trade-off you want to go with, but I hope this information has helped you. Have fun with it!

For an in-depth look at [only] Fraps vs Dxtory vs Bandicam, the codecs they use, options the programs offer, apparent 'lag' effect on the system when recording and more, visit the TestRun, Quick Edition (text-only) on them here: http://gametipsandmore.blogspot.ca/2012/05/testrun-quick-edition-fraps-vs-dxtory.html 

For tips on game recording and how to improve performance:  http://gametipsandmore.blogspot.ca/2012/05/tips-for-game-recording-currently-text.html

See you in the games!

» Look for an upcoming TestRun, Video Edition which will have a 'Redo' of PlayClaw (with their updated demo that allows higher quality) and include some newer Game Recording Apps, 
such as Mirillis' Action, OBS, SmartPixel and more!

[N.B.: I am not a developer for, nor affiliated in any way with any of these programs or companies]