I'm running happily for a long time on Gentoo...
just never committed to athlog 64bit mode
what I recall of it was mplayer codecs didnt work in 64bit mode...

is that fixed?
what are any other gotchas?
is it even worth the effort to got 64bit?
what are the benefits, are they substantial.

It depends on what do you mean. win32codecs use flag will be masked, that's not solvable, so don't hold your breath about that. It will be masked forever. This flag install 32 bits dll files, there's no way to fix those since in first place we don't have access to the source code. You can always use a binary precompiled binary, or search for an mplayer-bin ebuild in bugs.gentoo.org or any overlay if you really want to use these dlls.

However, it's really been years since the last time I needed those. Mplayer supports almost any imaginable codec out of the box nowadays without needing that hack anymore.

It depends on what do you use. I have been running amd64 for years and never had a problem. Some people say stuff about flash, but for me it fails the same on x86, so I don't feel like amd64 is the problem there. It works ok here.

Probably not, other than the happiness that it produces the fact of being running the native architecture that your cpu was designed for.

It won't duplicate the speed of your box. That can only be done with money. There's a performance increase in media encoding, it's not a legend. For the rest, I don't think that you are going to notice much difference.

64-bit speed boost alone is 10% at most (x264 is sped up by that much). However, there's often a bigger speed boost - applications compiled for x86_64 can take advantage of a lot of the instruction sets the ix86 compiled distros can't, since they can assume 64-bit procs have them. Of course, you have Gentoo, so you don't need to worry

Other benefits? Upgradeability, over 4GB of RAM is annoying without 64-bit and can hurt speed.

Personally, besides an extra minute to install Flash, I've had no problems due to 64-bit. But it's not huge either.

The codecs work fine you just need the 64-bit ones:
http://www3.mplayerhq.hu/MPlayer/rel...071007.tar.bz2

Benefits, well from my tests most programs complete about 1 second faster than they do on 32-bit, with some exceptions (due to usage of assembly). Not too many other benefits except RAM as Ranguvar said.

some vendors only ship 32-bit binaries...
will they run under a 64-bit linux environment??

If you run multilib yes. But, you need all the 32-bit deps installed too.

They are not the same. The win32codecs use flag downloads this:

http://www3.mplayerhq.hu/MPlayer/rel...071007.tar.bz2 (~13MB)

The amd64 essentials package which you point us to is around 225kb. It's just a matter of availability. Those codec sets are not available for x86_64 on windows either. The reason: I don't know. Maybe a big part of them are written in assembly, which will explain why no one bothered to port them to an OS (winxp_x86_64) which only two persons on the planet use (and surely as server, anyway).

PS: However, as I said, there's really no point in using these most of the time. Mplayer can run natively even wmv9 stuff which was the last blocker that I know of. And drm'd stuff will not work even if you use the dll I think (not tried anyway since I refuse to use anything with drm on it).

So far every video I've tried has worked with mplayer using only the essential 64-bit codecs. The others are perhaps for very rare movie types that I have not yet encountered.

It works, but not because of the 64 bits codecs. It works just because plain mplayer supports almost everything.

I just checked that and that tarball contains .so files, not dll files. Those .so files are contained on the 32 bits package as well. So, the 64 bits essential package is a -very small- subset of the 32 bits package. And it only three .so files, and a README file. Which probably means that it only contains the three codecs whose source was available (and hence, they have been compiled as native amd64 binaries for linux, hence the .so extension).

They are probably not in the main package due to licensing issues (only guessing here).