Crap. After getting a couple of comments saying they tried the same thing, and it didn't work for them, I went back and tried it myself. And it turns out it doesn't work. I think I had tried it with some media that I had already transcoded to WMV without realizing it. The reason it doesn't work is actually quite simple: The managed assemblies aren't pure IL - they're IJW images (lame-speak for "they contain some native code") so they're hard-tied to the platform they're shipped on. I also tried copying the 32 bit version and running them, to no avail. Ugh. Perhaps this will inspire folks to port some of their codecs? Heck, all I really want is FFDShow for x64, and I'd be happy...
UPDATE: FFDSHOW is available for x64 🙂 Still waiting for CoreAVC for x64... Scratch that: I really do prefer VC-1 and WMV. Transcoding takes a long time (at high quality) but the results are great...
Let me paint a scenario for you:
- Because the DVD was just sitting there in your Vista Ultimate box, you installed x64 Vista instead of x86 Vista.
- One of the only reasons you installed Vista to begin with is because the Vista Media Center product is much better than the old XP based Media Center.
- You'll even tolerate the fact that the XBox Media Center Extender doesn't work with Vista (Options: buy an XBox 360, or have an XP MC running somewhere in the house [cuz XP MCE doesn't run on Virtual PC, even just to serve to an extender] - grrrr....)
- You have a number of home movies taken before you paid attention to the fact that WMV is a great container & codec, so there's 3 years worth of home movies in DivX form.
- You open up Vista Media Center and start watching recent home movies - they look great!
- 2 weeks later, your wife opens up Vista Media Center, and calls you at work to tell you that all the home movies of your oldest daughter don't play!
- You go home, launch each of the 70+ home movies from the command line (cuz you're a command line junkie) and they play just fine
- You assume your wife must have had network problems or something, so you tell her they seem fine
- 3 days later, your wife calls you at work, tells you that she CHECKED the network (while she is no longer an employee of MSFT, and has spent the past decade interacting with children more than lead developers (which have a large amount in common), she is astonishingly technically savvy because she is forced to endure your own techno-centricity, bless her soul), and that you're either smoking crack, lying, or magic, because she still can't watch any videos of your oldest daughter from the media center.
Here's the problem: That cool 10 foot media center user interface? C#. UI code in general, because of the whole 'when am I actually done with this resource' aspect of UI code, seems to like garbage collection. I don't know if they use WPF (which looks pretty impressive - I've been messing with it a little, lately), but it's 99% C# code. C# code, by default, is processor agnostic - binaries produced by the C# compiler are flagged to run on ANY cpu. You can take identical binaries and run them on AMD64, x86, and yes, even IA64. And they work fine, in all 3 situations. However, if this managed code tries to use any native binaries on the machine (say, some DirectShow filters, for example), it can only use native binaries for the CPU type it is running on. Which means Media Center is running as a 64 bit app, and can only access the 64 bit codecs available on the machine. No ffdshow, no XviD, no DivX, no, not even any IV32. No problem, right? That's what corflags is for! "corflags.exe <assembly> /32bit+" - bzzzt - wrong answer. Windows Media Center, as part of the OS installation, is covered by a whole host of things to prevent people from screwing it up. In summary: You can't flag the Media Center binaries as 32bit because they won't even load (curse you, code signing and system file protection!).
There is a way to make it work, but it has the unfortunate side effect of making ALL managed code run as 32 bit. ldr64 is a utility that is included as part of the 64 bit CLR that does a single scary, system wide thing: it makes the managed loader think it's running on a 32 bit system, even when it's not. That's right: ldr64 setwow makes your entire computer think, for managed code, it's a 32 bit system. And it works pretty well. Don't do this on your SQL Server or anything, but my Media Center likes it much better when ffdshow is available to be used to show movies of my daughter back before she was losing molars, reading Harry Potter, having sleep overs, and generally being independent enough to make me feel far older than I actually am.
But wait, you say, weren't you smoking crack, lying, or perform some magic that made it work when you tried those media files from the command line? Nope - I was using WIndows Media Player, which, even on Vista x64, is a 32 bit native application. So it was loading 32 bit ffdshow and happily displaying my home movies to my heart's content.
One other minor note: I do find it slightly disconcerting that there's a flag to say IL is 32 bit only, but nothing to indicate that it's 64 bit only. There are plenty of things you can do in managed code (I've been told even verifiable managed code) that can force your code to be 64 bit only, or 32 bit only. The fact that you can only tie it one direction seems slightly sad to me. Oh well - unless you need the address space, the 64 bit managed platform isn't a really compelling platform, currently (okay, the extra registers are nice, but managed code uses pointers like they're char's, so the working set of most managed apps is tremendously higher when running as a 64 bit app, than as a 32 bit one)