32-bit HandBrake GTK GUI and Yasm deb Binary for Ubuntu

Update (5/15/09): I have working binaries of the latest code available in my PPA repository. Directions for adding it to your package manager are available here.

Download HandBrake GTK GUI (GHB) 32-bit deb
Download HandBrake GTK GUI (GHB) 64-bit deb
Download Yasm 0.7.1 32-bit deb
(they're compressed into a tarball, but the debs are inside)

Update: These binaries include a new version of the x264 codec that no longer requires as many options to do the same thing. From Dark Shikari (a main x264 developer):

x264 is removing b-rdo and bime options this week. GUI makers, take note, and prepare patches. bime will be enabled at subme >=5 automatically. New subme options will be organized as follows:

subme6: RD on I/P frames

subme7: RD on all frames

subme8: RD refinement on I/P frames

subme9: RD refinement on all frames

new subme 6 = old subme 6

new subme 7 = old subme 6 + b-rdo

new subme 8 = old subme 7 + b-rdo

new subme 9 = didn't exist, RD refinement in B-frames is completely new.

RD refinement in B-frames consists of qpel-RD as in P-frames, and also RD-bime for bidir blocks. Overall the speed cost for this option should be less than old subme6->7 (new subme7->8).

This is a first step on the road to decreasing the number of unnecessary options in x264.

I finally got my 32-bit Hardy Heron build environment set up, so first thing I did was crank out a couple of debs for the yasm assembler and HandBrake's official GTK GUI (known as GHB) from SVN.

Yasm is version 0.7.1 and GHB is version svn 1911.

Leave me a comment if these do/don't work.

How to Hack Mario Kart Wii Online for Unlimited Items Including Blue Shells

Update: looks like it's easier to cheat nowadays. If you install the homebrew channel, you can enable cheats from there. I don't know the specifics, so feel free to leave a comment if you know any more than that.

Update (6/19/09): from reader Rosalina, you can indeed hack it from the homebrew channel:

Materials:
A Homebrew Channel on your Nintendo Wii
An SD Card
Ocarina in your SD Card
Legend of the Twilight Princess for Wii

Use Legend of the Twilight Princess game to get Homebrew Channel and then
Go to File and then open TXT file. Then select rmce01 is Mario Kart Wii's ID. Then go to add a code/comment. Type in as many as you want but make sure you call it what it is called in the Mario Kart Wii Instructions Manual. And make sure you put “Infinite” before the power you want (the most fun powers are Star, Mega Mushroom, Triple Red Turtle Shells, Triple Green Turtle Shells, Bullet Bil l(the rocket) and some time Triple Banana, Fake Item Box and Bomb-omb.) OK? Now type the codes in the code box {codes are at www.usbgecko.com/codes}. Insert the SD Card into the PC and then go to 'Export to GCT' and select your SD Card. Insert the SD Card into your Wii and go to the Homebrew Channel and press start. You will be able to hack Mario Kart on the Homebrew Channel. My guess to stop hacking Mario Kart is to take your SD Card out of your Wii.

This information is out of date, but I'll leave it here for posterity:
I did some digging and this guy who goes by the handle /dexter0 (aka ihack@you) appears responsible for this nonsense (46 pageviews when I accessed it), but I could be wrong. It appears this hack is accomplished using a USB Gecko attachment, which is pretty much like an Action Replay or a GameShark.

He basically just edits the database values that represent your item box status to choose what item you have at any point (resulting in unlimited items).

From /dexter0 (aka ihack@you):

These codes were hacked under NTSC-USA. And since they involve assembly hacking, they are not easily ported. So don't ask for PAL or JP codes.

[Write Char Offset]
D27E4DDC 00000002
3FE08000 93BF1500
3BE00000 00000000

[Always Have Item *Works anywhere] - Add Your Own Button Activator
48000000 809BEE20
DE000000 80008180
58010000 00000014
DE000000 80008180
48100000 80001500
DE000000 80008180
1400008C 000000XX
14000090 0000000Y
E0000000 80008000

...you need both of them for it to work. The Write Char Offset must come first! And don't click the apply button while a race is active, you'll crash them game.

Have fun. Try not to be a dick.

If you wish to report a cheater, drop a comment on my Wall of Shame page with their name and a description of their Mii (if available).

How to Enable Surround Sound in Ubuntu Linux

Update (04/21/10): The information in this original post is no longer applicable since Ubuntu switched to the PulseAudio sound infrastructure. I'm leaving it all here for reference, but here's how to do it now:

Step 1: open up a terminal (Applications > Accessories > Terminal or Alt+F2 and type 'gnome-terminal' into the command applet)

Step 2: at the command prompt, type alsamixer

Your prompt should change to something like this:

Step 3: Scroll all the way to the right (using the arrow keys) until you reach a section labeled "Channel." It will most likely say "2ch" over it. Press the 'up' arrow key until it says 6ch (for 5.1 surround) or 8ch (for 7.1 surround).

Exit the alsamixer program by pressing ctrl+C. You should be all set. You may have to go into your Sound Preferences and change either the 'Profile' setting on the 'Hardware' tab or fiddle with the devices in the 'Output' tab. I didn't have to do this, but you might.

If you have any problems, leave me a note in the comments and I'll try to help.

Update (10/08/08): I was using Gutsy when I wrote this post, but I have since upgraded to Intrepid Ibex (8.10) and it still works for me. YMMV

I've been hard at work lately trying to get my motherboard's (an Asus M2V-MX SE socket AM2) 6-channel surround sound working with Linux and it's been a surprisingly stubborn pain in my ass. However, I finally succeeded this past weekend and decided to document my process here for others to hopefully benefit from.

The first complication I ran into when trying to get surround sound working is that my mobo does not have the normal multichannel output jacks. That is, instead of having the blue, orange, and black plugs that are in most multichannel setups, it instead just has what appears to be standard blue, pink, and green jacks that are usually used for stereo output, mic-input, and line-in, respectively.

What is poorly documented, though, is that the pink and green jacks can double as the orange and black plugs when enabled by software. It's a stupid way of doing things, IMHO, but low-end mobo manufacturers apparently do it to save costs.

Anyway, in Windows, enabling this hidden functionality was accomplished using the Realtek Sound Manager program that was installed with my sound driver. However, as with damn-near all driver utilities, it does not have a Linux equivalent.

Instead, open the Alsa-mixer GUI by double-clicking on the speaker icon in the upper-right of the screen (a.k.a., the Volume Control applet):

Then select 'Preferences' from the 'Edit' pull-down menu:

From here, you'll want to scroll down a bit and check the 'Channel Mode' box, and you'll probably want to check the 'Surround,' 'Front,' 'LFE,' and 'Center' boxes as well:

When you go back to the main applet, click on the 'Options' tab, which should now have an option to choose the number of channels:

Select '6ch' for a 5.1 setup or '8ch' in a 7.1 setup. This should unlock the hidden functionality of those pink and green jacks. On my system, the pink jack converts to the orange function and the green converts to the black function, but YMMV.

You could stop here, but I suggest doing one more step to make sure everything is configured properly. Open up a terminal and type:

speaker-test -Dplug:surround51 -c6 -twav

This will make a creepy disembodied voice play through each channel in succession so you can be sure your speakers are plugged into the right jacks.

Btw, this command is for a 5.1 / 6-channel surround card. A 7.1 system will use this command instead:

speaker-test -Dplug:surround71 -c8 -twav

For some people (like me), the system automatically duplicates the front channels' sound to the back channels for listening to stereo sources, such as mp3s, normal non-DVD video files, etc. Other people, however, will need to do a bit more to make this happen. If you're one of these people, open up a terminal and type:

gedit ~/.asoundrc

Whether this file is blank or already has some stuff in it, just skip down to the bottom and copypasta this in (courtesy of the Gentoo wiki):

pcm.!dmix {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
channels 6
period_size 512
buffer_size 1024
}
}
pcm.!default {
type plug
slave.pcm "dmix"
slave.channels 6
route_policy duplicate
}

You may have to change "hw:0,0" to something else, depending on your sound card's location. When you restart, surround signals will still work like before, but stereo signals should be duplicated. If, on the other hand, you have no sound or your sound is weird, just reopen the ~/.asoundrc file and delete the part you added (or try one of the other configurations from the aforementioned Gentoo wiki). No big deal.

Let me know in the comments if this works for you or not or if you have any questions.

How to Compile QT4 GUI For HandBrake

This is a guide for compiling the QT4 GUI for HandBrake that was updated by gonza from the HandBrake forums. I posted this guide on the Ubuntu forums, but I wanted to post it here as well so it could be updated as needed.

Update (5/15/09): I have working binaries of the latest code available in my PPA repository. Directions for adding it to your package manager are available here.

install git if you don't already have it (sudo aptitude install git-core), along with the dependencies for HandBrakeCLI, then type

git clone git://repo.or.cz/HandBrake.git

navigate to the newly created HandBrake directory:

cd HandBrake

and add the bonne/qhandbrake branch (all on one line):

git checkout --track -b bonne/qhandbrake origin/bonne/qhandbrake

You might need to type git pull just to make sure you're up to date. Then, compile HandBrakeCLI as normal:

make

navigate to the qt4 directory:

cd qt4

and then compile the GUI (dependencies include qt4-core and qt4-dev-tools, I think):

qmake && make

You should be left with a binary named qtHB. This GUI is feature-complete (as far as I can tell), including video previews, a working queue, advanced x264 options, presets, and so on. You can run it by typing ./qtHB into a terminal, or you can copy it into your /usr/bin directory like any other program.

Unfortunately, qtHB *refuses* to bundle into a proper deb binary, but I believe you can download and run my precompiled binaries as long as you have the proper qt4 dependencies installed.
Download 64-bit qtHB
Download 32-bit qtHB

HandBrake GUI Roundup

I previously posted all of this information in a thread at the Ubuntu forums, but I wanted to post it here, too, so I could update it as new versions/information arise. This is a list of all of the GUIs/frontends (that I know of) for HandBrake, along with information regarding features/limitations and development progress for each.

1. GHB is the official GTK GUI that is included with the HandBrake source code (currently just available in the SVN repository). It was written by a swell guy known as JohnAStebbins from the HandBrake forums and it's nearly on par with the OS X GUI in features. However, some people have trouble getting it to compile. On Ubuntu, it requires at least Hardy. (you can download 32-bit and 64-bit deb binaries from here or you can compile from source using HandBrake's official SVN repository [directions here]).

2. qtHB (aka qHandBrake) is an early, yet promising GUI based on the official QT4 HandBrake code that languished in SVN until a HandBrake forums user known as gonza updated it recently. It is still in early development and not yet included in the official SVN code, but it is nearly as complete as GHB and significantly easier to compile (fewer dependencies). (You can read about it here or download and compile it using my instructions here).

3. HandBrakeGTK (aka RippedWire) is a port of a Windows CLI wrapper that requires mono-devel to run. It has a bug that causes it to not pass advanced x264 options to the CLI, which is a total deal-breaker for me. However, its queue feature works well, so it can be useful for batch rips if you don't mind using baseline AVC. It also works well with other codecs, such as xvid, that don't suffer from the adv. x264 opts bug. Another advantage is that you can easily update the HandBrakeCLI backend without affecting the graphical frontend. RippedWire does not appear to be in active development. (read about its history here or download it here. 64-bit users can try this one, which I built from the author's mono project files on my 64-bit system [just install mono-devel, move the executable into the same directory as your HandBrakeCLI binary and type mono HandBrakeGTK.exe]).

4. gHandBrake is a GTK CLI wrapper written from scratch by a guy that goes by Derrik81787. I later added x264 options to it, but I'm a terrible programmer and it ended up really unstable. Derrik seems to have dropped the project because his site for it is gone (Update: he's too busy with classes to work on it now but plans to revisit development in the future), but I would love to see someone tweak the code for better stability (the big issue appears to be with malloc, which I know nothing about; leave a comment if you'd like to pitch in). The major advantage to this frontend is that it is really easy to compile and it has very simple dependencies, unlike the official GTK GUI. (read about it here or download it here).

If you have anything to add, or if you have any corrections, please leave me a comment.

How To X-Forward On a Mac

If you're a terminal-jockey and you use a Mac, you've probably come across the term 'X-forwarding' before, but very few places will actually tell you what it is or how to do it.

The X Windowing System is an open source window manager that's used to draw windows in most free operating systems, including GNU/Linux, the *BSDs, and Solaris. It was ported to OS X in the form of the XQuartz project and is distributed with Tiger and Leopard install DVDs. You can also download it here if you're using Leopard (10.5), here if you're using Tiger (10.4), or here if you're using Panther (10.3).

Once it's installed, you can do a lot of cool stuff. For instance, you can run many more open source programs than before (check out Fink and Darwinports), and (more importantly for me) you can X-forward from any other computer that is currently running X.

What that means is that you can open an instance of an X-native program from another computer using your Mac and it will seem (to you) as though it were running on your Mac (i.e., you will have a window appear on your desktop that you can move, minimize, etc., but it uses the other computer's resources). It ends up being sort of like a remote desktop--such as VNC--but faster and without affecting the experience of local users. For example, I use X-forwarding to run programs from my Linux media center while my wife watches videos.

To do it, the remote computer you want to X-forward from has to have an SSH client--such as OpenSSH--installed. Once that is in place, open the Terminal.app on your Mac (located in Applications > Utilities by default) and type:

ssh -X username@target.IP.address.here

You have to use an account that already exists on the remote computer. It will then ask for the account's password. You will then be logged-in to the remote machine via your local terminal. Your command prompt will also change to reflect this:

Now, you can run programs via this terminal and any windows will be drawn on your local computer (i.e., your Mac) instead of the remote computer.

Here is what it looks like when I forward the Linux QT4 GUI for HandBrake to my Mac:

As you can see, the widgets look a little weird, and the font is clunky, but it's fully functional and has much lower latency than other remote access methods. Also, thanks to the ssh connection (also known as an 'ssh tunnel'), your connection cannot be spied upon, even if you X-forward across the Internet. Leave me a comment if you have any questions or run into any problems.

Comparison of x264/h.264 Advanced Options (With Pics)

x264 is a popular (relatively) new codec that's extremely efficient and capable of producing a quality picture even at very low bitrates. Since it has largely replaced DivX/Xvid as the codec of choice for online video, users need to know how to maximize their video quality when using this new codec. The very best quality can only be achieved by tweaking the codec's advanced options, which is a daunting task. Therefore, I have conducted a side-by-side comparison of many of the most useful options so you can decide which ones work best for you (click the pictures to see full-size).

Note: the differences are often quite subtle. If you have trouble spotting them, try looking at the reflection on the fingernails, the quality of the teeth, the edge of the index finger against the black background, and the color gradients on the skin. These are the places where differences will be most apparent.

Some caveats: every video is different and different options work better for different sources. I tried to pick a test video that would be fairly representative of what you would encounter in normal use but your mileage may vary and I make no guarantees about anything. However, I tried to be as transparent and systematic as possible so you can feel free to reproduce my testing if you see fit***. In the comparisons, I will frequently refer to "peak signal-to-noise ratio" (PSNR; higher is better), so if you're interested, you can read up on it at the Wikipedia.

I used HandBrake for my testing, but the results should be equally applicable to mencoder and maybe other programs that support advanced x264 options. Extensive text-based discussions of these advanced options are available at the official HandBrake and Mencoder sites, so I will try not to overlap with them too much. You can think of my comparisons as a visual adjunct to these discussions.

2-Pass Encoding (-2; not really an x264 option, but very important)

The singlemost beneficial thing you can do for a variable bitrate encode is switching from single-pass encoding (the default) to 2-pass encoding. This means the encoder spends the first pass analyzing the file and figuring out where the most bits will be needed (e.g., high-motion scenes) and then it attempts to make the quality similar throughout the file. The drawback to this strategy, of course, is that it takes ~2x as long to finish, but the benefit is large (0.988 dB) and easily noticeable with the naked eye:


Subpixel Motion Estimation (subme / subq)

Subpixel motion esimation (subq) is the next-most-important option. HandBrake defaults to a setting of 4, but I recommend using a setting of 7, which is slow but provides an increase in PSNR of 0.292 dB beyond the default. Using a setting of 1 looks terrible and provides a PSNR hit of -0.325, though it has the benefit of being much faster than the default:



Trellis (trellis)

The trellis option provides the next largest benefit (0.158 dB) at the cost of a somewhat slower encode. Enabling this option also makes a striking difference in fine, hard-edged details, such as on-screen text, as demonstrated by the MPAA rating screen:



I've seen examples online of people using a setting of 2, which they claim improves the quality, but that just isn't supported by these benchmarks, so don't bother using a setting other than 1. Update: turns out using a value of 2 does do something (at the cost of slower encodes), but not unless your subme value is 6+.

The maximum subme value increased from 7 to 9 since I originally wrote this article. I used the new maximum setting for these encodings and they all turned out pretty similar with this highly complex setting, but you can still see some pretty noticeable improvements with each trellis bump. With trellis=0, we can see some blocking and a weird artifact on her tooth; the average encoding speed with this setting was 24.427734 fps. Trellis=1 is a little better but still has some discoloration, while the average encoding speed was inexplicably faster at 24.567919 fps. Trellis=2 is a little smoother than either of the other settings, but it had approximately 20% slower encoding speed, at 19.798990 fps, which may not be worthwhile for all applications.

PSNR was a real mystery to me in this comparison. The average PSNR actually fell as trellis use increased, despite some pretty clear visual improvements. Global PSNR also appears wonky, as it dips slightly with trellis=1 and then increases slightly more with trellis=2. These results really showcase the danger of relying on PSNR for assessment, as it is clearly an imperfect measurement.

Reference Frames (refs)

Next up, we have the number of reference frames. The default is 1, but increasing it to 3 provides an increase in PSNR of .079 dB and increasing it to a value of 5 provides a further increase in PSNR of .043 dB. Unfortunately, diminishing returns sets in quickly and ramping the value up to 12 provides only a further benefit of .034 dB at significant detriment to encoding speed:



Also, be wary of adding too many reference frames, as Quicktime may struggle to play back videos with large amounts. Furthermore, the number of reference frames interacts with the subpixel motion estimation setting to determine how much longer your encoding will take, so experiment to see what works best for you.

Mixed Reference Frames (mixed-refs)

Using >1 reference frames unlocks the ability to use mixed reference frames, which provides a modest improvement in PSNR of .035 dB:



B-Frames (bframes)

In my experience, the b-frames value is roughly as important as the reference frames value with respect to PSNR. Going from the default 0 b-frames to 1 b-frame provides a noticeable 0.12 dB benefit in PSNR. However, diminishing returns are apparent immediately whereby upping the value to 4 provides an additional benefit of only .069 dB, and ramping it up to 16 b-frames actually worsens the picture by -.033 dB:



According to the HandBrake wiki, you can use more b-frames in animated content (~10-15).

Weighted B-Frames and Pyramidal B-Frames

Once you enable ≥1 b-frame, you can also benefit from weighted b-frames and/or pyramidal b-frames. These options provide modest benefits to PSNR of .016 and .01 dB, respectively:




Be aware: enabling pyramidal b-frames is a "high-profile" feature that will totally bork Quicktime playback. Don't use it if you plan on watching your video on a Mac.

Motion Estimation Method (me)

This option determines the method used to estimate motion in your video. Options include hex (hexagon; the default), umh (uneven multi-hexagon; the highest quality), dia (diamond; not shown), and esa (exhaustive; not shown and not to be used). Umh is the highest quality but slightly slower than regular ol' hex; it provides a noticeable .159 dB improvement in PSNR:




Also included in the previous comparison is the motion estimation range (me-range) option, which provides a modest .048 dB improvement in PSNR at the cost of slower encodes.

Analysis (analyse)

The analysis method makes very little difference and I recommend sticking with the default. Switching the value to 'all' provides a miniscule .004 dB increase in PSNR (too small to see).

After enabling the 'all' analysis, you can also enable the use of 8x8 DCT analysis option, which, strangely, hurts PSNR by .07 dB:



No Fast P-Skip (no-fast-pskip)

The HandBrake wiki says this option helps "with blocking on solid colors like blue skies," but I didn't really see any benefit of it in that regard. On the other hand, it reduced the PSNR by a fairly substantial (considering the lack of benefit) -.048 dB, so it's up to you whether or not to use it:



Disabling P-skip might also have more of an impact on animated content, which generally features larger patches of solid colors than live content.

Deblocking Filter (filter)

This option tweaks x264's built-in deblocking filter to smooth out edges--and details--from the picture. It's kind of like using a PhotoShop filter on each frame, with positive values acting like a smoothing filter and negative values acting like a sharpening filter. The default, 0,0, is almost always the best, according to the HandBrake wiki, but I prefer a bit of smoothing and loss of detail (around 2,2). A lot of people (apparently) prefer using negative values, but I think that looks like crap and adds a lot of noise to edges:



Either way, you take a PSNR hit of approximately -.067 dB.

CABAC vs CAVLC

CABAC, the default option for HandBrake, is good for every use except when playback on iPod 5.5G and AppleTV are necessary. If you turn it off (cabac=0), HandBrake will use CAVLC instead, which is visibly detrimental and imparts a tremendous PSNR hit of -1.542(!!):



Direct Prediction (direct)

The HandBrake wiki makes this option sound really important, but changing the values had absolutely no effect on PSNR or appearance in my experience, so I suggest just leaving it alone:



Turbo First Pass (-T; again, not an advanced x264 option, but very important)

The turbo option significantly speeds-up the first pass of a 2-pass encoding by passing faster options for the first pass and slower, higher-quality options for the second pass. The HandBrake wiki mentions that the turbo option may slightly reduce quality, but my experience was exactly the opposite. Due to the nature of the option, I compared an encoding with a variety of slow, high-quality options with and without the turbo option included. Interestingly, this resulted in an increase in PSNR of .054 dB in the turbocharged encode:



Bidirectional Refinement (bime)

The next option, bidirectional refinement, depends on several other options that I couldn't readily identify, so I did a similar comparison to what I used with the turbo comparison (i.e., a variety of slow, high-quality options with and without bime). This yielded a PSNR benefit of .014 with bime turned on, which is probably unnoticeable, but worthwhile if you're looking for the best quality possible:



Threads (threads)

The threads option just allows you to specify the number of threads HandBrake will use while encoding. This makes no difference on single-core processors, but makes a huge difference on multicore processors. HandBrake defaults to automatically decide the "optimum" number, but I find I get slightly higher processor utilization if I assign a value of 4 on my dual-core AMD X2 4000+.

Deinterlacing (-d; not an x264 option, but it's pretty important so I figured I'd throw it in)

Interlaced video (as opposed to 'progressive') has a bunch of crazy-looking lines--known as scanlines or combing--in some frames and it makes videos look awful. If you want to get rid of them, HandBrake has a really great built-in deinterlacing filter that fixes things right up. I tried comparing "-d slowest" with plain ol' "-d" and they were exactly the same, so I've only included a comparison with and without the vanilla "-d" option:


Of note, deinterlacing does not affect PSNR, though it does significantly impair picture quality and introduces 'jaggies.'

Update (5/4/09): HandBrake has recently introduced a new option known as Decombing, which analyzes each frame and detects combing and only runs the deinterlacing filter on those specific frames. This is a huge improvement over regular ol' deinterlacing because it only affects the necessary frames and leaves the other intact. Furthermore, you can leave this option on all the time (i.e., include it in custom presets) and it will only kick in when necessary.

Adaptive B-frames: (b-adapt)

If I understand correctly, this setting analyzes your file and determines the optimum number of b-frames, up to the maximum you specify in the b-frames field. This means you can crank your b-frames setting up to, say, 16 and it will only use as many as it feels are necessary (almost never more than 10, so 16 is overkill, but you get the idea). Within this setting, you have 3 choices: 'none,' 'fast,' and 'optimum.' 'Fast' is much better than 'none' and 'optimum' is very slightly better than 'fast.' Importantly, 'fast' only imparts a slightly longer encoding speed than 'none,' while going from 'fast' to 'optimum' will drop your encoding speed by 50%(!!!) for a largely unnoticeable difference. Therefore, I recommend using 'fast' unless you're a real stickler for whom time is no object. I hope to get a comparison of these options up here in the near future, so stay tuned.

My personal settings

Each of these options may not provide much benefit on their own, but the improvements certainly add up. My settings result in a high-quality rip (PSNR of 41.232 vs 35.933 with the default options; approximately 13% improvement) that remains (mostly) compatible with Quicktime but with a 60-80% worsening in encoding speed (from ~60 frames per second with default options to ~15 frames per second with my settings). Here is a comparison of the vanilla x264 options and my personal settings so you can decide for yourself if it's worthwhile for you:



I also use a higher bitrate (800-900 kb/s) when doing my actual encodings (not in this comparison), which obviously improves quality a great deal. Here are my x264 options:

ref=5:mixed-refs:bframes=4:bime:weightb:b-rdo
:me=umh:subme=9:filter=0,-1:trellis=2:threads=4

I also use the non-x264 options of -2 and -T. Update (5/4/09): I used to be all about the 2-pass encoding, but I now prefer constant quality with CRF enabled. It takes the same time as 2-pass overall but gives consistent quality that is slightly better throughout the file, in my experience. I hope to post a comparison sometime in the near future.

***My source video is a preview for Jackie Brown that appears on a Pulp Fiction collector's edition something-or-other. All comparisons used frame 460 (or 1120 for deinterlacing comparisons). For testing, I used a bitrate of 300 kb/s, which was intentionally low so the benefits of different options would hopefully be more visible. Nevertheless, x264 is so good at preserving quality that I had to zoom in 400% to get a good look at the details. So as not to introduce artifacts from upscaling and/or jpg compression, I used png (lossless) screencaptures at the native resolution for all initial adjustments (zooming, compositing, etc) and only switched to jpg (lossy) at the very end for posting online. I placed all streams into a matroska mkv container and used AC3 passthrough for the audio.