Widescreen Gaming Forum

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.

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. :)

_________________
Widescreen Fixer - https://www.widescreenfixer.org/

Widescreen Fixer Twitter - https://twitter.com/widescreenfixer
Personal Twitter - https://twitter.com/davidrudie

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

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.

_________________
Widescreen Fixer - https://www.widescreenfixer.org/

Widescreen Fixer Twitter - https://twitter.com/widescreenfixer
Personal Twitter - https://twitter.com/davidrudie

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.

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

_________________
Formerly eZ`

Follow me on twitter: @theg00seberry and find me on Steam

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.

_________________
Widescreen Fixer - https://www.widescreenfixer.org/

Widescreen Fixer Twitter - https://twitter.com/widescreenfixer
Personal Twitter - https://twitter.com/davidrudie

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.

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.

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

_________________
Formerly eZ`

Follow me on twitter: @theg00seberry and find me on Steam