Widescreen Gaming Forum

Hmmm, I must have missed what was said earlier, because I thought you meant compressing with VDub, which is what I use it for. I always thought the capture feature was only usable with external devices, such as camcorders. Does it capture via software now too, like Fraps, but without the cap?

The guide I've posted has much more detail, but yes, VDub can record any on-screen activity via a screen capture driver. It is my preferred recording method since it doesn't artificially leash fps and it offers complete control over resolution, framerate, and codec/quality/filesize settings. It's not as simple to use as Fraps, PlayClaw, etc., but I can have it set up and ready to record in less than a minute when I want some game footage.

The guide I've posted has much more detail, but yes, VDub can record any on-screen activity via a screen capture driver. It is my preferred recording method since it doesn't artificially leash fps and it offers complete control over resolution, framerate, and codec/quality/filesize settings. It's not as simple to use as Fraps, PlayClaw, etc., but I can have it set up and ready to record in less than a minute when I want some game footage.

You must have responded before I edited my above post following reading your guide. I'm not really too worried about setup time. I know full well from having compressed with VDub a lot that initial setup on such things is a one time thing, then just retuning the compression rate a bit per game.

I'm mainly concerned about my spec not being robust enough to make use of the main benefits you speak of, like compressing while capturing, and resizing the res. I have such low spec that I usually anymore have to resize the res upon compression after capturing. Keeping the res small (512x320, 512x384) while capturing keeps my frame rates from plummeting too much.

I'll probably revisit your guide after building my new rig. I'm thinking of holding out for a DX11 GPU, but everything else I want is pretty much available, though I AM interested in the new e-IPS displays coming out too, esp if they make something bigger than 24" in 16:9. Thanks for taking the time to write such a beautiful guide.

As for the feedback you spoke of, there is really only one minor thing I noticed that seemed a bit out of place. Under Benefits you listed this:

"Tweaking game settings can directly improve capture performance. Often just turning down/off things like HDR, bloom, or post-effects can be enough to achieve a smooth playing/recording experience."

That is more a general tip for capturing with ANY app, not a specific benefit of VDub. :wink:

@Dopefish,
IMO, the one doing the capture should make sure what goes into the capture app is good in the first place, that includes screen tear. Often times the capping Fraps does lowers the FPS more than a game's built in VSync option. There's also many games that don't exhibit screen tear problems at all. In those games Fraps is lowering FPS for no reason.

Fraps will cap the FPS to whatever you choose to record at. If you choose to record at 30fps, it will cap it to 30. The same goes for any other FPS you choose. Fraps does this by hooking the game, forcing it's own vblank, and pulling from the frame buffer. This is the only way to guarantee you will not have frame-tearing. It's also the only way to guarantee consistency in every frame.

Applications that just capture the screen, ignoring vblank, will capture tearing if it happens. There's no way around it. They are simply capturing what is being displayed to the screen. So if frames are partially getting overwritten in the frame buffer before being displayed, then they are going to be captured that way.

As for the games that don't exhibit frame tearing, then it's still a good idea to capture at a specific frame rate so every frame is consistent. If you are playing a game that varies in frame rates between different scenes, then taking a shot every so often is just going to make un-smooth captures because there is no consistency. In many games, a lot of animations, physics, and other things are tied to a different framerate than what's being displayed. In most games, animations of players, weapons, etc. are all 30 fps, whether you are getting 120 fps in the game or not. Capturing a frame here and a frame there will just cause things to look out of place because it's unlocked and not entirely in sync.

Yes, Fraps imposing its own vblank can hurt performance and input response, but it's for a good cause. If you're serious about quality, then the best thing to do is record a demo, play back the demo and record that.

Bottom line, I'd rather have the choice of using VSync or not, and have a capture tool capable of allowing you to play at frame rates well above what it's recording at.

Choices are a good thing, I'll agree with you on that. It would be nice to have that option. However, I think it might also be misleading. People will disable it because they get better frames, and then we'll end up with even worse videos online. ;)

I really only recall one race recording with Fraps going from the hills in the NW to the naval yard in the south that was hard to drive due to lag. It was mainly on the section of road that has a divider where there was lots of traffic and race carnage.

You have to keep in mind that lag in Fraps isn't always necessarily due to capturing and/or what's going on on the screen. It's consistently writing massive amounts of data to the drives. If there's a hiccup anywhere in the writing, you're going to feel it in game. Always make sure you record to a different drive entirely (one that has nothing being read or written to/from) and that it is completely defragged before you begin.

The 20 FPS video I shot not only plays less smoothly due to less frames, it had one big skip in it where I was heading toward a tunnel on a dirt shortcut. There was numerous identical frames recorded about 50 meters before the tunnel, then the next frame I was right at the tunnel entrance. I would guess that it was due to erratic frame rates whilst entering an area that had to suddenly draw lots of new structure into view. The drop in FPS must have resulted in the number of skipped frames approaching the number of captured frames and choked the app.

This has to do with what I said about and everything being in sync/consistent. If the app hooked the game and set its own vblank, this wouldn't happen. When it's just capturing the screen on its own, there's a lot of possibility for inconsistencies. This includes duplicate frames, missing frames, missing segments, audio/video sync issues, etc.

You must have responded before I edited my above post following reading your guide.
Yup.

Your guide is excellent and I'm sure it's useful to many with fairly robust spec, but I'm doubting it will be of use to me until I build a new rig, maybe by year's end.
Thanks for the compliments. I hope you will find my guide useful, though I can see why you would want to wait for a new rig before giving it a good run through.

Of those the HL2 one was the only one that had what looked like acceptable image quality to me, though it's playback was not smooth. I also noticed a thin whitish-gray line at the left and bottom of the screen and the audio ends well before the video.
The white/gray line was probably a sloppy capture alignment to the game window on my part. Those clips are little more than rough captures just trimmed for time.

As far as image quality goes, having your choice of codec and compression settings open allows for whatever you want. I happen to prefer slightly compressed MJPEG for casual recordings because the quality is good enough for me and I save a TON of disk space. If I want higher quality I can bump the MJPEG compression slider to 0 or just go with a true lossless codec like Huffyuv, Lagarith, or even Xfire, which is accessible through Vdub. Just remember that at higher resolutions truly uncompressed video ceases to become an option simply because hard drives can't keep up (see the math I posted previously).

Seems to me if I try to compress while capturing, it will bog down the CPU too much.
Yes, it does place demands on the CPU, but that depends greatly on the codec. PicVideo's MJPEG codec is known widely as one of the fastest compressors around. Towards the bottom of my guide you can see encoding test results where it spanks every other codec handsomely. If the Fraps compressor wasn't locked to the application I would have tested it as well, though I expect it would perform just as good or perhaps better than MJPEG.

Here is a 90 second clip of Left4Dead: (20MB, Xvid+MP3). I played the game in surround but recorded only the center of the screens in a 16:10 AR. FYI, part of what may look like choppy motion is my tendency to jerk the mouse when I want to turn my character. I never realized I played like that until I started watching my own videos, and in a game like L4D I do it a LOT.

Random note: something else possible using the Vdub/screen capture driver method is setting up a realtime video broadcast of your game. I've done a rudimentary test using Windows Media Encoder, but I'm sure there are better video streaming/server setups available.

I'm going to try to answer Dopefish's and GeneralAdmission's responses in this post, so bear with me.

Fraps will cap the FPS to whatever you choose to record at. If you choose to record at 30fps, it will cap it to 30. The same goes for any other FPS you choose.

This I, and I'm sure most Fraps users are well aware of. I have owned it and been using it for some time.

Fraps does this by hooking the game, forcing it's own vblank, and pulling from the frame buffer. This is the only way to guarantee you will not have frame-tearing.

Here you give the same example of the tradeoffs as before, which I maintain, can be delt with in game or may not even be a problem, depending whether the game has tear issues or not.

As for the games that don't exhibit frame tearing, then it's still a good idea to capture at a specific frame rate so every frame is consistent. If you are playing a game that varies in frame rates between different scenes, then taking a shot every so often is just going to make un-smooth captures because there is no consistency. In many games, a lot of animations, physics, and other things are tied to a different framerate than what's being displayed. In most games, animations of players, weapons, etc. are all 30 fps, whether you are getting 120 fps in the game or not. Capturing a frame here and a frame there will just cause things to look out of place because it's unlocked and not entirely in sync.

Here you give a better example IMO, and in my PlayClaw/Fraps shootout using identical FPS, gameplay segment (of Burnout Paradise), in game TOD setting and duration, I did notice something other than just hitching that must no doubt be due to this. Many times whilst striking a small street sign pole using PlayClaw, the playback video would skip, possibly due to the physics frame rate you were referring to.

Yes, Fraps imposing its own vblank can hurt performance and input response, but it's for a good cause. If you're serious about quality, then the best thing to do is record a demo, play back the demo and record that.

Yeah, I always use a game's demo record and/or replay feature if I can, but that is more often the exception than the norm. I used to think that the apps that allow higher gameplay FPS would be MORE beneficial than Fraps in games that I can barely record with Fraps, but now, realistically, I think they're only beneficial in games I CAN'T record with Fraps. Burnout Paradise plays at pretty good FPS even on my aging P4, X1950 rig. If I'd chosen a game that is too hard to play while recording with Fraps, the test would have been more in favor of PlayClaw no doubt. So I WILL keep the app just for those instances.

Choices are a good thing, I'll agree with you on that. It would be nice to have that option. However, I think it might also be misleading. People will disable it because they get better frames, and then we'll end up with even worse videos online.

It's not misleading if you keep the above what I just said in mind. It comes in handy for games that Fraps simply gives you too low FPS to play well while capturing.

You have to keep in mind that lag in Fraps isn't always necessarily due to capturing and/or what's going on on the screen. It's consistently writing massive amounts of data to the drives. If there's a hiccup anywhere in the writing, you're going to feel it in game. Always make sure you record to a different drive entirely (one that has nothing being read or written to/from) and that it is completely defragged before you begin.

I was merely saying for the particular game I was using to compare apps with, there aren't many places in the game where even Fraps becomes noticeably laggy in use. And I know full well about capture/compression prep. I have been making vids for a fair time now. I religiously keep my drives defragged, background progs and non essential services shut down via AlacrityPC, and capturing to the secondary drive.

This has to do with what I said about and everything being in sync/consistent. If the app hooked the game and set its own vblank, this wouldn't happen. When it's just capturing the screen on its own, there's a lot of possibility for inconsistencies. This includes duplicate frames, missing frames, missing segments, audio/video sync issues, etc.

Again, a much better example than tearing. I'm sure this is what I'm referring to as skipping, hitching, etc, upon the PlayClaw clips being viewed. In fact I am now thinking that besides skipping less frames, Fraps use of vBlank may actually be the reason the captured clips are about half the size of the PlayClaw clips. And why am I the only one mentioning that? Surely those of you whom have compared it to Fraps have noticed the size difference.

There is talk, myth or not perhaps, of VSync cutting your frame rate in half. If that is true, perhaps it only happens in cases where the hardware is struggling to render at the chosen settings. If this is what is going on concerning capture, maybe that is why I am getting PlayClaw captures at about twice the size of the Fraps ones. Either way, I do not like the huge file sizes. Even on games that I get too low FPS to play well while capturing with Fraps, I tend to think using PlayClaw, were it a viable alternative in that instance, would get old having to reserve such HDD space.

@GeneralAdmission

PicVideo's MJPEG codec is known widely as one of the fastest compressors around. Towards the bottom of my guide you can see encoding test results where it spanks every other codec handsomely. If the Fraps compressor wasn't locked to the application I would have tested it as well, though I expect it would perform just as good or perhaps better than MJPEG

Thanks for the heads up on the codec, but given what Dopefish enlightened me to coupled with my tests verifying it, I can't say I'm a big fan of uncapped codecs right now. Still though, I'll give the one you mentioned a try eventually.

The main thing on image quality of the 3 clips I first viewed are the BF 2 and TF 2 ones had less texture detail, though the one with good detail, HL 2, was hitchy. It appeared to me that it was more due to the kind of skipped frames hitching Dopefish referred to, not your mouse hand.

The L4D clip was very nice though, much better overall. Perhaps it has to do with it being much smaller res. I did watch it in KMPlayer though, whereas I watched the others in WMP. That game is awesome, and though the res was smaller on that clip, it fit the mood perfectly with KMPlayer's jet black backdrop.

I have come to the conclusion so far that apps that don't cap FPS, while being smooth in gameplay, often struggle at the capture end with too many skipped frames, identical frames, and physics anomalies.

Thus I am feeling that you really need robust enough hardware to be able to capture with Fraps at a good 40 FPS at your desired settings to get consistently smooth results, unless the game is very playable at 30 or 35 FPS.

Thanks for the responses guys. I'm about to finish uploading those Fraps/PlayClaw test result clips, as well as a solo PlayClaw clip demonstrating an ultra low FPS setting (20) for those whom really need to get every frame for gameplay they can.

If you have the processing power and harddrive space, one thing I like to do if the game doesn't have demo/replay functionality is to set Fraps to record at 60 FPS. As long as you can consistently maintain 60 FPS throughout the recording, which isn't difficult if you are capturing at 720p, then you should have an easier time playing the game and recording at the same time. Once the recording is done, don't just cut the framerate down to 30 FPS because you have no idea how the software you're using is going to do that. It may cut certain frames while keeping others. The best thing to do is use something like Avisynth and use SelectEven() or SelectOdd(). This will basically select every other frame. If you captured at 60 FPS, this will cut it down to 30 FPS.


Here are my general encoding tips:
[list]
[*]Use/learn Avisynth.[/*:m]
[*]Make all of your captures at 720p (1280x720). This is probably the most common format out there online and the best suited for play on modern systems. A 2ghz C2D can handle a 720p video just fine, while it will probably struggle with a 1080p video.[/*:m]
[*]Always encode to H.264, preferably with x264. There is absolutely no reason to use anything else. Using anything else will just result in lower quality at similar or larger file sizes.[/*:m]
[*]Use built-in game recording features if they are available. Almost all Source-based games have a built-in method. The Call of Duty games also do, as well as World in Conflict.[/*:m]
[*]When working with lossless content, store it using huffyuv. You can use x264 to store it in a lossless H.264 raw stream, but with recent revisions, the frames are too large for many current applications to handle.[/*:m]
[*]Learn x264, its options, and how they affect the quality. You can often get by with some very reasonable bitrates that look amazing just by playing with some psy options.[/*:m][/list:u]

There's plenty of stuff I'm leaving off the list, but that should be enough for now. ;)

OK, I'm going to put this very bluntly, much like you did in my Burnout Paradise Videos thread I just submitted where you smugly tried to imply I'm an idiot for using Xvid.

You are obviously an elitist turd that thinks you can go around getting everyone to buy your way of making videos, which clearly only caters to those with very high end gear on the creation end and high speed net connections/patience on the receiving/downloading end.

I get the feeling you are about the only one that takes the time to watch your videos because they are no doubt too huge in file size for most to bother with. After all, I don't see you posting any here for download.

Next time think about that before you even get the crazy idea of stomping on one of my contribution threads because your head is clearly in the clouds like some rich kid spoiled to death.

I happen to know more about this than you apparently think I do, and the complexity you're suggesting is not at all necessary for mere offerings on the net for download.

In case you haven't noticed, most people totally ignore huge video files and would rather suffice with crap YouTube quality. I offer something that has much better image quality than YouTube at very reasonable file sizes.

You are offering misleading, snobbish, elitist advice, that is quite laughable really. In a nutshell you are merely exemplifying your arrogance, more than teaching anything.

Easy now.

If I may paraphrase dopefish in a more ... digestible way; have a go with AutoMKV if you haven't already (you'll need avisynth that dopefish mentioned).
It's a very good app, with preloaded profiles which allows you to load a raw FRAPS capture and simply hit convert with whatever bitrate you specify or filesize you require. x264 encodes can actually produce very small file sizes and look fantastic still, while placed in any container you want (mkv, mp4, avi etc). You can even encode with divx (h264) or xvid.

You're both correct. Your ways are simply personal preference, and arguing about that is utterly pointless, as I have a slight inkling that neither of you will back down. :P Consider the posts aimed at everyone, rather than personally to either of you, as they have decent information which would help out a lot of people !

I will do exactly the same as you Frag. Keep both apps, as there are some games that just don't play nicely with fraps !

most people [...] would rather suffice with crap YouTube quality.

Sadly your completely right. The fact that Video taped movies from the theater (CAM's) are popular on streaming sites supports that fact.

Yeah, I did get rather riled there, sorry, but as was mentioned on my contribution thread, there were attacks made that were blunt, insensitive and sarcastic, rather than constructive and very uncalled for. If one really is interested in helping others learn how best to make videos, they don't do it by scoffing, esp on contribution threads. I've seen too many beginner video makers give up because of comments like that, and I'm hardly new at this, nor tolerant to abuse.

As for the subject at hand, I have seen numerous ways suggested to convert Fraps to x264, the most common of which seems to be MeGui. There's also Winmenc. As well there's the fact that in all my searching, I've yet to see anyone PROVE that you can create a video as small in file size as Xvid can with even equal, let alone better image quality. I'm receptive to new methods that are superior, but I like to have proof before I go embarking on a much more complex process.

The only thing I really dislike about Xvid is it is too dependent on brightness levels for it's bit rate allotment. As well, when compressing, it always starts out very small in bit rate and is slow to ramp it up. Thus, if you are shooting for a small file size on a large clip and it starts out in a dark setting, the first few seconds of the video can look pixelated. I have read some very techy chat on a forum where some users were trying to figure out a way to make Xvid less dependent on brightness levels, but last I checked none had succeeded.

I apologize. I was not directly attacking you. XviD is pretty terrible when in comes to quality and I wasn't personally attacking you for saying it's high quality. I was simply attacking the fact that people think it's high quality for whatever reason.

I'm going to reply to the post in the video thread countering some points you made, but do not take them as an attack against you. I will simply be stating facts about H.264 and x264.



Also, for the record, videos encoded with x264 can easily produce a video that has a smaller filesize while still looking incredibly better. That's H.264 for you. XviD is a thing of the past. ;)

I apologize. I was not directly attacking you. XviD is pretty terrible when in comes to quality and I wasn't personally attacking you for saying it's high quality. I was simply attacking the fact that people think it's high quality for whatever reason.

I'm going to reply to the post in the video thread countering some points you made, but do not take them as an attack against you. I will simply be stating facts about H.264 and x264.



Also, for the record, videos encoded with x264 can easily produce a video that has a smaller filesize while still looking incredibly better. That's H.264 for you. XviD is a thing of the past. ;)

I'm sorry too, But I feel EXACTLY the same as dopefish about XviD.

XviD is pretty terrible when in comes to quality

I'm not trying to throw gasoline here, but you must be saying that XviD quality is terrible given a certain bitrate, right? (vs. similar bitrate with H.264)

-edit-
Well I see that's exactly what you said in the last sentence of your post, so question answered.

[quote]XviD is pretty terrible when in comes to quality

I'm not trying to throw gasoline here, but you must be saying that XviD quality is terrible given a certain bitrate, right? (vs. similar bitrate with H.264)

-edit-
Well I see that's exactly what you said in the last sentence of your post, so question answered.

With nothing to compare it to, wmv has insanely high quality! :wink:

I've always addumed folks think it's teh best codec because it's no damned popular. Same with .mp3.

Ooooo how much mp3 pisses me off. Why couldn't everyone adopt somethig nbetter? Arg.

But they're popular and easy, so i['m sure they won't be going anywhere soon.

Indeed. I prefer AAC over MP3. AAC is a much newer specification than MP3 and it was designed to overcome many of the drawbacks in MP3. It is a better codec. AAC at 128kbps is better than MP3 at 160kbps or higher, and it only scales up from there. The resulting filesizes are smaller, too.

The same can be done with x264 versus XviD. You can actually encode with x264 at a lower bitrate than XviD, and have a better looking video and a much smaller filesize.

Apologies accepted, and sorry if I sounding like a complete ass in my responses. I have some interesting videos I'm about to post tonight showing my preliminary tests between Xvid and x264. Had I known that AutoMKV makes it so easy to use, I'd have tried it before. I have been rather influenced by the huge file size differences I've seen on TV show archiving sites though. The x264 ones are generally nearly 3 times the size.

I don't want to give away too much as far as the results of my test here for two reasons. I prefer it be chatted about for the most part where it's posted, and I am too new at x264 to know the best setup yet. In other words I haven't even bothered experimenting with settings like qp_min or psy yet. THAT is the main reason I call the test preliminary, it's going to be a work in progress for me, but I must say, so far it hasn't been as daunting as I thought it would be.

I got a couple warnings in the process of experimenting with compression settings. One was VBR <######> Level Limit ######, the first number being about 5,000 above the second (eg: 25000 vs 20000). At one point I knew I was trying a bitrate too high because I got a warning saying try reducing qp_min, current is 10. I didn't bother changing these parameters because qp_min not being seen anywhere but in the command line appeared to require editing it, and of course the bit rate leveled out as I got better at setting it.

The results are rather surprising to me so far. I must say, little did I realize x264 could compete so well in the small file size arena and still retain it's legendary image quality. Truth be told though, I had to zoom the 640x480 videos full screen to really see noticeable differences, but they're definitely there. I imagine the most noticeable differences are at 720p and up resolutions.

On AAC, last time I tried it, via sampling iTunes a while ago (which I despise), it didn't sound as good to me as wma, and not even any better than LAME. Since I've been using Xvid though, I've been using mostly LAME. If AAC can be used with x264/MKV though, I'll give it another go. Upon installing AutoMKV, I noticed there was an option regarding Nero, and I thought it said something about AAC too. I opted out of the Nero thing because I didn't think it would apply to my uses, even though I burn with Nero.

I got a couple warnings in the process of experimenting with compression settings. One was VBR <######> Level Limit ######, the first number being about 5,000 above the second (eg: 25000 vs 20000). At one point I knew I was trying a bitrate too high because I got a warning saying try reducing qp_min, current is 10. I didn't bother changing these parameters because qp_min not being seen anywhere but in the command line appeared to require editing it, and of course the bit rate leveled out as I got better at setting it.

The warnings can be ignore if you're just going to put the videos online. You'll notice when you encode with x264 that it will have a target level, 4.0, 5.0, etc. There are exact specifications that you need to comply with for these levels if you want to be compatible with the specification. For example, if you want to encode a video to be played back on the PS3, it must conform to level 4.0. Exceeding the bitrate for that level will spit out a warning letting you know. If you are just going to play these files back on a PC and nowhere else, then you can ignore the warning.

On AAC, last time I tried it, via sampling iTunes a while ago (which I despise), it didn't sound as good to me as wma, and not even any better than LAME. Since I've been using Xvid though, I've been using mostly LAME. If AAC can be used with x264/MKV though, I'll give it another go. Upon installing AutoMKV, I noticed there was an option regarding Nero, and I thought it said something about AAC too. I opted out of the Nero thing because I didn't think it would apply to my uses, even though I burn with Nero.

LAME is the highest quality MP3 encoder out, and yet AAC can still have better quality bitrate for bitrate. Just like with LAME, though, depending on the encoder there are plenty of options to tweak the sound. Comparing with iTunes may not be the best. neroaacenc is pretty high ranked in terms of output quality. I think for the best comparison you should compare LAME to neroaacenc.

As for the audio format with MKV, you can pretty much put anything you want in that container. MP3, FLAC, AAC, WAV, etc., etc. It's really a great container. MP4 has more popularity and support over MKV, but MKV is superior in features, audio/sync, etc. They're easily interchangable, though. You can easily extract tracks out of both MP4 and MKV containers so you can switch between the two very easily.

I opted out of the Nero thing because I didn't think it would apply to my uses, even though I burn with Nero.

Go ahead and download the Nero AAC, it's nothing to do with burning, it's just a codec they've made. The link in AutoMKV doesn't work, use this one. Put it in your BeSweet folder. :)

Go ahead and download the Nero AAC, it's nothing to do with burning, it's just a codec they've made. The link in AutoMKV doesn't work, use this one. Put it in your BeSweet folder. :)

OK, thanks got em in there now. It didn't show up in the drop downbox at first but then I realized you have to take them out of the folders they're in. I'll give it a go next time I compress.