best x264 encoding software.

[taltamir]

What is the best program to use for x264 encoding?

 

[MrChad]

Define best. Ease-of-use, quality, speed, number of options? I like Handbrake because its dead simple to use.

 

[Cogman]

why, x264 of course.

There is no "x264" codec standard. Only H.264. x264 is an encoder (that beats the crap out of everything else).

popular x264 interfaces include
Handbrake,
Megui
and staxrip (All of which are free)

DVDFab isn't free, but it includes the x264 encoder.

 

[taltamir]

Define best. Ease-of-use, quality, speed, number of options? I like Handbrake because its dead simple to use.

The best in the only ways the actually matter to anyone who knows anything about video.

ok, let me clarify, I LIKE easy to use but it doesn't have to be.
Priorities are:
1. Quality / File size (the two are closely related)
100. Ease of use
There is no priority 2 through 99.

I don't care about:
1. Options (except for options that improve quality/file size)
2. Speed

I have DVDFab (which annoyingly refuses to save my choice of 2-pass encoding and keeps reverting to 1-pass, so I have to manually set it every time)
I have used virtualdub and virtual dub mod. How does handbrake, megui, and staxrip compare?

why, x264 of course.

There is no "x264" codec standard. Only H.264. x264 is an encoder (that beats the crap out of everything else).

I know all of that. I know H.264 is the standard, x264 is an open source implementation of the standard, and that various binaries of it are available with various GUIs, and I know that x264 is hands down the best video codec out there right now. I am aware of its licensing issues and how it compares with ogg, vc1, and VP8. I know about containers and my container of choice is MKV, using MKVToolnix to remux it.

I am asking which program is best to use for it.

 

[Cogman]

overall the best.

ok, let me clarify, I LIKE easy to use but it doesn't have to be.
Priorities are:
1. Quality / File size (the two are closely related)
2. Ease of use

I don't care about:
1. Options (except for options that improve quality/file size)
2. Speed

I have DVDFab. How does handbrake, megui, and staxrip compare to it?

I know all of that. I know H.264 is the standard, x264 is an open source implementation of the standard, and that various binaries of it are available with various GUIs, and I know that x264 is hands down the best video codec out there right now. I am aware of its licensing issues and how it compares with ogg, vc1, and VP8. I know about containers and my container of choice is MKV, using MKVToolnix to remux it.

I am asking which program is best to use for it.

They all use the same x264. So Quality/Size is going to be exactly the same across encoders. They all encode at the same speed because they use the exact same x264. They all, generally, have the exact same access to encoding options because they use the same x264 program.

x264 is the program doing the programming. It is a command line application.

The only difference is really the way they appear and what other programs they provide access to.

 

[Cogman]

I know all of that. I know H.264 is the standard, x264 is an open source implementation of the standard, and that various binaries of it are available with various GUIs, and I know that x264 is hands down the best video codec out there right now. I am aware of its licensing issues and how it compares with ogg, vc1, and VP8. I know about containers and my container of choice is MKV, using MKVToolnix to remux it.

I am asking which program is best to use for it.

The fact that you included in your list "Quality/Size" really says to me that you really don't understand what x264 is. All x264 interfaces are going to have close to the exact same quality/size capabilities.

The only exception would be that they use a particularly old version of x264 (The ones I've listed generally keep up to date or can be updated easily).

 

[Gooberlx2]

Handbrake or Avidemux, depending on your need.

 

[Anteaus]

Handbrake FTW

 

[taltamir]

The fact that you included in your list "Quality/Size" really says to me that you really don't understand what x264 is. All x264 interfaces are going to have close to the exact same quality/size capabilities.

Close =! the same.
x264 does not provide a reference binary. only source code which is available in a variety of compilation with various optimizations. Now, it will be very similar, maybe even the same, but it has the potential to be different.
Especially because some GUIs might not fully utilize it, for example, a lot of GUIs do not even provide the option of 2-pass encoding.

Handbrake FTW

I checked out handbrake, the option for 2-pass encoding on x264 is grayed out.

 

[Gooberlx2]

I checked out handbrake, the option for 2-pass encoding on x264 is grayed out.

You need to select either Target Size or Avg Bitrate Qualities.

 

[Cogman]

Close =! the same.
x264 does not provide a reference binary. only source code which is available in a variety of compilation with various optimizations. Now, it will be very similar, maybe even the same, but it has the potential to be different.
Especially because some GUIs might not fully utilize it, for example, a lot of GUIs do not even provide the option of 2-pass encoding.

The speed differences between icc and gcc compiled binaries is somewhere near 0. The quality difference IS zero (barring some unique compiler bug). Right now, there are no patches on the out there that significantly improve quality (even though pretty much no interface ships with a patched version of x264. They are all vanilla that I've seen.)

Even when a new quality/speed patch comes on the scene, they aren't incorporated into x264 instantly for stability reasons (do you really want to see your 5 hour encode crash due to an unstable version of x264?). Generally it takes about 1 month of testing before being committed. Which is faster than most of the guis update their x264 version.

The majority of patches out there are for enabling features for things like streaming or fix compatibility issues with different bluray players.

As for the two pass not being enabled. What are you trying to do? Constant quality? If so, they are rightly disabling two-pass as it doesn't make any sense to encode something in constant quality and then doing a second pass. Handbrake does 2 pass encoding.

 

[Phynaz]

Assuming you want to do H.264 encoding, the Main Concept encoder is available in TMPGEnc.

Runs about a hundred bucks.

 

[Phynaz]

Assuming you want to do H.264 encoding, the Main Concept encoder is available in TMPGEnc.

Runs about a hundred bucks.

Oops, nevermind. The new release uses the x.264 encoder. Interesting.

 

[taltamir]

The speed differences between icc and gcc compiled binaries is somewhere near 0. The quality difference IS zero (barring some unique compiler bug). Right now, there are no patches on the out there that significantly improve quality (even though pretty much no interface ships with a patched version of x264. They are all vanilla that I've seen.)

Even when a new quality/speed patch comes on the scene, they aren't incorporated into x264 instantly for stability reasons (do you really want to see your 5 hour encode crash due to an unstable version of x264?). Generally it takes about 1 month of testing before being committed. Which is faster than most of the guis update their x264 version.

The majority of patches out there are for enabling features for things like streaming or fix compatibility issues with different bluray players.

thanks, that is exactly what I wanted to know.

As for the two pass not being enabled. What are you trying to do? Constant quality? If so, they are rightly disabling two-pass as it doesn't make any sense to encode something in constant quality and then doing a second pass. Handbrake does 2 pass encoding.

What I am trying to do is encode it with the settings that produce the absolute highest quality/lowest size. It doesn't need to be compatible with anything special, just PC.
Any recommendation for target average bitrate? One where I will likely not see a difference between it and the bluray source.

I looked it up in the manual. It seems there is no CBR (which is good) only various implementation of VBR, and with constant quality it will not need 2 passes because there is no target bitrate only target quality and let size be what it ends up being.
I went ahead and set everything to max quality and I get "encoding finished" immediately as I start (well, after 0.012&#37 with a 4kb corrupt file as a result. Audio is on DTS passthrough btw.
here is the settings I used:

Any idea why?
Logs show it terminating with:
x264 [error]: malloc of size 8626176 failed

Found the issue, maximum B-Frames. Lowered back to the default (3) it no longer errors out.

 

[Anteaus]

thanks, that is exactly what I wanted to know.



What I am trying to do is encode it with the settings that produce the absolute highest quality/lowest size. It doesn't need to be compatible with anything special, just PC.
Any recommendation for target average bitrate? One where I will likely not see a difference between it and the bluray source.

I looked it up in the manual. It seems there is no CBR (which is good) only various implementation of VBR, and with constant quality it will not need 2 passes because there is no target bitrate only target quality and let size be what it ends up being.
I went ahead and set everything to max quality and I get "encoding finished" immediately as I start (well, after 0.012%) with a 4kb corrupt file as a result. Audio is on DTS passthrough btw.
here is the settings I used:

Any idea why?
Logs show it terminating with:
x264 [error]: malloc of size 8626176 failed

Found the issue, maximum B-Frames. Lowered back to the default (3) it no longer errors out.

Basically what you need to do is choose constant quality with high profile. That should give you the best balance at resolution. I encode at around 15-16 which gives me a 2.5 to 3.5GB file size on average, but the quality is top notch. Some movies (especially those with screen noise), are going to slam you with file size, so no matter what your going to have to dance a little with some movies and try different settings.

CQ in the latest version of handbrake is all win for the most part.

 

[taltamir]

Basically what you need to do is choose constant quality with high profile. That should give you the best balance at resolution. I encode at around 15-16 which gives me a 2.5 to 3.5GB file size on average, but the quality is top notch. Some movies (especially those with screen noise), are going to slam you with file size, so no matter what your going to have to dance a little with some movies and try different settings.

CQ in the latest version of handbrake is all win for the most part.

CQ? what is CQ?

Are you saying it only takes 2.5 to 3.5GB for a 2 hour movie on RF15?
the manual for handbrake recommends RF20 for DVD source and RF21-22 for BR source. Where RF0 is lossless and the higher the RF the more info is discarded on a log scale.

 

[Gooberlx2]

Any recommendation for target average bitrate? One where I will likely not see a difference between it and the bluray source.

I had a Watchmen bluray rip at about ~18GB, and I couldn't tell the difference.

According to this, the blu-ray is VC-1 encoded at ~19mbps avg, and DTS-MA audio at ~3.5mbps avg (so that makes ~31GB for the 186 minutes).

I've used that as reference with my own HD rips and re-encode audio to AC3 5.1 @ ~512kbps, and video came out to ~12mbps. So figure ~65% quality.

 

[taltamir]

According to this, the blu-ray is VC-1 encoded at ~19mbps avg, and DTS-MA audio at ~3.5mbps avg (so that makes ~31GB for the 186 minutes).

Originally bluray did not actually have h264 capability while HDDVD did, sony quickly added h264 option to the standard, and many modern blurays are encoded in h264

 

[Gooberlx2]

Yeah. VC-1 is a good codec though. At the double-digit mega-bitrates I'm not concerned about the minor differences between it and h.264, so I didn't compensate my calculations there or anything. I still go with ~12-13mbps average when making my encodes. More if I know it's dark movie with action, less if it's bright and slow.

Reminds me I should continue my task of ripping those few HD-DVDs I have.

 

[Anteaus]

CQ? what is CQ?

Are you saying it only takes 2.5 to 3.5GB for a 2 hour movie on RF15?
the manual for handbrake recommends RF20 for DVD source and RF21-22 for BR source. Where RF0 is lossless and the higher the RF the more info is discarded on a log scale.

CQ=constant quality. I agree that the manual shows an RF20, but considering if your making a serious encode its likely your going to be scaling it up to 1080P making artifacts much more apparent, especially banding. At resolution, RF20 is fine. In my experience, at RF of 15 or 16 gives a much cleaner picture at "somewhat reasonable" file sizes. I say somewhat, but it is still half of source usually, unless there is a lot of pixel noise. For the most part if the dvd has a clean mpg2 encode, then that will translate to a lower filesize using CQ for the same quality.

Considering that a 32-bit x.264 file has a 4GB limitation, anything < 14 ends up being unusable from a file size standpoint since the files are unplayable anyway unless you us a 64-bit container, which will break it for most players. Sometimes it will take multiple encodes of trial and error to find the lowest RF value for a given filesize. There is no one size fits all unless your using a higher RF

It may seem like overkill, but I am trying to future proof these files so that in the event my dvds are unreadable (for whatever the reason), I'll at least have something as close as possible. Hard drives are cheap.

 

[taltamir]

I have tons of 4+GB files, I use only MKV and I play it only on MPC-HC (HTPC FTW).

 

[Anteaus]

I have tons of 4+GB files, I use only MKV and I play it only on MPC-HC (HTPC FTW).

I use the MP4 container so perhaps the 4GB limitation is only with it. I just know that it will create files over 4GB, however windows will not show a filesize past 4GB and none of my players will load it. Are you sure you don't have 64-bit switched on? I refuse to use it do to compatibility issues

 

[taltamir]

I use 64bit windows, have been since 2003. (winXP 64bit, which was actually windows server 2003, followed by vista 64bit, followed by win7 64bit).

But the 4GB filesize limit has nothing to do with windows version but with the FS you use. FAT32 is limited to 4GB files, NTFS and exFAT are not.
32bit MPC-HC loads 4+GB files just fine.

What do you mean by "switch on" 64bit?

 

[Anteaus]

I use 64bit windows, have been since 2003. (winXP 64bit, which was actually windows server 2003, followed by vista 64bit, followed by win7 64bit).

But the 4GB filesize limit has nothing to do with windows version but with the FS you use. FAT32 is limited to 4GB files, NTFS and exFAT are not.
32bit MPC-HC loads 4+GB files just fine.

What do you mean by "switch on" 64bit?

Handbrake has a setting called "Large File Size" which enables a 64-bit MP4 container that allows for files over 4GB. Without that switch, it uses a 32-bit container that is limited to 4GB. This has nothing to do with your OS.

The reason I brought it up is because it was mentioned someone was using x.264 files over 4GB, and if your using this feature to create x.264 encodes over 4GB, those files will not work on most standalone multimedia devices, such as the PS3 or 360. If you use the standard 32-bit container, it will continue to encode past 4GB, however windows will not be able to read the header file (you'll notice it won't how long the video is) , and in most cases won't work at all. As far as 64-bit containers, very few decoders can read them. Most PC decoder software won't have any problems.

If you are looking to maximize compatibility, this is an important feature to understand.

 

[taltamir]

Handbrake has a setting called "Large File Size"

Yes, without it it will split files to maintain compatibility with filesystems such as FAT32 and standalone players. I didn't realize that is what you were referring to. I obviously check Large File Size.

This has nothing to do with your OS.

That was my whole point.

The reason I brought it up is because it was mentioned someone was using x.264 files over 4GB, and if your using this feature to create x.264 encodes over 4GB, those files will not work on most standalone multimedia devices, such as the PS3 or 360. If you use the standard 32-bit container, it will continue to encode past 4GB, however windows will not be able to read the header file (you'll notice it won't how long the video is) , and in most cases won't work at all. As far as 64-bit containers, very few decoders can read them. Most PC decoder software won't have any problems.

If you are looking to maximize compatibility, this is an important feature to understand.

I am not interested in PS3 or xbox compatibility, PC is all I want.