Burnout Paradise Videos (with Fraps/PlayClaw comparison).

Frag Maniac · Post by **Frag Maniac** » 24 Feb 2009, 12:02

These are some videos I made of Burnout Paradise, this first post of which* only shows the Fraps/PlayClaw comparison and a solo PlayClaw clip using it's recommended method of setting FPS.

The comparison clips are both captured @ 25 FPS, while the solo clip is @ 20 FPS. The comparison clips are of identical Burning Routes, in game TOD, and even near identical in finish line times.

Though PlayClaw has 2 compression settings for compressing while capturing, I used it's Uncompressed mode since I was comparing it to Fraps, which has no compression option.

I had to compress the comparison clips due to the PlayClaw captures being well over Filefront's file size limit. Both are captured with an identical twopass, 5000Kbps bit rate using Xvid in VirtualDub.

Besides the PlayClaw capture being a bit over twice the size of the Fraps one, it exhibits noticeable hitching on playback. The Fraps playback was not only smoother, it resulted in no less smoothness in gameplay whilst recording.

Hawker Burn Rt 5K Kbps Fraps

Hawker Burn Rt 5K Kbps PlayClaw

The winner hands down is Fraps. Even in lieu of PlayClaw's larger file size and hitching on playback, there simply was no smoother gaming performance whilst playing to justify the uncapped codec PlayClaw uses, which no doubt is the cause of at least the hitching problem. I will however keep PlayClaw on my HDD for games that I get too low FPS to play while capturing with Fraps, but I remain skeptical.

Below is that solo clip using PlayClaw @ 20 FPS I spoke of above. I get anywhere from 25-55 FPS while playing Burnout Paradise without recording. This shows that using PlayClaw's recommended method of setting FPS can result in quite a low capture setting. Yet even recording this clip, the gameplay, though PlayClaw showing a higher gameplay FPS, was not significant enough to be noticeably easier to control the car than recording with Fraps at 25 FPS.

The route in this clip is fully exploited, using all available stunts along the way. I was originally going to use it for the Fraps/PlayClaw comparison. In the end though, I decided linking all the stunts together in one run whilst recording was too hard. I had several recordings with Fraps getting all but one of the stunts.

Had I persevered as long as I did to make this one, I may have succeeded, but I saw no point for the mere purpose of comparing the capture tools. Thus I came up with the alternate route in the clips above, which IMO is just as fun to drive. In all I counted 11 multiplier points in this one, had the stunts been linked together with burn in a stunt run.

Hawker Burn Rt @20 FPS PlayClaw

*I will follow up tomorrow with more Fraps clips of Burnout Paradise. I have several A Class races using the 25 V16 Revenge, and one each of the Racing Oval Champ and Uberschall 8.

Jedediah · Post by **Jedediah** » 24 Feb 2009, 16:46

Great thread! Its nice to be able to read about these 2 programs in detail and then see the video comparison myself. I think for the sake of trying PlayClaw did alrightf. Fraps has been on the market for some years now. Maybe playclaw can improve itself with some updates. Allowing it better performance and smaller video captures. You can defiantly see how FRAPS made a better recording.

If PlayCloaw wants to make a name for itself maybe they should include some compression features. Maybe even a direct upload to youtube feature.

Frag Maniac · Post by **Frag Maniac** » 25 Feb 2009, 03:31

Great thread! Its nice to be able to read about these 2 programs in detail and then see the video comparison myself. I think for the sake of trying PlayClaw did alrightf. Fraps has been on the market for some years now. Maybe playclaw can improve itself with some updates. Allowing it better performance and smaller video captures. You can defiantly see how FRAPS made a better recording.

If PlayCloaw wants to make a name for itself maybe they should include some compression features. Maybe even a direct upload to youtube feature.

Thanks, but sorry if the mini review/comparison wasn't thorough enough to explain that PlayClaw DOES actually have two compression options. Besides Uncompressed, you can select Low Compression or High Compression. I edited the review accordingly.

However, since the comparison was aimed solely at pitting PlayClaw against Fraps, a tool that only captures uncompressed, I did not use the compression features. Compressing whilst capturing also taxes your CPU more, and my spec is fairly low (P4 3Ghz, X1950Pro, 2GB RAM).

Both capture and compression are resource intense. I feel it's best to not do them simultaneously, esp if you prefer to compress with a high quality codec like Xvid, which produces great image quality and low file size, but has to undergo lots of calculations while doing so.

Post by **dopefish** » 25 Feb 2009, 05:05

XviD... high quality... I laughed. :)

DaFox · Post by **DaFox** » 25 Feb 2009, 07:16

XviD... high quality... I laughed. :)

hehe I sol'd aswell.

Frag Maniac · Post by **Frag Maniac** » 25 Feb 2009, 11:14

A bit of thread stomping going on here? Show me a better codec in image quality for the resulting file size that is free open source and I will eat those words. Otherwise keep your mouths to yourselves you childish turds.

No wonder not many offer contributions around here, bunch of retards. :roll:

Anyone that knows anything at all about offering videos for net download understands file size is important too. Look at ALL the major download sites for TV shows, movies, etc, and you will find they're offered primarily in two types of codecs, X264 and Xvid. X264, while being slightly better in image quality results in WAY bigger file sizes and is WAY less stable to use.

I don't see the two of you proving to be aficionados of videos for the smart ass remarks you make. Where are your offerings wannabes? If you could manage anything better they'd probably be larger files than anyone would want to bother with.

Bunch of God damned punks I swear. You two better keep your mouths under control in my contribution threads from now on or the shit is going to fly faster than you can shut them. Probably a couple of idiot DivX dickheads.

Post by **Abram** » 25 Feb 2009, 14:28

Getting off topic, no?

The thread and those videos did their job. Isn't that enough?

Fraps good.
Playclaw not so good. Yet. I didn;t think it'd look so poor.

And Frag Maniac.... 4:3?? Whu? Huh?

PS - just got the Hawking and stole your route.

Post by **g00seberry** » 25 Feb 2009, 15:00

As Jedediah said "Great Thread". It's helping people and serving it's purpose in comparing the 2 capture programs.

There's no need to attack it. :?

Frag Maniac · Post by **Frag Maniac** » 25 Feb 2009, 23:16

Yeah, perhaps I could have opposed that attack, which it was, a bit more tactfully, but I felt anyone as knowledgeable as they are ought to know better. Most into video making know full well x264 is the best codec for final compression as far as image quality goes, but primarily used for HD video, not net downloads where file size is critical.

Obviously one of the primary functions of a codec is to compress to a smaller file size. In that respect they are not unlike file compression tools like WinRar, 7zip, etc. Thus their image quality for the given file size should be a main factor in judging their overall quality. Xvid still holds the crown for small file size. If you tried making an x264 vid of equal size it would look quite bad.

X264 is also fairly complex and unstable to work with. You so much as even use an avi container and you can wind up with problems. Having to perform simple tasks like resizing via AviSynth isn't exactly the pinnacle of user friendliness either.

It wasn't long ago many, even the tech oriented, thought wmv was the best codec for small file sizes, some preferring DivX. Then Xvid started being widely used and wmv and DivX got left in the dust. Along came HD video and suddenly all those obsessing over cataloging their Blu-ray movies wanted something better, enter x264, the open source alternative to the very finicky H.264.

Along the way there were many frustrations, more so than with any codec before. I mean just Google for Fraps to x264 encoding and you will get half a dozen opinions on how best to do that with several accessory tools listed to assist the process.

Thus the primary use for x264 became and still is HD video archiving, an elitist crowd that is often seen even using such monikers for their websites. To each their own. Personally, I don't bother cataloging HD movies. Heck, I don't even rent them yet.

I prefer to wait until Blu-ray takes over on the rental end of the market before even equipping myself with such hardware. I really can't see cataloging movies when I don't care to watch them a 2nd time unless they are exceptionally good, and even then I prefer to wait a couple years so I've forgotten most of it and it's fresh again watching it.

At the price I get my rentals for, I can watch a movie twice and still pay no more than just the blank disc it takes to catalog it, and then there's all that time to encode, compress and burn. True to the moniker elite, some people have nothing better to do than harp about someone else's work in having obsessed for hours over their own little home movie projects that probably for the most part just sit on the discs they were burned to.

OK, enough of the OT. Here's the rest of those Burnout Paradise videos I promised. All these use Fraps for capture and again, Xvid, for compression. If you feel the video quality isn't to your liking, perhaps you are using WMP for playback. I highly recommend a better, superior alternative, like KMPlayer or even VirtualDub can play them back much better. I here VLC is now vastly improved too.

These are all races btw, listed by name of race and car used:
(There's no boost used in any of these. After my first successful no boost run in Go West!, I became more interested in doing them that way, as it adds needed challenge to the game IMO.)

Go West! - Oval Champ

Save ferris - Revenge

Hard Fort - Revenge

Full Gallop - Revenge

Torpedo Run - Revenge

Plaza Endurance - Revenge

Mano A Mano - Revenge

Baseball Battle - Uberschall

For the record I am going to try some x264 compressions, despite having a pretty good idea of the tradeoffs. I don't particularly like overly complex, bulky, finicky codecs, but I am a stickler for comparisons.

Post by **dopefish** » 26 Feb 2009, 01:49

A bit of thread stomping going on here? Show me a better codec in image quality for the resulting file size that is free open source and I will eat those words. Otherwise keep your mouths to yourselves you childish turds.

x264. It's free. It's open source. It has better image quality and a smaller file size, because it's smarter, newer, H.264, better compression, etc., etc., etc.

Anyone that knows anything at all about offering videos for net download understands file size is important too. Look at ALL the major download sites for TV shows, movies, etc, and you will find they're offered primarily in two types of codecs, X264 and Xvid. X264, while being slightly better in image quality results in WAY bigger file sizes and is WAY less stable to use.

I'm not trying to insult you here, but it really sounds like you haven't done any research or homework. x264 produces better image quality at smaller filesizes. YouTube actually uses x264 to encode their videos. NoobFlicks does, as well.

Now why would YouTube, the largest online video site, use x264 to encode their videos if the filesizes were so much larger? How would that help dealing with the massive amounts of traffic and streaming they have to do?

I don't see the two of you proving to be aficionados of videos for the smart ass remarks you make. Where are your offerings wannabes? If you could manage anything better they'd probably be larger files than anyone would want to bother with.

I'm not much of a video maker, but I do a lot with the technical side of encodings. I consistently do testing, work with the developers, comparisons, etc. I make available lossless videos online that can be used to test. I also experiment with many different encoding options that affect quality.

Most into video making know full well x264 is the best codec for final compression as far as image quality goes, but primarily used for HD video, not net downloads where file size is critical.

Disagree. x264 produces smaller sizes than XviD while providing better image quality. It's not just good for HD, it's good for SD, HD, and whatever you want to throw at it.

Obviously one of the primary functions of a codec is to compress to a smaller file size. In that respect they are not unlike file compression tools like WinRar, 7zip, etc. Thus their image quality for the given file size should be a main factor in judging their overall quality. Xvid still holds the crown for small file size. If you tried making an x264 vid of equal size it would look quite bad.

Entirely false. x264 will not only be a smaller filesize, but the resulting quality will be incredibly better. Using your archive compression comparison. Think of XviD as the old zip format. It has poor compression. Now think of x264 as lzma (what 7z uses). It has much better compression, while still retaining the same contents. So if you targeted a specific quality between XviD and x264, x264 will be the clear winner in filesize and quality.

X264 is also fairly complex and unstable to work with. You so much as even use an avi container and you can wind up with problems. Having to perform simple tasks like resizing via AviSynth isn't exactly the pinnacle of user friendliness either.

Again, this sounds like you've never personally messed with x264. It is completely stable to use. It's also no more or less complex than XviD. Both utilities have command line versions that you can pass arguments to, and both have plenty of interfaces that you can use to set your options.

AVI? Seriously? AVI is one of the worst containers available to date. MP4 and MKV are both superior in features, compatibility, formats supported, etc. No b-frame support, no streaming, etc., etc., etc.

Using AviSynth is amazing. You don't have to use it. There are plenty of ways to resize without using AviSynth. It's just that using AviSynth makes everything far easier. Want to downscale a video? LanczosResize(640, 480). Now you just open the .avs file in any video player you want and you can see it downsized without even encoding it. There is so much you can do with AviSynth. It's probably one of the most powerful video utilities around. However, AviSynth, again, is not required to do any of that. It's just an easier way.

It wasn't long ago many, even the tech oriented, thought wmv was the best codec for small file sizes, some preferring DivX. Then Xvid started being widely used and wmv and DivX got left in the dust. Along came HD video and suddenly all those obsessing over cataloging their Blu-ray movies wanted something better, enter x264, the open source alternative to the very finicky H.264.

H.264 is a solid standard. The standard specifies both encoding and decoding. It's a newer and better standard than what XviD uses. XviD is old technology.

I mean just Google for Fraps to x264 encoding and you will get half a dozen opinions on how best to do that with several accessory tools listed to assist the process.

How is this a problem? The last time I checked, choices were a good thing. Sure, there are plenty of ways. There are plenty of utilities, tools, etc. to accomplish this. Use what you want.

Thus the primary use for x264 became and still is HD video archiving, an elitist crowd that is often seen even using such monikers for their websites. To each their own. Personally, I don't bother cataloging HD movies. Heck, I don't even rent them yet.

People think this way because whenever anyone tries to explain why x264 is better, it gets shot down by elitist XviD users who won't let go of the past. x264 is, and always will be, better at encoding anything over XviD.

For the record I am going to try some x264 compressions, despite having a pretty good idea of the tradeoffs. I don't particularly like overly complex, bulky, finicky codecs, but I am a stickler for comparisons.

This is what I do. I do comparisons. I talk with the developers daily. I provide test cases. I work with the technical side of all of these codecs. I can already tell you x264 is better in every way.

Frag Maniac · Post by **Frag Maniac** » 26 Feb 2009, 08:47

All I can say is some of the sites that offer Xvid and x264 downloads are VERY misleading as far as the difference in file sizes for the same exact content. I admit, now that I have tried a direct Xvid/x264 comparison, I am quite surprised by the result so far. Not in a totally blown away and flabbergasted sense yet, but I've yet to tweak certain settings like qp_min and psy.

It's not so much that I haven't done ANY research or homework, but that it's much harder to find good tutorials for x264 than it is for say using Xvid in VirtualDub, where you can get a few good visual tutorials on settings and their meanings. Besides that, VDub has a fairly good built in Help file, I saw no such thing with AutoMKV.

You must realize when you comment on such things you are into the programming arena, and others are not. It's probably not only easier for you to pick it up, it's likely easier for you to get information about it due to the kind of contacts you have. So please keep in mind that it's one thing to offer rational points of view and constructive criticism, quite another to vaguely scoff at a tool some are still using, which can plant skepticism in their minds as to why.

As someone mentioned on another thread here, there's always a myriad of opinions and personal preferences on things like codecs. So when you vaguely scoff without so much as giving rational detailed reasons, you reduce yourself to sounding like the dime a dozen self proclaimed critics, and therefore seemingly less credible to some.

None the less, I value your input, and have learned there is just as much hype about free open source software as there is licensed retail products. I'm not so sure it's due to clinging or elitism that some don't want to give up the old for the new. For me it was mostly feeling like I was on the outside looking in every time I tried to discuss x264 with those in the know. That coupled with the common talk of it being less stable, more complex, and larger in file size, just exacerbated the problem of trying to research it as you say.

I'm not going to hold any of that clinging or even the hype against Xvid users though, because elitism in one camp generally begets elitism in another. It's ironic that open source tools, being collaborated on by so many users, can end up being the source of such introverted social cliques. It seems to go against the grain of the mindset of what open source is supposed to be.

Post by **dopefish** » 26 Feb 2009, 09:56

Yeah. Don't get me wrong. I wasn't trying to make fun of you or anything. Nothing personal.

Anyway, I think the more familiar you get with x264 and its options, the better off you'll be.

As for sites being misleading, we've come to an age where online videos as XviD are no longer acceptable by the people who encode them. With HD shows appearing everywhere, it's natural to want to encode it in its original format and with a larger filesize.

Encoding at a higher resolution like 720p or 1080p requires a higher bitrate, which increases the size. However, if you encode with XviD at that same resolution, the size of the output file will be larger. If you compare bitrate for bitrate at the same resolution, x264 will win in quality and filesize.

Plus there's a ton of options when encoding to get different results. :)

Frag Maniac · Post by **Frag Maniac** » 26 Feb 2009, 12:51

OK, back to the thread topic, but with a twist. This time I've just one Burnout Paradise capture of the fun Togue Sport Burning Route, though comparing Xvid and x264 compressions. As mentioned, I'm new to x264 as far as hands on compressing, so bear with me. Like I said elsewhere, consider this a preliminary test, as I've yet to master the use of it.

I kept the resizing of the 512x384 clips the same as before at 640x480 via Lanczos. As for why 4:3 that was mentioned earlier, it's not me, it's the game. You see I generally capture at 16:10 even though I have a 4:3 CRT, because every game I've captured up until now plays fine at that aspect ratio on my monitor. This one for some reason has lots of proportional distortion I could not adjust out via screen resizing. I've never seen the Takedown 4x4 look so silly, tall and skinny.

CRF was left at the default 20 and no change to qp_min, as my minimal reading of x264 indicated CRF is better and the default setting about right. I found the 2 Pass !Fast compression profile to be roughly identical to Xvid's twopass as far as time to compress, so that's the one I used. Target file size was set to 41 MB, which resulted in a pretty accurate 40.8MB. Conversely the calculator in VDub came out at 39MB, so I did some manual calculations, readjusted the bitrate, and made another compression.

For audio compression I used the LAME codec at 192kbps stereo, merely for the purpose of using the exact same codec for each video codec, so as to not skew the results. All other settings were left at their default values. I decided to make a 3rd compression just before posting this, to see if indeed x264 could have better image quality in a smaller file size. Though this time I tried the AAC codec at 160 vs 192kbps. I know, that's going against pitting video codec against video codec a bit and slightly skewing the results, but I was also wanting to compare VDub to AutoMKV, and that includes making use of some of it's features.

I tried a half size compression, 20MB, which was noticeably worse in quality, so I scrapped it. Something I should note though. I didn't actually complete that compression. When I started the encode process, I got an error saying a BAT file could not be found. In clicking OK it continued encoding anyway. The only difference was I used the default output file location, vs one I had designated before. I checked the partial compression to look at it's quality out of curiosity, and it was not as good.

I settled on a 30MB file size, which did not result in an error after starting the encode process. I had the feeling it was something about that 55MB or so Temp file contents the app produces upon each encoding. Everything else was left the same on the 30MB clip, only the target file size and audio was changed.

To my eye, the two 41MB clips are close, but the x264 one is noticeably better when zoomed. You can see more detail in the foreground, and no banding in the sky, as was evident in the Xvid clip. The nearby textures that quickly draw into view (trees, walls, etc) are also sharper in the x264 clip.

The 30MB clip however appeared to me to be a mixed bag. Whilst the sky is still sharper on the x264 clip without the banding the Xvid clip shows, the nearby textures drawing quickly into view are less sharp. You can see it if you look closely at the tree foliage and the brick walls of the tunnel. However amazingly the foreground including the pavement and the car's silhouette seem to be sharper in the x264 clip, despite being less than 75% the file size. Again, ALL these differences I'm noting are while the videos are zoomed full screen on a 20" viewable 4:3 CRT.

I will leave it for those of you whom download them to judge though. Some people see things I don't, and perhaps vise versa. Overall though I have to say x264 is the clear winner, even though this is just a prelim test done by a relative noob at using it. Though it doesn't seem as huge a difference to me as it sounds dopefish claims to be possible, I still can't get over how much I was mislead by the talk and sight of large file sizes with this codec. Perhaps some don't even know how to use it as well as this first timer.

Truth be told though, I really think it's more that the sites that offer such downloads cater two type types, those that want small files due to slower ISPs or time constraints, and those whom prioritize HD video quality. From what I've heard there's no comparison between the x264 videos and the Xvid videos on such sites, there are simply none of the flaws readily visible in the Xvid ones. I saw an x264 compression of the Fantastic Four: Rise of the Silver Surfer Blu-ray movie once on a 720p TV and I swear, you'd have thought it was actual Blu-ray.

I get the feeling that at 720p and up resolutions, which obviously I'm not showcasing here, the differences might be even more dramatic, perhaps in both image quality AND file size.

Togue Sport Burn Rt Xvid

Togue Sport Burn Rt x264

Togue Sport Burn Rt x264 30MB

Post by **dopefish** » 26 Feb 2009, 14:59

I'm glad you're looking into x264.

I want to point out some things, though.

CRF is used for a target quality. You only need to make one pass with this setting. This is the best way to encode with x264. Don't be fooled into thinking you need two passes to get quality, at least not with this setting. The main drawback to CRF is that since you target a quality and not a bitrate, there's no way to determine the final filesize. This is the best method to use if you're focusing on quality. Lowering CRF will result in better quality. Anything below 18 is indistinguishable to the naked eye.

If you wish to target a specific bitrate, and therefore know the final filesize before you start, then you'll want to do two passes and specify the target bitrate.

I've posted these arguments in another thread here, but I'll post them here so you can try them out:
x264 --crf 24 --ref 6 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --weightb --direct auto --subme 9 --trellis 2 --psy-rd 1.0:0.1 --partitions all --8x8dct --me tesa --threads auto --progress --no-dct-decimate --no-psnr --no-ssim --output video.264 input.y4m

This is if you use x264 directly. I don't use any interfaces so you'll have to translate these settings into whatever front-end that you use.

These are pretty much the settings for maximum quality. Adjust CRF as needed. Encoding with these options will be slow unless you have an Intel i7. :)

You can read about the x264 settings at this page:
http://mewiki.project357.com/wiki/X264_Settings

Let me know if you have any questions.

Frag Maniac · Post by **Frag Maniac** » 26 Feb 2009, 15:44

You know, I could swear I read two different explanations of how CRF works, first the way you described it, then another site claiming it only works with multiple pass variable bitrate compressions. Anyways, I really don't want to be spending huge amounts of time waiting for compressions to finish, and I only have a P4 3Ghz single core CPU.

I forgot to mention that in the comparison test, each app took approx 7.5 min to complete the compression. I'd be willing to go as much as double that time because really I WAS using 2 twopass compressions before with Xvid, one at 5000kbps, the next around 2100.

With some games it's hard to tell if doing 2 sets of twopass compressions really helps, but I know it has in some games like FEAR, where I've been able to record full level videos of about 7:30 duration and compress to 115MB file size at 640x400 that are high enough in quality to zoom to the full res the game played at (1280x800) with barely any distinguishable difference in quality from when I was playing it.

Can you tell me how to utilize that command line script? I see a box above the script shown in AutoMKV that says Add, but what you've shown looks like an entire command line all in itself. I don't want to change anything in the app that I won't know how to change back. Also, though I do put quality at a high priority, even enough so to be able to zoom full screen with good clarity, I still would like a reasonable file size too.

I would not know how to translate those settings as you say. About the only thing I see as plausible for me so far is perhaps editing values within a given command line based on recommendations I read, but again, I'm reluctant to do even that not knowing if the changes are easily reversible and/or memorable. And yes, I have skimmed through that site you linked to, but I prefer a more pictorial guide like this: http://automkv.a.wiki-site.com/index.php/Help:Contents?

BTW, I was reading an old text guide that reminded me some time ago I had read about people using x264 in VirtualDub, though it's called x264 VFW in that case. Is x264 VFW no longer used and is the latest build of x264 quite a bit better? I really prefer a more user friendly interface like VDub. Besides changes being easily selectable and memorable via boxes, vs a lot of script, it has a viewer and great filters, the two of which make for easy changes that can be previewed instantly.

I'll probably have an i7 in my next rig, maybe build it around year's end, but for now I need a compression config for a poor man's rig.

Post by **g00seberry** » 26 Feb 2009, 16:13

In the AutoMKV folder, look in /exe/Encoder to find x264 :)

Post by **dopefish** » 26 Feb 2009, 18:29

You know, I could swear I read two different explanations of how CRF works, first the way you described it, then another site claiming it only works with multiple pass variable bitrate compressions. Anyways, I really don't want to be spending huge amounts of time waiting for compressions to finish, and I only have a P4 3Ghz single core CPU.

Yeah, you'll want to lower the settings I mentioned then. :)

With some games it's hard to tell if doing 2 sets of twopass compressions really helps, but I know it has in some games like FEAR, where I've been able to record full level videos of about 7:30 duration and compress to 115MB file size at 640x400 that are high enough in quality to zoom to the full res the game played at (1280x800) with barely any distinguishable difference in quality from when I was playing it.

If you're encoding for a target bitrate, two-pass is a must for quality. If you just go with one pass, it's going to be much worse -- not just visually, but also in compression.

However, you can use a reasonably higher CRF setting, like 26 - 28, and end up with a smaller filesize. If you have it show the progress, you can monitor the bitrate in real-time so you can see if it's too low or too high.

Can you tell me how to utilize that command line script? I see a box above the script shown in AutoMKV that says Add, but what you've shown looks like an entire command line all in itself. I don't want to change anything in the app that I won't know how to change back. Also, though I do put quality at a high priority, even enough so to be able to zoom full screen with good clarity, I still would like a reasonable file size too.

Using options that increase quality won't really increase the size. The size has more to do with the bitrate than the options used. The options just provide ways of improving quality at the cost of encoding time. The higher the quality, the more CPU time you're going to need.

I frequently update and compile my own versions of x264 and benchmark them. You can view the benchmarks for various systems here.

My builds of x264 can be found here:
http://imk.cx/pc/x264/

I would not know how to translate those settings as you say. About the only thing I see as plausible for me so far is perhaps editing values within a given command line based on recommendations I read, but again, I'm reluctant to do even that not knowing if the changes are easily reversible and/or memorable. And yes, I have skimmed through that site you linked to, but I prefer a more pictorial guide like this: http://automkv.a.wiki-site.com/index.php/Help:Contents?

Well. If you see my line and it says bframes 16, then maybe see if AutoMKV has an interface option to adjust bframes.

BTW, I was reading an old text guide that reminded me some time ago I had read about people using x264 in VirtualDub, though it's called x264 VFW in that case. Is x264 VFW no longer used and is the latest build of x264 quite a bit better? I really prefer a more user friendly interface like VDub. Besides changes being easily selectable and memorable via boxes, vs a lot of script, it has a viewer and great filters, the two of which make for easy changes that can be previewed instantly.

VFW is no longer supported. I believe some people maintain patches to support it, but it's no longer officially supported.

x264 improves greatly with each revision. Usually when encoding, I work with lossless sources in y4m or huffyuv format. This lets me work with an unmodified source that doesn't need re-encoded. Once I have everything I like, I then encode the final product with x264.

Jedediah · Post by **Jedediah** » 26 Feb 2009, 22:41

Once again, wonderful thread. I enjoy reading through this and learning what I can. After the video examples I'm rather interested in x264 also. I've been using a Mp4 codec to compress my videos before but I think I would to give this a try.

Frag Maniac · Post by **Frag Maniac** » 27 Feb 2009, 02:58

Well, until I get a better rig built, it looks like much of my using this codec and app will be experimental. The build versions you show for x264 are for dual core and up obviously, and thus so would be the recommended settings.

Still though, I am quite pleased with the result so far. Can you tell me primarily what settings I need to tweak though to get that better quality you spoke of without added file size? Am I looking at mainly dropping CRF a bit and increasing bFrames?

I see that the default bframes setting is 3, but there is no box in which to change it. I think it has to be done via that command line editor and I'm not sure how to use it. And what about the Advanced x264 settings I highlighted in red? Would changing any of those help add quality without increasing file size?

Here's the script shown when I click open the drop down box for "Add to line:" in the command line editor, rather confusing.

You can simply type in commands separately above it, but I've yet to try actually adding any. Like I said, there's no way for me to know if I'll permanently change something. I can only assume it saves a separately profile from the default library of profiles once you edit something then click Save Profile, leaving the default library of profiles/commands intact.

@eZ,
I'm not sure why you made the comment about finding x264 in the AutoMKV folder? Selecting and/or using it in the app has never been an issue. In fact it's pretty much the default codec shown.

About the only issues I'm having other than trying to find out how to change certain settings is there's no Help file and the tooltips don't stay showing very well when I hover the cursor over parts of the app.

You CAN see the tips as text lines at the bottom of the app, but only if you click on something. Perhaps this is a minor glitch they need to work out. I did notice the app launches a bt shakey, flashing on and off momentarily.

@Jedediah,
I look forward to comparing notes with you should you start using x264 and AutoMKV, esp if you have older spec like I do.

To all,
...no comments yet on the x264 vs Xvid vids. Did I screw up or are the results anywhere near adequate for a first go with x264/AutoMKV? I got the feeling they're not bad for using mostly default settings and given the processor power I have, which I think can also affect quality some.

Post by **g00seberry** » 27 Feb 2009, 03:08

I frequently update and compile my own versions of x264 and benchmark them. You can view the benchmarks for various systems here.

My builds of x264 can be found here:
http://imk.cx/pc/x264/

Awesome benchmarks. I think i want an i7 ;)

Without going into too much detail, what have you actually done to your x264 compiles? If i replace the existing one that AutoMKV uses with your one, you reckon that'll work fine n dandy? I've downloaded "x264.r1114M.SSSE3.x64.imk".

@eZ,
I'm not sure why you made the comment about finding x264 in the AutoMKV folder? Selecting and/or using it in the app has never been an issue. In fact it's pretty much the default codec shown.

Sorry, i meant you can find the .exe in there if you wanted to use it directly without AutoMKV

Widescreen Gaming Forum