Showing posts with label editing. Show all posts
Showing posts with label editing. Show all posts

Sunday, December 07, 2014

And More, Quick Tip: HitFilm Effects 'Stop Working' or 'Not Working When Reopening Projects' in Sony Vegas 13

Just a Quick Tip, for those using Sony's Vegas line of products for editing. I was working in a recently-upgraded-to Movie Studio 13 Platinum, enjoying the new version and trying the FXHOME HitFilm Effects plug-ins that come with it. Then, the plug-in effects seemed to stop working today - they didn't show the effects in the Preview at all when I re-opened the Project. I could open the Settings Panel for the plug-ins and change them, but could not 'see' the HitFilm effects. I made a few recent changes to my System, one of them being upgrading my NVIDIA GPU drivers. So, I rolled them back, installing an older version (going back to 332.21 - a version I chose so that I could also use CUDA for Rendering, among other things) and boom - the Hitfilm effects were back ...to the future ...with a vengeance ok I'll stop. So, if anyone else runs into this problem with these HitFilm Effects and Vegas [it may help no matter what Edition you have installed], try rolling back the GPU drivers.


[N.B.: This issue was encountered and solved on my NVIDIA GPU,
it is unknown by myself, at this time, whether this issue exists with AMD/ATi GPUs]

Have fun editing your gameplay adventures - and See You In The Games!


Thursday, October 23, 2014

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!

Sunday, May 18, 2014

'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 Benchmark1366x768~ 2 fps
Hitman: Absolution Benchmark2560x1440~ 4 fps
FurMark (Full Run)1366x768~ 2 fps
FurMark (Full Run)2560x1440~ 0 fps
Unigine Valley Benchmark1366x768~ 6 fps
Unigine Valley Benchmark2560x1440-
Batman: Arkham City Benchmark1366x768~ 4 fps
Batman: Arkham City Benchmark2560x1440~ 9 fps
Skyrim (Introduction)1366x768~ 0-8 fps
Skyrim (Introduction)2560x1440-
Minecraft1366x768~ 0 fps
Minecraft2560x1440~ 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 Benchmark1366x768~ 34 Mbps, 0.97GB/hour
Hitman: Absolution Benchmark2560x1440~ 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 Benchmark1366x768~ 37 Mbps, 1.06GB/hour
Unigine Valley Benchmark2560x1440-
Batman: Arkham City Benchmark1366x768~ 20 Mbps, 0.57GB/hour
Batman: Arkham City Benchmark2560x1440~ 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"]

Wednesday, June 12, 2013

And More: How to record with H.264/AVC/x264/x264vfw (MPEG-4 Part 10) so that your video clips will open in Sony Vegas and Adobe Premiere (Short Tutorial/Example Video)


Originally created to show an example of what to change so that your game recordings using the H.264/AVC/x264/x264vfw (MPEG-4 Part 10) codec will open up in Vegas, this also works for Premiere, Lightworks and other NLE's (Non-Linear Editors), for those who were having problems editing.

In this example*, I am recording with an x264vfw (Komisar's Unofficial, Black Logo) interface**, which sets up h.264/AVC encoding, used as an "External Codec" in Bandicam:

*Just a silly version of the video, sorry for taking up your time with this little joke
Summary of Video: Within the x264 Video For Windows interface, change the FourCC code that x264 is recording with [think of it as the 'UPC label' or 'QR tag' for the videos] to a code that these video editing apps can recognize natively. That's all.
Now, you should be able to import all your future game recordings into Vegas and Premiere without problem...


Ok, for a truly easy-to-follow video, that shows examples of how to set the code for Bandicam, Dxtory and Afterburner, look no further than here:

The true version of the video, showing how to adjust the setting required


As you can see, because the main setting to change occurs within the x264vfw interface itself, this change can be utilized no matter what game recording program you prefer to record with (Bandicam, Dxtory, MSI Afterburner, etc.)


**If you are using the 'Official' version of the x264vfw codec interface (Red Logo), the setting to change is indicated in this screenshot below:



»» Note: 
When editing the x264vfw codec with NLEs (Non-Linear Editors) such as Sony's Vegas line of products and Adobe's Premiere applications, you may experience artifacts such as 'trails' or 'corruption' unless you set the GOP setting to "1", which will make "Intra-frame only" encodes. This will encode frames that do not depend on surrounding frames, containing all necessary data within each frame itself (similar to how the MJPEG codec operates, requiring more bitrate/filesize, but MPEG-4 still uses less bitrate overall), which alleviates this problem.

This seems to only occur with Vegas, Premiere, Lightworks and similar products when using MPEG4, but does not occur with most other video editing applications (tested with Windows Movie Maker, CyberLink's PowerDirector, Nero Video, Avidemux, VirtualDub, etc), so you could always extract the portions of the video you want from your recordings with those, then import your portions into Vegas/Premiere/etc and finalize your video projects that way. However, to omit having to do that extra step, you can have your H.264/AVC (x264) recordings editable in Vegas/Premiere/etc by doing the following:

For the Official (Red Logo) x264vfw interface, add "--keyint 1" (without quotations) into the Extra Command area at the bottom
For The Unofficial (Black Logo) x264vfw interface, set the Maximum GO Size to "1"


***
A lengthy article, talking about recording with x264/H.264/AVC in detail (testing settings, recommendations for speed, etc.) can be found at the blog here:
http://gametipsandmore.blogspot.ca/2013/05/game-recording-with-mpeg-4-using.html

***


Have fun editing and See You In The Games!


Tuesday, June 11, 2013

And More: Game Recording for Compatibility with Video Editing Programs (Text-Only Version)


Just some quick tips for recording your gaming adventures, so that no matter what recording or editing program you use, you can open the recorded file and edit it without any problems:

Most game recording programs will automatically install CODECs (COmpressor/DECompressors) when you install the program itself. Codecs can be thought of as 'handlers' for the video and audio formats that the program will 'prefer' [that is, formats that they were programmed with], so that you can open them in video editing applications. Also, most video editing apps can read certain widely-accepted/standardized formats such as MJPEG, RGB, YV12, Uncompressed, and so on, "natively" (without installing any additional codecs, once you install the video editing program itself). The thing is, sometimes there is a format that is selectable or useable in a recording application and then you can find out later that your video editing application "doesn't like it" (won't open your recorded file)...

To solve this problem, you can do a few things (in order of ease-of-use):

  • Change the format you are recording with.
[This also works if you don't want/can't install any additional codecs on the system]
All you have to do is switch the recording codec you are using to something that the editor can easily open. If your recording cannot easily be imported into your video editor, take a look at the 'importable formats' that are listed for your video editing application at the manufacturer's website.
You can also just do a couple of short test recordings to find out what can be recorded to and opened by your favourite editing app without problem. You may, for instance, test with a short recording and find that only the video (or only the audio) can be opened. This means you just have to check what formats you are recording with and switch out the one that is not being read properly. 
For example:

Problem: Sony Vegas opening a recorded file and the video track is fine but the audio has only a small 'sliver' of data (no sound track)
Fix: Change the audio recording format to Uncompressed PCM Audio
Now Sony Vegas can properly open both the video and audio portions of the recording (without installing any additional codecs) - all solved by merely switching to using a different codec for recording

  • Install the codec you wish you use.
A recording program may offer a format that you can record with, but it may not automatically install the decoder portion for it, so you may have to download and install the codec package in order to open the recordings.
Some examples:

Some find that when using the MJPEG codec offered within MSI's Afterburner program to record, they cannot open the MJPEG format recorded files in their video editing application. Within MSI Afterburner, there is an option to enable an MJPEG decoder within it, if it is needed (it shouldn't be, since most video editing programs support MJPEG natively (it is just a sequence of JPGs))

Some find that when using the Xvid codec offered within Bandicam to record, they cannot open the Xvid format recorded files in their video editing application. To solve this, merely download the Xvid codec package from the Xvid.org website and then you should be able to open the Xvid recorded files in your video editing program

  • Convert the recorded file into a format that the video editing app can open without problem.
Most editing programs have a list of 'compatible' formats that it was programmed to open natively [without installing anything else]. From the list, choose a format that is easy for you to convert your recordings into, so that you can easily import them into your video editing application.

To convert your recordings, you can use the conversion program that came with your camera or multimedia device, if it came with one. There are also many freeware programs that you can use, such as:

Avidemux
Virtualdub
FormatFactory
Xvid4PSP
Xmedia Recode
Nero Recode
WinFF
and more
Simply use the one that you find easiest to use and convert your files with. You can also purchase a video editing program/software suite that will allow you to convert/edit the recordings.

Once you try one of the above steps (listed in order of easiest/quickest first), you should find importing your recordings into your favourite editing apps going a lot smoother and having less problems/glitches when starting your editing.


Good luck with it and Have Fun editing your gaming adventures!


Wednesday, June 13, 2012

GTAM Minute Tutorial - Editing Textures (Repairing A Deleted Branch In Leaves) with The GIMP

Playing around with editing textures for Minecraft (Tutorials on how to do that Coming Soon!) something happened that I think others would run into - it was a pretty minor/specific thing, but I'd like to share what I did and how I fixed it, just in case anyone ever runs into this little problem.


The GIMP (GNU Image Manipulation Program, changed from General Image Manipulation Program) is a free editing application that is quite capable to stand up against most of the functions of Adobe's Photoshop and similar programs. Using it to edit the general Leaf texture portions of Minecraft's texture source, I accidentally selected and deleted a section of branch. Wanting to change the colour anyway, I replaced it but then thought that this might be something that could happen to other people, especially those new to graphic editing. I wanted to erase it again and record what I had done to repair the poor deleted branch and share it.

Perhaps for you it was deleted and then the file was saved, or perhaps you didn't notice it until a later step, where it was then inaccessible as a layer or similar problem. No matter what the situation, if anyone happens to run into this specific minor misfortune or even similar, it has spawned what will now become the first in a new series of videos I'd like to start, called Game Tips And More Minute Tutorials.

GTAM Minute Tutorials will be very short (60 seconds or less!) instructions showing how to do something very specific. I don't mean completing a quest or mission, I mean one thing, or at least a small number of steps, that complete one specific task. It may be editing or troubleshooting (the "And More" portion of this blog's namesake) or it may be how to jump high or shoot something in a specific game. Whatever it may be, in this time of short attention spans (who doesn't get crabby when the computer takes more than a second to do what you just told it?), all the tutorials/walkthroughs will be less than one minute. Really. Guaranteed! Not really.

In this tutorial, I show how to easily replace a deleted branch in a photo of leaves. That is something pretty specific; but the concepts presented, such as shading, blending and some general GIMP usage can be applied to many other situations and projects as well:


It is played back at 4x speed and states the steps being taken and basic concepts behind them. Being very specific in nature, not a lot of extra information is given, but this video is targeted towards people already editing [Minecraft textures for instance] and familiar with programs and games such as GIMP and Minecraft.
(I would like to do a full tutorial on how to extract, edit, import and save your own textures for use in Minecraft in the future)

Recorded with: Bandicam
- 'Rectangle On A Screen', 'For Edit Premiere/Sony Vegas' Preset
- 1280x720 (720p HD), 60fps, no Audio
- compressed to 720p, 30fps, 10Mbps, h.264/AVC for smaller upload size


Check back for more Game Tips And More Minute Tutorials in the future and See you in the games!