MSI AfterBurner Overclock Application Discussion forum This forum is intended for MSI customers for questions on the AfterBurner Overclock Utility based off Rivatuner. In this section the users help each other out with answers as well as support staff from MSI.

I am trying to find the best settings for recording gameplay videos with the smallest FPS hit.

When I record with "Video Format: Uncompressed" I naturally get the best quality (and file sizes in the stratosphere)

MJPG Compression works well and is what I will fall back on if I can't figure out what my problems are with x264vfw.

If I set the Video Format: x264vfw H.264 in Afterburner settings, and then in the sub options to these settings I get half decent video, but no audio (this only happens when the OUTPUT MODE is set to FILE)

If I change it to OUTPUT MODE VFW I get both audio and video. The Video plays back fine in VLC player but if I import the AVI file into Sony Vegas I get massive video issues. This video plays fine in VLC.

I'll be the first to admit I don't really have a clue what I am doing (I've tried searching Google but I can't find anything), I don't know what half the options on the x264vfw config options page even do.

My main question is; Why do the videos set to use the x264vfw codec and OUTPUT MODE VFW get corrupted when trying to edit them in Sony Vegas? Why do I get good picture but no audio when set to OUTPUT MODE FILE.

What are the "best" settings to set these too to get a good quality video (YouTube 720p Quality is all I need).

I've tried searching to see what these options do but I can't really find anything at all specific to using this with Afterburner.

Considering the settings, it's possible that the resulting video has compression artifacts that are just THAT bad. Maybe try a higher quantizer?

Also, try just loading that video in VirtualDub and see if it shows properly there (scroll around the video). If it shows properly in VirtualDub, it's a Sony Vegas problem. If that's the problem, you might want to recode the video to something lossless (like Lagarith) from the .mp4 you record with MSI afterburner. Then try loading the Lagarith video in Sony Vegas again.

x264vfw is a x264 hack, it is not officially supported (hasn't been for something like 6 years). The hack method is a third party workaround, and doesn't work as well as the proper CLI method.

On the issue of audio, x264 is a video encoder, not an audio encoder! Video and audio streams are actually independent of each other, it is only the container (avi, which is deprecated, mp4, mkv etc) that links the two together. Video encoders can encode audio only if there is a separate audio encoder component to the encoder, but it is still independent of the video.

Another thing, on-the-fly encoding is far from optimal, so you either end up with a very large file or low quality encode. By far the best solution is to capture it in a very high quality format then re-encode it later using a program like Staxrip, Handbrake etc. They are encoder frontends that automate the encoding process, best results are obtained if you update the individual components and choose the settings to match your preferences.

To summarise, just capture in say, MJpeg, then re-encode using a proper encoder later

Considering the settings, it's possible that the resulting video has compression artifacts that are just THAT bad. Maybe try a higher quantizer?

Also, try just loading that video in VirtualDub and see if it shows properly there (scroll around the video). If it shows properly in VirtualDub, it's a Sony Vegas problem. If that's the problem, you might want to recode the video to something lossless (like Lagarith) from the .mp4 you record with MSI afterburner. Then try loading the Lagarith video in Sony Vegas again.

The video plays fine in VLC and Media Player Classic so I don't think it's the video at fault. It's probably vegas's fault

Quote:

Originally Posted by thatguy91

x264vfw is a x264 hack, it is not officially supported (hasn't been for something like 6 years). The hack method is a third party workaround, and doesn't work as well as the proper CLI method.

On the issue of audio, x264 is a video encoder, not an audio encoder! Video and audio streams are actually independent of each other, it is only the container (avi, which is deprecated, mp4, mkv etc) that links the two together. Video encoders can encode audio only if there is a separate audio encoder component to the encoder, but it is still independent of the video.

Another thing, on-the-fly encoding is far from optimal, so you either end up with a very large file or low quality encode. By far the best solution is to capture it in a very high quality format then re-encode it later using a program like Staxrip, Handbrake etc. They are encoder frontends that automate the encoding process, best results are obtained if you update the individual components and choose the settings to match your preferences.

To summarise, just capture in say, MJpeg, then re-encode using a proper encoder later

Thanks, I was not aware it was video only.

Quote:

Originally Posted by Cold Fussion

You need to setup the x264 for intraframe recording to avoid this problem.

I have no idea what this means. What setting to I change to set it up this way?

With a codec like x264, there is only 1 complete frame every x number of frames, and all preceding frames depend partially on the information of other preceding frames and the reference frame. Once editing takes place, you destroy the dependencies and the whole thing goes bad. When you run in intraframe mode, every frame is a standalone frame with no dependencies on other frames for the information. You'll also probably notice very poor scrubbing performance when working with interframe x264. I suggest you google how to set it up because I don't remember off the top off my head. It's one command line option as well as setting the GOP sizes to 1.

h.264 or any other compression using delta frames is not the best choice for videocapture, if you're going to edit videos later. MJPG or any other format where is frame is compressed (and can be decompressed) independently are intended for subsequent video editing, each video capture tutorial is telling you so.

h.264 or any other compression using delta frames is not the best choice for videocapture, if you're going to edit videos later. MJPG or any other format where is frame is compressed (and can be decompressed) independently are intended for subsequent video editing, each video capture tutorial is telling you so.

Quote:

Originally Posted by Cold Fussion

It's not difficult. Put --keyint 1 in the command line and set both GOP options to 1.

Thanks for the explanations. I got it working it seems

I did a test, one with the x264vfw encoder (at the best settings I manged to get for minimal FPS hit) capturing at 1920x1200 for 30 seconds and MJPG at 100% quality for 30 seconds. I was able to basically stand still overlooking a base in Just Cause 2 (it was nice, since I was able to ALT-TAB out, change the capture settings in Afterburner to the other encoder, and ALT-TAB back in without moving in game so the 30 second captures are identical) and do the test.

The quality was almost identical (with a slight advantage to MJPG, but for YouTube videos it shouldn't matter) but the filesizes...

The 30 second x264 clip was 264Mb, the 30 second MJEG was 1.7 GB

The x264 is fully editable in Sony Vegas now too.

If there was anyway to give rep on this forum I'd do it. Thanks for the help.

Like I said before, the filesizes are large due to the nature of on-the-fly capturing You should capture first, edit (if required), then compress with your desired audio and video decoder.

The difference is that with x264 intra, you get 1gig/10 minutes of video recording with crf 18 with acceptable quality. Recording large amount of of mjpeg or with any loseless codec will be 10s-100s of gigs of data just to record a 30 minute round of BF3, which is unacceptable if you need to capture a large amount of data to get what you desire.

One thing to consider is that you will want to have the recording HDD be separate from your OS/program drive. Problems with low performance during recording (especially uncompressed/lightly compressed) might be due to this.

Hi, I'm playing around with capturing game video using MSI Afterburner 2.3.0 and x264vfw as well, I've run into some of the same stuff but not entirely. Here's my experience:

Outputting to VFW (as opposed to file) produces corrupted video like you posted, but the log window will appear with no details and time out if you try to interact with it. Stopping recording will make it disappear. Using --keyint 1 makes the video not corrupt, but the video file is very choppy compared to letting the codec output to it's own file.

Outputting to file through x264vfw works fairly well if you don't care about game sound, like me, but Afterburner will still make it's own files, and they'll be blank with no video, but take up roughly the same space as the real file. I haven't found a way to stop this from happening. Another problem with this solution is that if you stop and start recording, the first file will be overwritten.

I haven't really been able to find any guides on how to set up this kind of recording, but I hope someone looks at it, because the file size output + lack of performance hit + quality seems really good.

Edit: A hacky sort of solution to the Afterburner file output problem is to set all settings to the lowest they'll go, record a segment to VFW, and then set your real settings to output to file in x264vfw. Afterburner will output files with the old spec, so they'll be in the KB size range while you will have the real output in a seperate file.

Like I said before, x264vfw is unofficial and requires dodgy workarounds to work properly. It is unsupported and know to cause issues! It doesn't mean it doesn't work in certain circumstances, but it does mean that issues with the video shouldn't be unexpected. The quality of the encoding may also be lower.

Like I said before, x264vfw is unofficial and requires dodgy workarounds to work properly. It is unsupported and know to cause issues! It doesn't mean it doesn't work in certain circumstances, but it does mean that issues with the video shouldn't be unexpected. The quality of the encoding may also be lower.

Wrong. It is not a question of "unofficial" x264vfw. It is a question of poor support of editing videos in AVI container with delta-frame compression in Vegas. Videos are fine and not "corrupted", Vegas is just unable to decompress independent frames properly.

x264cli is perfect for compression after recording. And cli writes in a container which at least is able to handle and support all h.264 features, which avi doesnt do.. H.264 has to be in MKV or MP4, but not avi ..

And the 2nd thing is: Why? Why this codec as recommendation?

Why not just a simple lossless codec, which are designed for VfW, and which are perfect for avi?

Lagarith Lossless Codec for example. Set its mode to YV12 and checkmark Multithreading and you have a very fast recording performance and very good compression.
or if you have very fast storage, you could choose other codec which compresses softer, but has due to this less cpu usage.

Wrong. It is not a question of "unofficial" x264vfw. It is a question of poor support of editing videos in AVI container with delta-frame compression in Vegas. Videos are fine and not "corrupted", Vegas is just unable to decompress independent frames properly.

I Agree here.
Vegas just can digest almost anything correctly unless it's fully uncompressed or lossless compressed with proper codecs.

That's is why I use AviSynth.

Quote:

Originally Posted by De-M-oN

Why you recommend THAT codec at your page? ..

x264cli is perfect for compression after recording. And cli writes in a container which at least is able to handle and support all h.264 features, which avi doesnt do.. H.264 has to be in MKV or MP4, but not avi ..

And the 2nd thing is: Why? Why this codec as recommendation?

Why not just a simple lossless codec, which are designed for VfW, and which are perfect for avi?

Lagarith Lossless Codec for example. Set its mode to YV12 and checkmark Multithreading and you have a very fast recording performance and very good compression.
or if you have very fast storage, you could choose other codec which compresses softer, but has due to this less cpu usage.

But x264vfw .. bad choice. Why you recommend that?

Agreed here too.

Lagarith is an awesome codec. I use it to capture footage from my old VHS camcorder to lossless and then to MPEG2 Element and then to DVD-VOB
I also recommend it to anyone who wants a fast lossless codec for capturing anything you can Imagine.

Because it is a question of personal preferences. Some people prefer the best compression rate and just store the video or upload it without editing so x264vfw is the best choice for them. Others prefer the best performance and minimum performance hit during gaming so RTV1/MJPG is their choice. Some people are crazy about capturing lossless video so their choice is Lagarith. And none of those choices can be called "right" or "wrong".

People who just want to store the video should record lossless and then encode with x264cli. a GUI for x264 is free too and a good GUI is for example MeGUI. So you encode your recorded lagarith file with for example MeGUI and have it in a suitable H.264 container.

You should in no way recommend a vfw lossy codec. AVI is very bad for H.264 and other lossy codecs which are usable with AVI have bad efficiency.
Also: The CPU load is way higher than with a lossless codec (except maybe for MJPG/RTV1)

On your page you're also not going into this. You recommend it as the one and only vfw codec as to be recommended.

If you want to recommend something, then you should indeed recommend lagarith or any other lossless codec. You should recommend which is the best method. And the best method is lossless record and lossy encode after recording. Thats the optimal way.
And the most people with a little bit knowledge want it this way.

If you still want to mention x264vfw, then at least do more examples and mention what you wrote here. maybe like this: People who like to have that, can use that, and people who like that, use that etc.

At the moment it looks like as a best for all people recommendation.

I say: its for nobody the solution.

x264vfw recording wont be very fast performance, especially if you encode lossy with b-frames and so on, avi not suitable for H.264.
You recommend a ultrafast preset recording. You sure recommend then a lossless recording too, right? Then let the people record in lagarith and encode afterwards with x264cli and so you havent to record with very bad ingame performance while recording, and you dont have that very inefficient bad compressed lossy coding..

x264vfw is in any way suboptimal for everyone.

No one wants bad recording performance, no one wants bad encoding efficiency

People who just want to store the video should record lossless and then encode with x264cli.

Many people record a lot of video during gaming and prefer to compress it on the fly with maximum possible compression ratio to avoid flooding HDD with gigabytes of uncompressed or lossless data. So no need to tell what people should do, you're personal preferences are not the only ones.

Quote:

Originally Posted by De-M-oN

You should in no way recommend a vfw lossy codec. AVI is very bad for H.264 and other lossy codecs which are usable with AVI have bad efficiency.

Please let me decide myself what should I recommend to others. This solution provides tbe best compression ratio and it has pros and cons like any other.

Quote:

Originally Posted by De-M-oN

Also: The CPU load is way higher than with a lossless codec (except maybe for MJPG/RTV1)

You forgot to add "and way higher compression ratio" to it.

Quote:

Originally Posted by De-M-oN

On your page you're also not going into this. You recommend it as the one and only vfw codec as to be recommended.

I don't know what do you mean by "my page", I don't host any webpages and post info only in the forum or in MSI Afterburner readme/context help system. And both of them say the following:

o External VFW codecs support. Now in addition to built-in uncompressed, RTV1 and MJPG encoders it is also possible to encode video using external VFW codecs installed in the system. It is recommended to download, install and use Lagarith Lossless Codec for lossless video capturing or x264vfw codec for the maximum compression ratio, MSI Afterburner was developed to provide the best compatibility with these codecs

So maybe you should just RTFM instead of pushing your preferences that aggressively?

On the fly encoding of any video is never going to be high quality. The suggestion of recording video in Lagirith first then re-encode later isn't a bad one. If you record to x264 on the fly, I can absolutely guarantee 100 percent that either the quality won't be as good as it could be, possibly noticeably so, or the filesize will be much larger than what it would be otherwise.

There are times when x264vfw may simply not work as expected not just because it isn't officially supported, but for the reason why it isn't officially supported. To work with vfw, some less than ideal code 'hacks' were used (apparently) that can never guarantee a perfectly successful encode all the time. To get to a high quality x264 output on the fly, you have to use settings that are conducive to much larger file sizes. Whilst this isn't a problem per se, it does mean you have to edit it later and re-encode if you want to distribute it. Re-encoding a lossy picture is like making a photocopy of a photocopy, you are not only encoding and introducing new artifacts, you are literally encoding artifacts that ere already part of the picture. If you record in a lossless format, when you re-encode it will be like photocopying off the master.

So, if you do use x264vfw, you still have to re-encode anyway as you can drastically reduce the filesize. The higher resolution and better quality on-the-fly recording you do, the smaller you can get the filesize with the re-encoding. If you have the resolution and quality at a level that is actually good for an encode, you would either be clueless or lazy to distribute them online etc. If you have the resolution and quality settings such that the file size isn't too excessive, then the video won't really look too good!

Like I said, if you disagree with this, argue it over in the x264 development thread (or open a new thread) on the Doom9 forum. You can argue directly with the lead programmer of x264 there, as well as a significant number of other users that know more about x264 specifically, and encoding than you do

Can both of you stop this useless flaming please? If x264vfw doesn't suit your needs, just don't use it, it is simple as ABC. It doesn't make it useless for others though, it is just not your way, but it absolutely doesn't mean that others have to follow your way.