Quick Tip: Bandicam Releases CFR-capable Recording Update (for Importing into Vegas, Premiere, Lightworks, etc) [Notice of Update]

Just a Quick Tip for people having problems editing their recordings in Sony's Vegas, Adobe's Premiere, or Editshare's Lightworks, Canopus' Edius and other similar Non-Linear Editors:
Bandicam has released an Update to their software today, that allows the choice of either VFR (Variable Frame Rate) recording [Shadowplay's Default, for example] or CFR (Constant Frame Rate) recording - which is much more compatible for importing into these video editing applications, when recording with NVENC, AMDAPP or QuickSync codecs.


For a number of years now, people have been having issues with importing videos into Vegas or Premiere (to use these as an example, as two of the more common consumer editors) - mainly because many recording applications/settings use, by Default, VFR recording (Nvidia's Shadowplay, for example). As many people have already found, this can cause a multitude of problems, when trying to import these recordings into some of the video editing programs mentioned above. Problems such as:

• Audio and Video being Out Of Sync
• Recordings not showing up as Full-Length
• Audio not importing properly
• Video not being recognized
• Audio importing as only 'a small piece' of data

and other issues...

An example of one issue that can arise with VFR and some Video Editors is, 'trails' or corruption of some type; where the differences between the frames is displayed erroneously, as seen in the still-frame/screenshot just below:

While these issues are a combination of the strictness of the video editing applications and the settings that the codec is using in a recording application, these may now all be alleviated, with the latest update to the game recording program Bandicam, if they are occurring:

The Bandicam interface after the recent update, showing the Steps ("I. II. III.") for enabling CFR, which increases import compatibility with video editing applications such as Vegas, Premiere, Lightworks and more (MP4 container, GPU-accelerated H.264/AVC via the AMDAPP codec, 60fps format/settings shown as example). Click to see Full Size

Today, after updating to the latest version of Bandicam, there can be seen the option to choose either VFR (the Default for Shadowplay and many other recording applications, including Bandicam - which is more efficient for compression, but can result in problems when importing into Vegas/Premiere/etc) or CFR (which is less efficient for compression, but can alleviate the problems with importing into Vegas/Premiere/etc).

For those wanting to use NVENC, AMDAPP or QuickSync to record, for example (GPU-accelerated recording capabilities), this will allow increased importing into these editors, without the need to 're-compress' the videos into a more compatible video format (for example, adding the extra step of using Handbrake to convert the videos into CFR, making the videos importable into Vegas/Premiere/Lightworks/etc, as I wrote about here, when talking about Shadowplay). 

(As another example, if you used Plays.TV's client to record with (which can also use buffered and GPU-accelerated recording), you may have noticed audio/video desynchronization occurring, when attempting to import your recordings into video editing programs - as Plays.Tv's Support Area talks about here, it is due to the usage of VFR)



As a quick Test, I captured my Desktop in a short recording (using Bandicam with the new CFR setting), then tried to import that into Vegas, to see if the video and audio were indeed importable without problems, as a trial of this new compatibility setting.....

A short test of the CFR setting in Bandicam (Desktop portion, short recording, imported into Sony Vegas Movie Studio Platinum 13, playing back within Vegas, output converted into GIF with Honeycam).
Click to see Larger Size

It worked great! The recording was not only imported into Vegas without complaint, it was faster (more responsive) in editing/shuttling/scrolling through the video, due to the CFR setting.

[This was with the AMDAPP (AMD GPU-accelerated) codec, in the MP4 container, using the CFR setting. This codec setup within Bandicam utilizes AAC audio as well and I would use it mainly when editing with Sony's Vegas line of video editing products, as it seems to import without issue. If I were to switch to other codecs or the AVI container, they may then not be as easily imported into NLEs such as Vegas, so I would then use something else, such as CyberLink's PowerDirector (for example), which is far less 'fussy' when it comes to codecs and formats, for importing]

VFR (Variable Frame Rate) helps increase possible compression by reducing the number of frames in a group ('groups of frames utilized per second' in the file) - literally reducing the number of frames used in a file - when less is changing/occurring onscreen. CFR (Constant Frame Rate) will increase file size moderately, due to the fact there is no longer the reduction of the number of frames in a group useable as a factor in compressing the video further - when 60fps is set as a FrameRate, it will literally write sixty frames every second into the video file, regardless of how much has changed onscreen. BitRate is still the major factor in how large the video will be, however. Also note, that this setting is independent of the "fps" (Frames Per Second) displayed output.

[TLDR: CFR will create larger files than VFR because it cannot compress the video as much, but not excessively large, as BitRate is still the main factor in video compression/sizes - and both of these do not affect "frames per second" output onscreen]

Hopefully, this new capability will alleviate the problems with importing your game recording experiences into your favourite video editing application. Try it out, have fun with it - and See You In The Game!

 N.B.: 

I discovered when editing recordings with NLEs (Non-Linear Editors) such as Vegas, Lightworks, Premiere, et al. you may need to utilize a GOP (Group Of Pictures) of "1" for editing compatibility... 

Usually, with MPEG-based video data, there are set intervals of "Keyframes". 
Keyframes are 'stand-alone' images, where all the picture data is kept within one frame (it is not dependent on surrounding frames in the file). Video editing applications use these Keyframes to begin/cut edits from. If there is a large GOP (with many frames in-between these Keyframes), the video editing program must 'key off' of these frames, rebuilding the GOP within the program, causing slowdown in edit processing and possibly causing visible corruption ('trails' or 'glitchy' output). 
Setting a Keyframe Interval of "1" makes every frame in the video a Keyframe, eliminating the possibility of this issue. 

I have written a couple of articles on this, here at the blog,
http://gametipsandmore.blogspot.ca/2013/06/and-more-how-to-record-with.html
http://gametipsandmore.blogspot.ca/2013/05/game-recording-with-mpeg-4-using.html
and submitted this occurrence to Bandisoft, the development house of Bandicam. I am proud to state that this led to the inclusion of a Keyframe Interval option within Bandicam. 

This setting may still be required for full compatibility with Non-Linear Editors. 

Although a GOP of 1 takes away most of the 'headroom' to work with video compression (the video file sizes will increase as it does not have the inter-frame dependency), if you are having issues with importing your videos into these types of video editing applications, even with this new CFR setting, try configuring the Keyframe Interval to "1" [you can also use PCM ("Uncompressed") audio to increase audio compatibility] and this should assist with issues with importing your recordings into these editors. 

Good luck with it!

Quality Test: Bandicam's Xvid Implementation And Examination Of The Optimization Configuration [with Screenshot Comparisons]

For those that use Bandicam to record their gameplay, you may already be familiar with and even use one of the built-in Presets that Bandicam offers, all of which configure many of the recording settings automatically for you. Some of these Presets are directed towards 'immediate post-record upload' of gameplay recordings. One of these, is the "YouTube (720p)" Preset.

In this Quality Test, I will be focusing in specifically on the "Optimization" setting within the Options of this Preset and examining the difference you can expect between the two options that you can choose from. The two options for the Optimization setting under the Xvid Settings dialog are: "Faster Encoding Speed" (the Default) and "Smaller File Size" - the area where you choose between these two is highlighted in the Header of this article, above.

Recently, on the Official Bandicam Forums here, I was trying to help out a fellow Bandicam user, with information about Quality and it's relation to File Sizes, and I ended up speaking briefly about this "Optimization" setting, offered in Bandicam. I felt as though I wanted to expand a bit more on this setting in Bandicam and the effect of each option - both for the benefit of this user and to help others as well - and so here is the 'expanding'... ness...

"Xvid" is a codec (used to COmpress and DECompress video), that is part of the MPEG-4 family. For those familiar with video compression and H.264/AVC (which is MPEG-4 Part 10, Advanced Video Coding), Xvid is H.263/ASP (MPEG-4 Part 2, Advanced Simple Profile). This means it is related to h.264/AVC; however, being h.263/ASP, Xvid does not have some of the 'top-shelf' capabilities of h.264/AVC. It does however, have many capabilities (such as B-Frames and Quarter-Pixel analysis) which still give it high-quality output potential.

For more of an in-depth look into Bandicam's implementation of Xvid and other Settings it offers, their effects on Quality and related File Sizes (and More!), I have written an article earlier (by popular request) talking about "some of the Xvid settings I use, and why", here.

In the game recording application Bandicam, the many options that Xvid offers have been given a simplified interface for the user, where they can very easily choose between a 'Faster Speed' version (the Default) and a 'Smaller Size' version. This is to expected from the concept of the Presets, but it is also simplified in the Xvid configuration options in general [in Bandisoft's implementation of Xvid in the program]. This should not be seen entirely as a negative, as there are many, many options for Xvid (an MPEG-4 codec, with literally dozens of settings) and it would be potentially confusing for many users to attempt to choose between the various settings [and know what their effects on recording and output would be], thus the simplified interface.

So then, what is the 'real difference' between the two "Optimization" settings? Let's take a look...

Night Scene frame comparison for the two settings, in the Unigine Valley Benchmark. Click to see Full Size

Above, is a side-by-side comparison of two frame extractions from two recordings, utilizing the two different Xvid Optimization options in Bandicam. The one on the left was from a video recorded using the Default setting of "Faster Encoding Speed", where the one on the right was from a video recorded using the option changed to the "Smaller File Size" setting.

It can be seen, mainly in the flatter, darker-blue area between the moon and the trees to the left of it, that the 'Faster Speed' side appears to have a 'blocky' effect occurring, even though it is a subtle occurrence. It does not seem to be happening on the right, in the 'Smaller Size' setting frame. The right side has a smoother change in the variations of colours, with less of the 'blocks' - which are compression artifacts (that is, visual effects seen in the video material due to the difference in how the codec is calculating the gradations ['noticing and calculating the series of changes'] in the colours).

This 'blocky' effect is likely occurring because many of the analysis and processing options in the codec may be turned OFF in the 'Faster' setting of [Bandicam's usage of] Xvid. This is a normal approach however, as turning these types of options off, essentially tells the codec "don't pay as much attention to detail" - resulting in the codec processing and outputting data (in the form of frames) much faster - hence the "Faster Encoding Speed" title of the option. It simply is not attempting to 'look at all the subtle differences in colour' and 'keep them all'.

As far as Output File Size for each Optimization setting, when recording the Valley Benchmark with the "Faster Encoding Speed" option of Bandicam's "YouTube (720p)" Preset, it was streaming data at about 24Mbps to the video file (writing about 3MB/s [to a hard drive capable of 150MB/s]).  When recording using the "Smaller File Size" option, data was being recorded at half that rate, about 12Mbps (writing less than 1.5MB/s to the video file). This is most likely due to the extra analysis that the codec is performing, being able to [with the 'Smaller Size' setting] scrutinize further and compress the video more, reducing the final recorded file size output.

 Let's look at other examples to see more differences between the two settings.

Close-up anatomical frame comparison for the two settings, in the Street Fighter IV Benchmark. Click to see Full Size

Above, is a comparison of two frame extractions from two recordings of the Street Fighter IV Benchmark. The left (using the 'Faster Encoding Speed' option), has not only the Macroblocking effect from our earlier example (at less severity, seen more along in the right edge of the frames); but it also shows a blotchy, speckled effect within the subtle changes of colour (seen everywhere, but it is more obvious around the deltoid and pectoral muscles of the game character [Ryu's shoulder and chest muscles]) . This is a form of Gibbs Effects, sometimes called "mosquito noise" in video processing.

This type of effect is likely to occur for the same reasons as the above comparison, where in the "Faster Encoding" setting, many of the analysis and processing options are turned OFF, resulting in higher Performance, in the end. The codec is simply not attempting to maintain the same amount of detail (the minor changes in colour) within and between the frames - again however, having the result of higher performance [versus the "Smaller Size" option].

The recordings themselves, of the Street Fighter IV Benchmark, had similar Bitrates to the above example. With the "Faster Encoding Speed" option, about 30Mbps were being saved to the video file (written at about 3.5MB/s to the drive). When using the "Smaller File Size" setting, about 20Mbps of data was being streamed out (written at about 2MB/s to the video file output). This again, is an example of the extra analysis, capable in the 'Smaller Size' option, where the codec is going to sacrifice some performance, to do what it can, to analyze the differences in the video and maintain them to a higher degree in the final video output (keeping more detail - at the cost of a performance 'hit' in recording and disk space used overall for the final output file).

Still frame comparison for the two optimization settings, taken from the Batman: Arkham City Benchmark.
Click to see Full Size

In the above pair of screenshots (extractions from two Batman: Arkham City Benchmark video recordings), evidence of both of the previous example types of compression effects can be seen. In both frame extractions, Gibbs Effects ('ringing' or 'mosquito noise') can be seen around the furniture in the bottom/front (center). The left frame also contains the Macroblocking effect, especially in the 'flatter' [area with less detail] center region (it is also present in the right frame, but it does so in a far less obvious manner).

Both of these effects occur to some degree in the right example as well, but Macroblocks occur to a far lesser degree in the central region, as the codec [with the "Smaller File Size" option] is sacrificing Speed for the sake of taking more time to analyze each frame further, taking into account the changes in colour between the frames ('Temporal') and throughout the frames themselves ('Spatial'), attempting to maintain more of the colour it is detecting.

Looking at the Bitrates used for the recordings, with the "Faster Encoding" option, it was saving data at about 16Mbps (writing about 2MB/s to the video file), where the "Smaller Size" option was recording half that, about 8Mbps (saving 1MB/s to the recording); once again showing the difference the analysis and attempt to compress the frames further, saves on diskspace. The Performance Hit for this game was little however, in difference, as the Average Frames Per Second (reported after a Full Run of the Benchmark) was the same for both: 93fps.
4

I wanted to do an example of a game that has far lower 'action' happening on the screen (a lower amount of changes happening at once), so I chose this Web Browser-based game, called Lottso Express (found at Pogo.com). As can be seen above, there is little apparent difference between the two frames extracted from the two recordings, each with the different optimization setting being used.

This is likely due to the fact that there is so little changing on the screen at one time in this game [source material], that the codec is able to efficiently handle all changes occurring, losing little to the lower analysis being done when using the "Faster" option. Indeed, the difference in Bitrate between the two recordings was less than 100kbps - the Faster Encoding recording had a Bitrate of 540kbps (writing about 67KB/s to the file) and the 'Smaller File' video had a Bitrate of about 440kbps (writing about 55KB/s to the file).

Getting back to higher-action games (ones with more changes going on in the screen/frames), the above two frames are extracted from two game recordings of Battlefield: Hardline, each with the different Optimization option selected. Taken from videos where the player [me!] was standing almost still, there was little going on in game, but the frames have Macroblocking occurring in the flatter/less-detailed region on the left [of each], most likely due to the 80% Quality setting of the YouTube720p Preset - compressing the non-moving area as much as possible. Gibbs Effects ("ringing" or "mosquito noise") is apparent in the upper-right area for the "Faster Encoding Speed" side, far less visible in the same region (around the edges of the leaves) on the "Smaller File Size" side.

The Bitrate for both videos shown above was similar as well, with the 'Faster Encoding' recording running at only about 10Mbps (saving about 1MB/s to the video file), as again, the player was not moving very much at all [in this example]. The 'Smaller Size' recording saved only slightly less data, at 7Mbps (writing less than 1MB/s to the file) - not a large difference, since there weren't many changes going on with the material in the frames (due to not moving very much). This is a good example of showing how both settings, although both set with differing limitations, 'try to do as much as they can', when it comes to compressing/saving the video data to the output file.

Still frame comparison for the two optimization settings, taken from two recordings of Planetside 2. I was shooting my rifle just off to the right, creating an area to analyze between the rifle and the Console. The open areas around the Console are also open to examination. Click to see Full Size

Another high-action game, these frames above are from the game Planetside 2, with my soldier shooting a rifle just off-screen to the right. This increases the motion going on in the frames, and thus increases the differences between the two Optimization settings and how they will handle the onscreen motion vectors (seen more in the area between the just-off-screen rifle to the right and the console in the center). Between the two, especially on the left example, Macroblocking is seen in that region, as well as the floor.

Although a handful of examples can bring out the difference between these two settings, try to remember that these are all zoomed, scrutinized examples - still frames, as well, where compression artifacts are much easier to spot - so here is a different type of example, following:

Above, is an example of the two codec settings in motion (created as a GIF by Bandisoft's Honeycam [which came out of Beta just weeks ago - Tutorial for the program Coming Soon™]). Even though I applied a Sharpness Filter within the program, to accentuate the difference between the two, it can be seen that Macroblocking occurs in both (likely due to the 80% Quality portion of the Preset) - although it appears much stronger in the left half. Below is the same example, but with no Sharpness Filter applied.

As seen above, although the compression artifacts are present if looked for, it is somewhat of a subtle presence in a moving, action-packed recording, during playback. Indeed, many people will not even notice the visual differences between the two settings, being more interested in the action occurring on screen! These artifacts are also further 'hidden', if a recording is going to be further processed - such as after uploading to a video sharing site.

Many of these types of sites (YouTube, Vimeo, Plays.Tv, etc) will re-compress the video into a more streaming-friendly Bitrate, sometimes into multiple bitrates, then available to choose from, by the viewer, when browsing them. This decreases Quality (in the name of smoother streaming, with less dropped frames or 'falling behind'), further hiding imperfections like the compression artifacts above - unless of course they are far too obvious in the source recording, where then, they will still be present (although blurred or softened) in the final video playback/viewing. I created an example of the effect from this re-compression, done by video sharing sites - it is shown just below (YouTube is used merely as an example):

Originally created for an earlier article, testing out MJPEG on Diablo3 with Bandicam, this screenshot shows examples of the detail loss after uploading to YouTube, when the video is streamed back at 1080p and 720p (the frames are extractions of the downloaded post-recompression versions of the original upload).
Click to see Full Size

As always, dear reader, I urge you to try your own tests, with your favourite (or latest played) games, to see which setting you prefer. Sometimes, you may be limited in your choices. For example, if you have an older PC system, or are using a Laptop, you may only be able to record with the 'Faster Encoding' option, unable to utilize the further analysis and processing done by the 'Smaller File' setting at this time - it may just create too much 'lag' or 'choppy-ness' while recording for your system. Or, you may have disk space as a limitation, then only being able to use the 'Smaller Size' option, where the further analysis and compression is the only way you can collect enough gameplay recordings for your project.

Either way, don't be too discouraged, remembering from the last [animated] example above - and the YouTube example - that it is a subtle difference overall, one that I have accentuated here [merely for educational purposes, for those that wished to know what the 'real' difference in output would be]. When not 'zooming in' or otherwise scrutinizing the videos closely - normally enjoying them and all their action-packed-ness - one may not even notice a difference at all, even after seeing the above examples! In that case then, I urge you to use whichever is more beneficial for your circumstances - and try to have fun using either setting of this 'Bandicam-optimized-version-of-Xvid' as your recording codec, to record your gameplay experiences.

See You In The Game!

Quick Tip: Multitasking with Bandicam (Recording One Program And Looking At Another)

A few days ago, I suggested on the Official Bandicam forum, the idea of being able to ALT+TAB while recording with Bandicam. For instance, if someone was recording a game, and wanted to ALT+TAB 'out' of it, to another application (for example, to look something up in a web browser).

Currently [as of the time of this post], this cannot be done as easily as described - it simply doesn't work that way - hitting ALT and TAB (or hitting the WindowsKey on the keyboard, which is CTRL+ESC) will result in Bandicam ceasing recording (but it can be started again, of course).

However, during initially attempting to multitask with it and doing some testing, I quickly found a way to get it working and wanted to share it with you all [those who don't already know about it] - and here it is:

When recording gameplay with Bandicam, if you switch to running the game in a Windowed Mode, such as Borderless (ie. not a Fullscreen-exclusive mode), you can then ALT+TAB 'away' to another application that is running and Bandicam will stay focused ('locked') on to the game (that is running in Windowed Mode) and continue recording without interruption. 




Until it gets implemented where this can be done with Bandicam and a game running in Fullscreen mode, try this for now and see if it works for you, too.


Have fun recording your gameplay and doing something else at the same time - and See You In The Games!

Bandicam - Their 2.1.0 Release and Testing Compatibility of the MP4 Container Recordings with Nine Different Video Editing Programs [Link To Forum Post]

Just letting those who use Bandicam to record their gameplay know, I tested the newest version (2.1.0.708, released two days ago) and Bandicam's new ability to record into an MP4 container [natively], an addition that would hopefully increase compatibility with video editing programs. All I did was some quick tests by importing recordings created by Bandicam into different video editing applications; but I wanted to share the results with you all. Here are the programs I tested:

- Adobe Premiere Pro 6 (Trial)
- Avid Media Composer 8.1 (Trial)
- Sony's Vegas Movie Studio 11 Platinum
- CyberLink's PowerDirector 12
- Lightworks 12
- Nero Video 11
and some free video editing applications...

For the results of my testing the new MP4 container recording option with those video editors, visit my short post at the Official Bandicam Forum here:

http://www.bandisoft.com/forum/viewtopic.php?f=10&t=2956&p=10235

I hope you find it useful and See You In The Games!

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

As the First Post of a new type of article here at The Game Tips And More Blog

[started due to popular demand!], I would like to explain a bit about my 'Setting Of The Month':

What is meant by "Of The Month" (at least at this blog), is less 'lunar syzygy' and more 'what is currently being served', in concept. Every once in a while I will post what Recording Settings or Rendering Settings I am currently using. I want to begin doing these posts in response to two things:

• 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.

And so, here is the first edition of a new addition to this blog, without further adieu:

 

This Month's Featured Setting

Bandicam's Xvid Codec

For the past little while, I have been messing with the Xvid codec - not the 'official' one from XviD.org that you have to download - the one that is built-in to Bandicam, easily available via pull-down menu in the Format area, where you choose which codec you want to record with. As of the most recent version of Bandicam [at the time of this post], Xvid is now the Default Codec that is pre-selected, when you install/startup Bandicam. Where in previous versions, a 'Bandisoft-optimized' MPEG-1 codec was the Default, now a 'Bandisoft-optimized' version of Xvid is thrust into the limelight - and I wanted to test this puppy out and see what tricks it can do!

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'):

Recorded Game Title	Resolution	Performance Hit (Δ)
Hitman: Absolution Benchmark	1366x768	~ 2 fps
Hitman: Absolution Benchmark	2560x1440	~ 4 fps
FurMark (Full Run)	1366x768	~ 2 fps
FurMark (Full Run)	2560x1440	~ 0 fps
Unigine Valley Benchmark	1366x768	~ 6 fps
Unigine Valley Benchmark	2560x1440	-
Batman: Arkham City Benchmark	1366x768	~ 4 fps
Batman: Arkham City Benchmark	2560x1440	~ 9 fps
Skyrim (Introduction)	1366x768	~ 0-8 fps
Skyrim (Introduction)	2560x1440	-
Minecraft	1366x768	~ 0 fps
Minecraft	2560x1440	~ 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 (1366x768) 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).

[I personally found that in dark (as in nighttime) scenes, at 80% Quality there was distracting colour quantization (colour quality loss) and macroblocks (little square compression artifacts); but for most material, the 80% Quality setting seems ok to use for Xvid(b)**, most of the time]

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 1280x720). 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

While not as obvious in the moving video, the above frame extractions (both Left and Right sides) show Gibbs Effects ['ringing' or 'mosquito noise'] around the hard edges of Minecraft's graphics. The colour gradient changes, blending slowly into the background/sky colour in the Right Half of the above image also cause Ringing and Macroblocks to occur. Distant water gets treated with extreme prejudice by the codec, as the jumble of lines and animation from the textures are 'sluffed together' [my technical term] and Macroblocks are obvious. Again, these artifacts are more obvious in the stills from the game recording - the video itself, when watched, was more appealing to the eye and these compression artifacts aren't as noticed as the frames fly by and the cow looks at you in a wondering manner.

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.

The default setting, when installing Bandicam, creates a GOP of 150 [GOP stands for Group Of Pictures or the number of frames between Information/Key Frames in a video]. This is fine for normal viewing (and it leaves a lot of headroom for compressing 'only the differences' between the frames, resulting in smaller filesizes), but a large GOP can create problems with editing, as many NLE's (Non-Linear Editors, such as Sony's Vegas/MovieStudio line, Adobe's Premiere products, Lightworks and more) do not work well with so many frames in-between the Keyframes - however, editors such as Corel's VideoStudio, CyberLink's PowerDirector and Microsoft's own Movie Maker do not exhibit this issue [I tested these three applications by hand, myself, just to make sure and they imported fine and were handled without the "glitchy-ness" or "trails" that were exhibited in (for example) Vegas].

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]

Staying on the topic of Bitrate [from the above paragraph] for a moment, "..what kind of file sizes are we looking at..?", you might ask. Well, here is a sampling of some of the Bitrates that were seen when recording with Xvid(b)** at Bandicam's Default Settings for the codec:

Recorded Game Title	Resolution	BitRate (Mbps, GBph)
Hitman: Absolution Benchmark	1366x768	~ 34 Mbps, 0.97GB/hour
Hitman: Absolution Benchmark	2560x1440	~ 83 Mbps, 2.4GB/hour
FurMark (Full Run)	1366x768	~ 44 Mbps, 1.2GB/hour
FurMark (Full Run)	2560x1440	~ 45 Mbps, 1.2GB/hour
Unigine Valley Benchmark	1366x768	~ 37 Mbps, 1.06GB/hour
Unigine Valley Benchmark	2560x1440	-
Batman: Arkham City Benchmark	1366x768	~ 20 Mbps, 0.57GB/hour
Batman: Arkham City Benchmark	2560x1440	~ 54 Mbps, 1.5GB/hour

table code created by Danny Sanchez (journalistopia.com)

Just to compare some file sizes of other codecs: the Low Quality setting for the Dxtory codec (with Compression) recorded a run of the Unigine Valley Benchmark (at 1080p) at about 326Mbps (9.3GB/hour), while FRAPS produced a recording of about 291Mbps (8.3GB/hour), with Lagarith (in Default/RGB Mode) creating a recording of the same material that ran at about 235Mbps (6.7GB/hour). Of course, bitrates fluctuate, depending on the complexity of the material (more movement/action/etc, which requires more bitrate to properly represent the material.. but a longer explanation of that is outside the scope of this post [believe it or not...I'm trying to keep them 'short'! hah]).

The other setting that can be changed in the Bandicam interface for their version of the Xvid codec, is the Quality. Here is an example of the differences in quality output at the various Quality settings for Bandicam's Xvid:

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

As you can see, the perceived quality for Xvid goes down quickly, with Macroblocks becoming more obvious as the quality setting goes down. However, acceptable Quality can be maintained if the quality setting is kept high [in my opinion, stay at 90% or higher if you can]. Remember though, that with the higher quality settings, more space will be required by the codec, to save all of that data. Also, if using a Keyframe Interval of "1" (creating a GOP size of one frame, each frame in the video then being a Keyframe), the codec will also not have as much room to compress the images/video and your output size will increase. As stated above though, the benefit of using a Keyframe Interval of "1" is, then your game recordings will be easily importable/editable in NLEs like Premiere, Vegas, Lightworks, etc - if you are are having troubles with those specific applications [if you are not, there is no need to limit the GOP to one frame, which is why there is no green arrow indicator in the below illustration]. Below, are my Suggested Settings then, for this codec in Bandicam, in one image:

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

Overall, I think 'Bandisoft's version of Xvid' in Bandicam does a decent job with Quality - and is downright excellent where Performance is concerned. On my system (and hopefully yours), Bandicam's Xvid had very little drain on the performance of the game while recording with it, creating very little 'lag' while recording (it had a low 'performance hit'). As long as the quality setting is kept high (90-100%), the recorded output Quality can be quite acceptable, with only a little Macroblocking (block shapes being visible) and Posterization [colour quantization, which is a reduction in the amount of colours, resulting in 'colour banding' or 'bands' seen] in the darker and 'flatter' areas of a frame in a game recording (Macroblocking may occur in areas such as skies, less-colourful regions, etc). Try out some recordings with Bandicam's version of Xvid for yourself and see if you prefer using it for recording your gaming adventures.

Please note dear reader, that I am not saying "this codec is the best one to record with" or "use this one only". I am merely showing that it is possible, or how to tweak it for quality or file size, as to your own personal tastes. There are many codecs out there to choose from when game recording and although some are more apt for certain types of games than others, overall it is your own choice to do with as you wish - use what you prefer. 

See you in the games!

Personal Short Version/Opinion:

While the Bandisoft-optimized version of Xvid included in Bandicam works pretty well and is fast, I find myself not using it very often, other than this past month or so, for testing. After recording for a while with Xvid's 'successor', h.264/AVC, the extra features of Deblocking and other tools in AVC have 'spoiled' me. Going back to the slightly more 'blocky' output of Xvid - even though it creates very little lag when recording - is slightly distracting to my eyes. When I see an Xvid game capture of mine now, my eyes are instantly drawn to the darker/flatter areas of the scene and those little tiny block shapes...and I sigh at the slowly-aging Xvid codec, remembering its' heyday' of compressing my TV shows recorded on my ATi TV Wonder PCI card. The late 1990's and the 2000's were 'Xvid's Time' to me, when I used it for almost everything - and while it performs well in game recording today (even Xvid.org's 'Official' version, with the right settings), I am now just too used to the benefits of more modern codecs, like h.264/AVC, which can even use the videocard/hardware, for GPU-accelerated recording.

I realize there are a lot of people gaming on laptops out there, and not everyone has a dedicated/separate videocard inside their system to record with, but the more I use my GPU to record with, the more I am impressed with the performance when recording most games [note that some games 'don't like' GPU-accelerated recording (are not fully coded for compatibility with it) and these games have large hits to performance with it]. At the moment of this writing, I have two NVIDIA videocards running in my system (performing together in SLI mode) and I am enjoying using the GPU-accelerated CUDA offering in Bandicam to record with. Like AMD's AppAcceleration and INTEL's QuickSync, CUDA utilizes H.264/AVC through the hardware to record, having high performance [for most games] and producing nice output, utilizing some of the newer aspects of MPEG-4 (such as Deblocking) when recording, to hide compression artifacts [the little 'glitches' from compressing the video]. The speed, and presence of light 'compression correction' from this hardware implementation of MPEG4 has spoiled me now, and I am finding it hard to go back to the slightly more obvious artifacting in 'older' codecs, such as MPEG-1 or Xvid (which is 'older' MPEG-4), especially when those codecs are used at lower quality settings, to try and save hard drive space. (Turning up the Quality settings for these codecs helps a lot, if your system can handle it)

As CPU architecture evolves and modern CPUs have 'mini-GPUs' built into them, the differentiation of capability between 'gaming rigs' and 'gaming laptops' blurs [as far as game recording goes], as GPU-accelerated game recording is possible now by less and less expensive hardware (AMD APUs) and processors (INTEL's QuickSync), even within laptops [as opposed to full desktop systems]. This means that "gaming laptops" now have much more capability when it comes to game recording, today. If your laptop is capable of using GPU-accelerated recording, give it a try. If it is not, systems that do not use the GPU to compress their video can still perform well recording games, as is shown with the above article, by using Xvid. "If you can't choose the H.264 encoder in Bandicam, choose 'Xvid'" ~ Quote from the Bandicam.com website.

Do some testing of your own dear reader - and have fun experimenting, finding a codec that you will eventually prefer to record with - and See You In The Games...

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...] 

 **[designated as "Xvid(b)", to show that it is the "Bandicam-Optimized Version of Xvid"]

Quality Test - GPU-accelerated H.264/AVC Game Recording with CUDA (with Screenshot Comparisons and Examples)

To perform game recording solely on the videocard, utilizing the high resources of today's little powerhouses sitting in our cases - resulting in high quality video and less lag while recording - sounds like manna from heaven. You might be saying, "Wait, the possibly of lowered performance hit and the possibility of a high-quality recording?.. if this is true, please stop teasing and just tell me now..". Well, dear reader, let me tell you that these things are indeed true [for the most part..].

Beginning with version 1.9.0, Bandicam (a game recording application) included support for utilizing NVIDIA's CUDA for recording your gameplay, touting high speed (less 'lag'), high compression ratio (smaller file sizes) and high quality. All you needed was a CUDA-capable NVIDIA videocard, the latest videocard drivers from NVIDIA, and Bandicam. In the most recent version of Bandicam (1.9.1) they have also included support for AMD's APP ACCELERATION and INTEL's QUICK SYNC. 

For this QualityTest, I took an NVIDIA GPU and put it through the paces of some game recording with the accelerated H.264/AVC codec (as opposed to the CPU-based x264 for example), using Bandicam [which at the time of this writing, to my knowledge, was the only game recording app that could utilize accelerated/gpu-based AVC recording] to test things out. Here are my findings, shared just for you.

An example of an NVIDIA CUDA encoded game recording, this is a frame extracted from the CUDA-produced output file (Unigine Heaven Benchmark Test @ 1080p). Click to see Full Size

Overall, recording with the GPU gave good performance (low performance hit / lag), fairly small file size output, with decent quality [surprising to anyone that has compressed video with CUDA in the past, I know, more info below]. It was only with certain games that the performance suffered (although this may be more the fault of optimization with the game's engine and not NVIDIA's programming) and it was slightly disappointing that the performance wasn't "that much faster" than other codecs [more info at the end about that]. For the most part however, game recording "live" with the GPU and directly encoding to a file using a compatible videocard is indeed nice and fast and produces comfortably-small footprint file sizes.

What file sizes are we talking about here? 

I haven't looked at the specs for the codec and how it's utilized, but from what I can quickly see on the surface, it is using the h.264/AVC codec with my NVIDIA GPU, with Deblocking enabled and with a keyframe/I-frame inserted every 5 seconds. That doesn't leave 'a lot' of headroom for compression (x264 AVC usually defaults to 250-300 frames between keyframes which, at 30 frames per second, is more like 10 seconds to 'play with' for compression); but it still gave a nice small filesize when recording with VBR (Variable Bit Rate), where it would compress slower-motion areas and scenes when it could and increased the bitrate (to try to keep apparent quality) when needed in faster/high-motion sections.

An example of an NVIDIA CUDA encoded game recording, this is a frame extracted from the CUDA-produced output file (Battlefield 3 @ 1080p). Click to see Full Size

Just below, you will find some data samples of game recordings that were done at incremental quality settings, showing the average bitrate of the recording overall and the sizes of the files produced as output
[(i)all game samples were recorded with accelerated/gpu-based H.264/AVC generated by NVIDIA's CUDA at 1080p unless otherwise indicated (ii)although test recordings varied in length between games, throughout each game title, all 4 tests of the same game were done with the same elapsed time]:

Recorded Game Title	Q. setting	Average BR	Filesize
Batman: Arkham City	Quality 100	(~75000 kbps)	753 MB
Batman: Arkham City	Quality 70	(~22000 kbps)	224 MB
Batman: Arkham City	Quality 50	(~10000 kbps)	104 MB
Batman: Arkham City	Quality 20	(~5000 kbps)	59 MB
Unigine Heaven Benchmark	Quality 100	(~120000 kbps)	1390 MB
Unigine Heaven Benchmark	Quality 70	(~48000 kbps)	551 MB
Unigine Heaven Benchmark	Quality 50	(~24000 kbps)	276 MB
Unigine Heaven Benchmark	Quality 20	(~11000 kbps)	140 MB
Diablo III	Quality 100	(~22000 kbps)	44 MB
Diablo III	Quality 70	(~9000 kbps)	20 MB
Diablo III	Quality 50	(~5000 kbps)	12 MB
Diablo III	Quality 20	(~4000 kbps)	9 MB
Alien Versus Predator (PC-2010)	Quality 100	(~110000 kbps)	380 MB
Alien Versus Predator (PC-2010)	Quality 70	(~37000 kbps)	126 MB
Alien Versus Predator (PC-2010)	Quality 50	(~18000 kbps)	66 MB
Alien Versus Predator (PC-2010)	Quality 20	(~8000 kbps)	28 MB
Minecraft (Standalone)	Quality 100	(~47000 kbps)	44 MB
Minecraft (Standalone)	Quality 70	(~27000 kbps)	25 MB
Minecraft (Standalone)	Quality 50	(~13000 kbps)	12 MB
Minecraft (Standalone)	Quality 20	(~7600 kbps)	7 MB
Lord Of Ultima (Browser Game)	Quality 100	(~ 24000 kbps)	59 MB
Lord Of Ultima (Browser Game)	Quality 70	-	-
Lord Of Ultima (Browser Game)	Quality 50	(~7000 kbps)	20 MB
Lord Of Ultima (Browser Game)	Quality 20	(~3000 kbps)	11 MB
Lottso Express (Browser, 384p)	Quality 100	(~870 kbps)	10 MB
Lottso Express (Browser, 384p)	Quality 70	(~320 kbps)	7 MB
Lottso Express (Browser, 384p)	Quality 50	(~225 kbps)	6 MB
Lottso Express (Browser, 384p)	Quality 20	(~164 kbps)	5 MB

table code created by Danny Sanchez (journalistopia.com)

As you can see in the table above, due to the nature of Variable Bit Rate recording, setting a quality figure of "50" does not produce 'exactly one-half' of the bitrate or filesize of a "100" quality setting. The codec is adjusting as needed and where required, allocating more bitrate to complex areas and changes between frames, to help keep "apparent quality" near the desired estimate. Configuring the Quality setting of "100" is essentially telling everything to keep as much detail as possible - but it will only do so within the limitations of the codec being used (in this case, AVC) and how it is configured internally (the calculation time allowed per frame, the buffer allowed, etc), depending on how the developers have programmed it to encode.

An example of an NVIDIA CUDA encoded game recording, this is a frame extracted from the CUDA-produced output file (Minecraft @ 1080p). Click to see Full Size

Overall, it seems that with CUDA, the file sizes are kept comfortably small - especially compared to a FRAPS or DXTORY codec recording. The bitrate doesn't stray too far from a 100,000kbps maximum (about 12 MB per second of video data) despite how much action is going on in the game at the time. At that bitrate, a half hour of straight recording would take up only about 22GB. Not too bad, especially if you are creating long recordings or can't afford that 4TB drive upgrade just yet. A Blu-Ray disc title typically uses a bitrate of 25,000-50,000kbps, so a GPU-based/accelerated recording is still allowing for more than double that bitrate to try to represent what is happening on the screen in viewable quality.

So then, what is the quality like?

Normally, if you ask anyone about quality who has used GPU-acceleration together with words like "video editing" and "compression", they will tell you: "It encoded faster, but the output looked craptacular..". I myself have tried off and on in the past to compress videos for myself and others with acceleration and every time I tried CUDA or AMD's APP.ACCEL for the final AVC output I was disappointed at the blotchy, blurred, 'macroblock-y' mess that comes out, unless I allow for a much larger bitrate than intended (and receive a correspondingly larger file size). Somewhat surprisingly then, it was nice to find that I did not need to confine myself to "100% Quality" and always expect huge filesizes with GPU-based game recording to get decent viewable quality, suitable for sharing.

A side-by-side comparison of four CUDA quality settings (100%, 70%, 50%, and 20%), these are frames extracted from the CUDA-produced output file (Batman: Arkham City @ 1080p). Click to see Full Size

As can be seen in the screenshot comparison above, decent quality can be maintained at the 100% Quality setting, despite the speed of the encoding being done with H.264/AVC. I was pleasantly surprised, to be honest. Of course, Videophiles will notice slight Posterization and light MPEG-compression artifacts (such as Macroblocking) occuring even at 100% Quality if looked closely for; but for the majority of people, a quality setting of 100% (even down to 80%) should be found quite acceptable. I personally found that at 70%, the compression artifacts became more noticeable, especially the 'trails' that occur from the lossy Vector Quantization (the codec keeping track of where things are moving around between frames), which is why I chose 70% as the 'next notch down' on these tests. At a Quality setting of 60% and any setting below that, these 'trails' left behind are very apparent and in my personal opinion I do not recommend going below 60% for GPU-based game recording at this time, as the quality loss and compression artifacts become too obvious and may remain apparent even in a final render after editing.

An example of an NVIDIA CUDA encoded game recording, this is a frame extracted from the CUDA-produced output file (Diablo III @ 1080p). Click to see Full Size

The screenshot above is a frame taken from a CUDA-produced Diablo III game recording. Even during a busy moment, with many things happening quickly on the screen, clarity seems to be maintained at a decent level, even the somewhat-hard-to-compress 'Red Text On A Dark Background' - and this video clip was recorded at the 80% Quality setting. Although some macroblocking is beginning to occur in the darker/flatter area of the upper left (as the codec attempts to keep detail in the high-motion areas by compressing the more static areas of the screen to a higher degree), the darker/flatter toolbar and stone floor overall do not seem to be suffering excessively.  [As always however, my personal opinions on quality are mere suggestions based on my own tests and I encourage you to do a bit of your own testing, to find out what settings you would like to settle on and use for your projects]

Since the desktop/GUI can also be recorded with Bandicam, I decided to try record a web browser game with the GPU as well, for the people out there who like to record these games. I recorded two free online games, Lord of Ultima (a city/area building game) and Lottso Express (a bingo-style game), both of which are 2D (flat, board-like), which I thought would be a good example of more static detail (low-motion) compression.

An example of an NVIDIA CUDA encoded game recording, this is a frame extracted from the CUDA-produced output file (Lord of Ultima, a web browser game @ 1080p). Click to see Full Size

Lord of Ultima takes up the entire desktop in this large example of low-motion/static area handling by the accelerated codec. The game, captured above, is largely non-moving, especially the toolbars and left portion of the screen. Recorded at GPU-encoded 100% Quality, the toolbars are clear, text is very readable, and even the darker, static area of the Town Hall pop-up is clean and macroblock-free (very little compression artifacts throughout the entire screen), very nice.

A side-by-side comparison of four CUDA quality settings (100%, 70%, 50%, and 20%), these are frames extracted from the CUDA-produced output file (Lottso Express, a web browser game @ 384p). Click to see Full Size

Lottso Express runs in a small window, so I tested out recording at the exact resolution of this window (576x384) to see how gpu-acceleration handles lower resolutions. The differences inherent in the four Quality settings, in each of the four extracted frames from the CUDA recordings above, is shown. Although the top section/frame is quite clear (at 100% Quality), it quickly degrades as the quality setting goes down, but the recording still remains watchable. In my opinion, if one is recording just for themselves for fun, or just to share with a friend quickly, even a recording level as low as 60% quality may be acceptable when recording a low-motion 2D game with gpu-accelerated encoding; but I still recommend not going below the 70% Quality setting when recording a 3D (high-motion) game, to maintain enjoyability and clarity when using gpu-accelerated recording (such as CUDA, being used here).

 [My tests presented here are only done with CUDA, as I do not own any other videocards capable of gpu-based recording at this time. Output quality may vary when recording with AMD's App Acceleration or Intel's Quick Sync. As always, I suggest doing a few short tests yourself to see what codec and settings you personally would prefer]

What are the configuration settings that can be changed? 

There was not much available to configure, as far as the Quality settings and configuration, within the game recording application (Bandicam) at the time of this test. Certainly not as much as the x264 codec, with it's VFW interface, that has been developed over time by generous programmers/contributors. For CUDA, you can choose between Variable Bitrate and Constant Bitrate (allowing CBR if you wish to more precisely estimate the file size) if you wish, and you can utilize the CPU to assist with recording and compression as well, but that's about it. This may be a limitation in CUDA itself however, as I contacted Bandicam developers to see if there would be any deeper configuration options for the codec that CUDA is using (such as Deblocking settings and Partitions) and they got back to me stating that there were no other configuration options of that type available to include, at this time.

The interface for CUDA recording found within Bandicam's Video Format settings. 

As of the most recent version of Bandicam (announced at the Bandicam website just days ago), they have added the option to change the Keyframe Interval (the frequency of Information Frames within the Groups Of Pictures, which helps with things like 'trails' or corruption from compression) and the ability to change the FourCC identifier, both of which will make the recording more compatible with video editors such as the Sony Vegas and Adobe Premiere lines of products. I am proud to say that I did a lot of compatibility testing previous to this on my own and submitted my findings to the developers of Bandicam, just in case they were interested, which contributed directly towards this recent addition to their application. Information on my tests and findings, for those interested, can be found in these articles, here:
http://gametipsandmore.blogspot.com/2013/05/game-recording-with-mpeg-4-using.html
http://gametipsandmore.blogspot.com/2013/06/and-more-how-to-stop-trails-and.html
http://gametipsandmore.blogspot.com/2013/06/and-more-game-recording-for.html
http://gametipsandmore.blogspot.com/2013/06/and-more-how-to-record-with.html
http://www.bandicam.com/forum/viewtopic.php?f=14&t=1687&sid=06b9cdb4450af00f3d33fb4306963f6f

As always, remember that if sharing your video on streaming sites (which limit bitrate) and uploading sites (such as YouTube), your video will be recompressed [converted again] at settings much lower than your production video and detail will be lost (blurred/smoothed and show Macroblocking) due to  the nature of recompression. Therefore, if wanting to save time, there is no need to create and upload huge-bitrate, finely-detail video, as can be seen in this comparison of an uploaded YouTube video and the output that people will be seeing afterward:

A side-by-side comparison of frames extracted from the Original Uploaded Video (Left), YouTube's 1080p Compressed Video (Middle), and YouTube's 720p Compressed Video (Right), showing loss of data/detail due to recompression.
(Diablo III @ 1080p, high-motion scene, moderately-detailed game engine)
Click to see Full Size

How about performance?

I don't usually talk much about performance when I do QualityTests or TestRuns, except for maybe a short paragraph on my own experiences or a "Personal Short Version/Opinion" section at the end. The reason is, every system is different and everyone has their system configured in different ways. I could say that GPU-recording ran great for me, but then someone with a laptop running a non-dedicated videocard will tell me how wrong I am and that it doesn't run well at all. I could say it lagged me out all the time, but there would be many who could run the same thing with no problems. A quick look at any Technical Support area of any forum anywhere is evidence of the fact that even with the same hardware, there are a bunch of people who will have no problem at all and a bunch who will be having no joy. So, I mainly leave the issue aside but I sometimes mention how it seemed to run for me and [especially if anyone asks directly] I would be happy to provide more information to those who want to know more about it.

For me, performance while recording with the GPU was a mixed bag. For the most part it seemed to work fine, but there were a handful of games that just didn't like it as much. Some were choppy or laggy when I began recording. The theory is, that recording with the many cores of a GPU, processing and encoding a frame to a file should be more streamlined, but in practice it seems to take more resources from the videocard itself than I expected. Perhaps it is due to needed optimization of the games or drivers, or perhaps it is my 'older' videocards that are beginning to get on in years (I was running two GTX 560 Ti's in SLI mode during these tests). I did find that some games preferred non-SLI mode when recording with CUDA (such as Diablo III, if I remember correctly) and things were smoother when recording that way; but for the most part, accelerated recording ran with about the same responsiveness as [and in some games, slower than] my own optimized settings for the x264 iteration of AVC. Not long ago, I spent a bunch of time testing and tweaking x264 to record with the H.264/AVC codec, finding the best settings for speed while maintaining quality - and in light of the performance I was able to tweak out of x264 - GPU-based-recording didn't impress me much [if talking strictly about performance hit here]... perhaps I'll end up just using my settings with x264, for now.

For more information, tests and tweaks that I did over time with h.264/AVC and the x264 codec, feel free to check out these articles here at the blog (some are the same as the above asection):

http://gametipsandmore.blogspot.ca/2013/05/game-recording-with-mpeg-4-using.html

http://gametipsandmore.blogspot.ca/2013/06/and-more-how-to-record-with.html

http://gametipsandmore.blogspot.ca/2013/07/quality-test-h264avc-game-recording-2k.html

An example of an NVIDIA CUDA encoded game recording, this is a frame extracted from the CUDA-produced output file (Allods @ 1080p). Click to see Full Size

Overall, recording with gpu-acceleration was pleasantly surprising. Quality (at 100%) was better than I expected from it (it does taper off quickly as you lower the quality setting, however). The file sizes were comfortably small (about 25GB for an hour of recording at 70% Quality, about 45GB for an hour of recording at 100% Quality). The performance was a mixed bag for me, but for most games it was indeed fast and could get the job done. So, in essence, it managed to deliver on all promises. Not bad at all.

Have fun recording with your GPU and See You In The Games!