Showing posts with label shootout. Show all posts
Showing posts with label shootout. Show all posts

Thursday, October 11, 2012

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]

Sunday, May 13, 2012

TestRun, Quick Edition: FRAPS vs DXTORY vs BANDICAM (Text-Only Version)


I'd like to start a series of posts called TestRun, where I test out either hardware or software applications, benchmarking where I can with utilities (such as FurMark, CrystalMark, 3dMark) and just playing and testing when there are none (such as with Battlefield3, where at this time there is no repeatable, actual Benchmarking tool, as opposed to say, other stand-alone benchmarking game utilities such as Alien Vs Predator, Crysis, or even games with demo recording playback for repeatability, at this time BF3 does not have).

This is also a 'Quick' Edition, a version of the testing and results that are text-only for now, where I may do a full version as time permits in the future, with screen recordings, graphs and other materials that I would like to share; but for now, hopefully the testing and results alone will help people out.


[Links to updates and Video Editions of these tests can be found at the bottom of this article]



The Experiment



For this TestRun then, I am pitting FRAPS against other screen recording tools, Dxtory and Bandicam.
I wanted to include MSI's Afterburner with its capture utility, but at this time I could not get it working with my Gigabyte Mainboard and ASUS videocard. Other utilites such as ZDsoft's Game Recorder only allows 60-second recordings in it's trial version and I wanted to test longer recordings, since one of the problems many people are having (including myself) is with the audio and video going out of synchronization over longer game captures *coughfrapscough*. Dxtory and Bandicam allowed unlimited trial version recording (with large watermarks embedded) so they were perfect adversaries for my purchased version of FRAPS.

Dxtory and Bandicam are both newer competitors in the game recording market, showing up in 2009 and 2010 and as such, seemed to take more advantage of modern hardware processing capabilities. For instance, both Dxtory and Bandicam offer recording compression on-the-fly. You can even choose various compression CODECs (compressor/decompressors) such as MPEG, XviD, and more. What the compression allows, is much smaller file sizes for your captures.

Fraps does a very light compression through their codec, and results in large file sizes.
Dxtory and Bandicam have configurable settings for the codec and the compression amount (how much to process the recording as you go, how small to make the files that you create) - but remember that the more compression you attempt on the data, the more you are straining your hardware to process it as you go - meaning that the smaller the output of the files you are recording will be, but the slower your system will respond while you are playing the game and recording.
Bandicam allows you to record the operating system screen itself, not just within an accelerated game, but the Windows GUI for instance, so you can create Screencasts or tutorials, recording what you are doing on the screen.
Dxtory does not do this, it will only capture the DirectX/OpenGL acceleration within a game.
FRAPS will record the gpu-accelerated interface (such as AERO in Windows), so you can record the screen like Bandicam, if you wish.



The Test



For this TestRun, I used the Crysis Stand-Alone Benchmarking Utility, the Unigine Tropics Demo/Benchmark, played Diablo2 [warming up for D3!] and some multiplayer Battlefield 3 (returning to the same server in a short period of time), since that is a nice modern game that exercises your hardware well. I also tried recording the standard Windows GUI, reading some articles and watching some YouTube videos and recording what I was doing. I am currently running an AMD 6-Core CPU and an AMD/ATi Radeon HD 6870 on a GIGABYTE 990FXA chipset mainboard. I assume this is an average-to-above-average system at the time of this writing and it could help out anyone with a similar rig in the future as well, looking for ideas on what may work for better for them.

Keep in mind, that when considering the apparent effect of lag on the system, it can vary, not only between systems but also between games. 
For systems, one person may get only a loss of a few frames, while another person can experience a much larger framerate loss, the difference usually more dependent on the system hardware. 
For games, sometimes a company programs/codes the actual game on one type of hardware or the other, then 'ports' it over/translates it [the portions of it that were not compatible] for the other family of systems (such as Intel-->AMD or AMD/ATi-->NVIDIA), the result being games then 'prefer' one or the other and will natively perform more efficiently on the former (this explains why some games will perform better in Benchmarks and Testing on one brand of architecture than the other).

[I chose these three game recording applications for now, as opposed to including PlayClaw, Xfire and others, as perusing game forii, these three seemed to be "The Big 3" programs that people were always talking about, suggesting, and using in their game recordings. They also all allowed Unlimited Recording Times, since I already owned Fraps. In the future, I hope to do a larger TestRun of all of the currently available screen recorders I can find and create a nice Review of them all!]



The Data



FRAPS:

Game recordings from this Australian Heavyweight Champion, as everyone already knows, are huge. One minute of in-game recording at 1680x1050 [the current limit of my monitor at the time of this writing] was over 4.5 GB. That's a total filesize which will take up more than a DVD. For 1 minute. The data stream average for the video overall was about 550Mbps, meaning that it was writing data at about 70MB/s to the harddrive [on a drive that can handle up to 150MB/s]. That means, that recording an hour of gameplay (beginning a long session, or an average Conquest match in BF3) would be well over 250GB of data.

The thing with Fraps recordings however, is that the Quality is superb. It almost is WYSIWYG (What You See If What You Get), but the file sizes show that as well. You could not record days and days of game time and edit it all up at the end; at least not at Full Resolution, playing at 1080p or higher, unless you had the hard drive space to deal with it all.

Another issue with Fraps is that is very demanding on the system*. Because it is powerdumping huge amounts of data onto the drive, it strains the colon of the system bus with its girth, filling all bandwidth with video and audio data, taxing the CPU and RAM as it traffics it all, even though it is only very lightly processed.
End Result: your entire rig (especially if older) is slower in response to pushing this huge amount of data around and hence the many complaints about 'Fraps lags the game' on forums everywhere*.

*[Note however that this does not happen to everyone and not on all games]

I found that playing Battlefield 3, on a 64-player map, while recording with Fraps, my framerate drops from 70fps down to 30fps, even with "Lock Framerate While Recording" not toggled on. The same thing happens with Skyrim. The resulting videos are smooth and look great though, they are just...big.

There is not much that you can configure with Fraps. You can change the framerate (to whatever your system can handle) and record in Full or Half resolution (for instance, if you are playing at 1680x1050, your recordings would be at 840x524), if your system cannot record at your full game size. You can also simply lower the in-game display to something smaller, like 1280x720 for easy editing and upload without having to resize if you are sharing your videos at that resolution anyway. this also helps if the strain is too much for higher resolutions.
[These two 'tips' above will also help anyone experiencing lag or slowdown or choppiness while recording during gameplay]

You can record multiple sound inputs, if you are doing a game commentary for example, and there is a built-in "benchmarking" utility, where it will keep track of the in/out/average frames per second and output that to a file, if you want to do some testing.

I purchased Fraps long ago, when it was the Go-To app for game recording and benchmarking and in many ways it still is; however through recent system upgrades (from a single core to a dual core and now up to a six-core processor) Fraps seems to have another problem - audio and video desynchronization: the sound doesn't match what you see on the screen, getting worse and worse out of time with the video the longer the recording is. As my older system (for instance, the dual-core) does not experience this, I assume it has something to do with the hardware and calls that the application is/is not making. Not being a developer for Fraps, I do not know exactly; but without fixes in future versions, many people (not all, only the ones experiencing this problem) are going to be looking for alternatives to this classic and wonderful veteran program, origin of the phrase "FRAPS, Or It Didn't Happen!"™.


DXTORY:

Dxtory is a challenger from Japan, touting faster movie capture and distributed hard drive writing (taking turns over different drives, so that it lightens the strain on all of them by sharing it, if needed) as it's battle weapons. Highly configurable, you can actually use most Codecs that you have installed on your system, finding the best one that may work for your setup. It comes with its own Dxtory Codec as well, a high quality adversary for the Fraps codec.

One minute of recording at 1680x1050, with the High Quality setting of the Dxtory Codec, came out to just over 5GB, averaging about 600Mbps. With the 'Compress' checkbox ticked, I assume this is the Fraps equivalent, because it looked just as good with the slight compression; but the file size was just as large as Fraps as well.

Dxtory has a couple of tricks up its sleeve however. For one thing, recording at that high a bitrate in game in Fraps, my framerate took a big hit. With Dxtory, it was a lot smaller: from about 50fps in a busy 64-player BF3 multiplayer area, down to about 40fps. And then to see the quality of the video file is almost the same as Fraps? Fantastic. The other thing is, you can specify different levels of quality when using the Dxtory Video Codec to save disk space and lower the strain on your system. For instance, trying the Dxtory Low Quality setting, the file created from a minute of gameplay was about 2.5GB, with an average bitrate of 330Mbps - about half that of the High Quality recording. Although it wasn't bad, you could tell that it was lower quality however, with some Chromatic Aberrations around text at lower resolutions [I may provide screenshots from the video in a future post]. It was good enough for recordings at 1050p or higher though, especially if you are resizing down to 720p for upload to a video sharing site somewhere.

You can also use other Codecs that you have installed on your system. I tried XviD, x264 and some others, but putting too much compression/small size restrictions on the recordings created more lag in the game and resulted in 'choppier' video output/playback.

[Although the built-in codec is great, I settled on installing the UT Video Codec (YUV-4-2-2) for it's balance of speed and size versus its great quality - and that's the one I would use if I were to purchase Dxtory.]

For more details/information on various codec settings (using as an example, H.264/AVC), I have written a more in-depth article, talking about the different settings (for MPEG-4 Part-10) and why you may or may not want to enable them, here (text only, "Long Version"):
http://gametipsandmore.blogspot.com/2013/05/game-recording-with-mpeg-4-using.html

Another weapon in the arsenal of Dxtory is its configurability. You are not restricted to just Full Resolution or Half, you can record in 75%, 50%, 25% and even other increments [I found 80% to be a good trade off between quality and file size for the default codec] or set your own resolution to record at - even while you play in another totally different rez, to help with reducing recording 'lag'. Nice. It also has multiple audio inputs (compressing the audio as well, if you wish) and timed screenshot-taking in multiple formats, if that's something you need. It also has it's own little 'Disk Benchmarking' tool, so you can test each drive and find out which one is the fastest to record with.


BANDICAM:

Bandicam is a contender from Korea that can record not only DirectX/OpenGL acceleration in games, but also the GUI itself or portion of it (such as recording what you are doing in Windows for tutorials). Another highly configurable program, you can change the resolution and quality level you are recording at (playing at one resolution while recording in another, as with Dxtory). You can choose a compressible the sound format and even embed your own logo as a watermark, with various sizes and transparency settings on it.

One minute of recording at 1680x1050 with its default setting came out to 0.1GB - you read that right, 100MB - with an average of about 15Mbps of data. Ten straight minutes of recording BF3 multiplayer came out to about 1GB. That means to record an hour of gameplay (an average Conquest match in Battlefield 3 or a Full Run of an Episode in Left4Dead) would take up only about 6GB!
[That also means, for the amount of space 1 hour takes up of a full-size Fraps recording, I could record over 40 hours of gameplay!]
I still can't believe it.

I immediately thought that the resulting file must look like crap on a cracker, but the video is actually comparable to both Fraps and Dxtory. It's not 100% quality, but then, the Default setting in Bandicam [at the time of this writing] was set at 80% Quality of MPEG-1, Variable Bit Rate ( which uses more bitrate when needed, using less when less is going on and not needed) encoding. The resulting video file did indeed look about 80-85% quality of a Fraps/Dxtory(HighQuality) recording, but that means it looked just fine, with clear text and textures, and it could further be turned up to 100% if you so desired.

['Videophiles' will notice some typical mpeg artifacts such as Gibbs Effects at lower resolutions/quality settings and some Temporal Recursive Noise and other compression artifacts when using MPEG-1 at low quality settings, but these can be alleviated by increasing the VBR percentage (to 90% or higher) or switching to recording in MJPEG [which is PlayClaw's recording codec of choice, for example, at the time of this writing] using a high quality setting (again 90% or higher) or once could even use the built-in YV12 codec if space is not an issue]

You can also record in YV12 or RGB, which give "FrapsQuality" recordings, but are also huge in file size to match (for instance, recording in YV12 colorspace, 1 minute of recording was about 5GB and 1 minute of RGB was almost twice that size).

[For filesize savings at a decent quality price, I think most people will be happy using [what originally was the program default of] the built-in Bandicam-optimized MPEG-1 codec at a high variable bit rate (80-100%) setting - and that's what I would use if I were to purchase Bandicam.]

The effect of apparent lag on the system was somewhere between Dxtory's 'Barely There' and Fraps's 'Omg I'm Gunna Lag', taking a 60fps Battlefield3 match down to about 40fps while recording. It was surprising to not have it affect the framerate more actually, considering the quality of the resulting video file, its small footprint the output file was going to have, and the processing that must be going on, behind the scenes to have that all happen. I also found that when recording the Windows interface, the resultant video was less choppy than a Fraps recording of the same thing (and with Bandicam you can choose to record only a portion of the screen, if you wanted to, for creating tutorials and such).

Bandicam is also configurable like Dxtory, so if recording at 1080p resolution, of 100% quality, at 60fps is a bit much for your system, you can turn down the quality (80% is the default and looks ok), or record at a smaller resolution while playing the game at a larger one, or record 'full-size' and just go and reduce the in-game resolution to something smaller, or you could turn off sound compression and many other things... but for the most part it works great as is, especially with a more modern desktop system.

With no audio/video sync problems during long recordings (tested up to 48 minutes) and with the additional option to record general Windows screen output when needed, this is a serious contender, especially for those who must have 'disk space usage during recording' as a consideration, as I do.



The Conclusion



Fraps vs Dxtory vs Bandicam?

I always like to say to everyone: try things out on your own, on your own system, and see which one is the best for you (they all have Demo versions available).
Perhaps you are more concerned with 'the best quality' and not concerned with 'hard drive space', then Fraps may be more for you - if your system can handle it. If you have an older system and are experiencing too much lag during recording, the configurability of Fraps to help, with options to turn down, are simply not there, so perhaps one of the other two, offering more configuration and recording options, is more your speed. Every system performs different and everyone has differing opinions on 'what looks good enough' for what they are doing; but, after testing all three choices of game capturing software personally, here are some overall considerations I can give with confidence:

Fraps
++ Excellent Quality (No other program records in as good quality by default)
-- Quality is not very configurable (aside from half-resolution recording)
-- Huge File Sizes
-- Large Performance Hit ([*not everyone] when recording, can lower to half-size to help perf.hit)

Dxtory
++ Great Quality (or Excellent or Low, depending on your settings and restrictions)
++ Quality is Configurable (compress with various codecs, compress audio, any resolution/size)
-+ Variable File Sizes (depending on settings, YV/RGB is possible which is similar to FrapsQuality/Size)
-- Small Performance Hit (when recording using UT Video YUV-4-2-2, otherwise Medium perf.hit)

Bandicam
++ Great Quality (or Excellent or Low, depending on your settings and restrictions)
++ Quality is Configurable (compress with multiple codecs, compress audio, any resolution/size)
-+ Small/Variable File Sizes (Smaller even at 100% Quality, YV/RGB is possible which is similar to FrapsQuality/Size)
-- Medium Performance Hit (when recording, can lower quality or size to help perf.hit)



Have fun testing and making your own choice!




Personal Short Version/Opinion:
  • Fraps has great quality and always has, but the file sizes are just too big for me right now. I could record at half-resolution, but then the overall quality is too low in most games. And recently, there is a problem with the audio being out of sync with the video in the recorded files for me. Sorry Fraps, I have to look for something else until you get that fixed (or I do on my end).
  • Dxtory has great configurability, I can have the quality of Fraps with the right settings, and without the lag that Fraps creates in some games! But then, recording with those settings, the file sizes would be just as big anyway. Since a concern of mine right now is disk space; sorry Dxtory, you're not my pick today.
  • Bandicam, in it's default setting at the time of this post, does not have the exact quality of Fraps, but it can be made to have closer to the quality of Fraps by increasing the Variable Bitrate higher, or changing the compressor to MJPEG with a high (90-100%) quality setting. I could utilize the even better looking YV12, but then the file sizes would be just as big as Fraps... The MPEG-1 codec, as it's being used/optimized in Bandicam, especially with the VBR setting, only uses up disk space as it needs - and it compresses well even what it does use. The result is that it seems I can record everything, for hours and hours, and then I can pick and choose the parts later that I want to edit/keep. The quality of the Bandicam-optimized MPEG-1 (or Bandicam-optimized Xvid if you prefer to use that) at a high setting (80-100% VBR) looks fine for action games to me, with a few small nit-picky parts in areas where there is not much going on (flat color areas or slower games/movement), as is the nature of Variable Bit Rate recording. This can be fixed however, by filtering or resizing during editing - or it can not even be a problem at all by simply increasing the bitrate/VBR setting, or changing the codec to a high bitrate MJPEG setting [90-100% quality], which would improve things for even slow, non-action-oriented areas and games (like web browser games). Changing the codec to MJPEG also uses less overhead [performance demand/'lag'] and your recording will also be more compatible with editing programs and allow you to cut/start anywhere in the video and have it respond/seek much faster [I personally like the film-like look of MPEG-1 and how it compresses so well (small file size recordings); but the crispness, low overhead and compatibility with editing apps MJPEG offers is very useful, I am finding as I was doing this testing]. Being able to also record the desktop for tutorials, on top of all of that disk space I'll be saving, simply won me over. I am now a proud supporter (Registered User) of Bandicam.


See you in the games!



[ Update 1 : If you are looking for a TestRun with Video Examples of these programs and the quality that they produce when recording, the first Video TestRun comparison of them can be found at the blog here:



» Look for upcoming TestRuns, which will include PlayClaw's Newer Demo Version (that allows higher quality) and more Game Recording Apps - like Mirillis' Action, OBS, SmartPixel and more!
Update on this - a QualityTest/'Shootout'/Versus between ACTION, Playclaw 5 and Plays.TV Coming Soon™ in 2016!



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