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...
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 |
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!
No comments:
Post a Comment