Nope.

Initial Setup

To get things started, pretty much everything worked out of the box in so far as what was advertised — the Philips universal remote never advertised explicit compatibility with my IR receiver. On the other hand, I had it controlling both my TV and sound receiver in under five minutes. Likewise, once I found out which driver to use with my USB IR receiver, LIRC was very straightforward to configure.

The Problems

As it turns out, there was no device code in the Philips documentation for Microsoft Media Center Edition remote compatibility, so I was on my own. I tried using the learning feature of the remote with mediocre results. Sure, it would eventually learn and reproduce given IR codes but the lag time associated with learned codes on the remote was astonishingly bad. Not to mention that pressing and holding a button was out of the question with learned codes. Try scrolling through hundreds of movies that way.

The Solution

I was able to find a preprogrammed mode for the universal remote that actually made independent use of [almost] all of the buttons on there, and put the remote into that mode. As it turns out, such a mode for the Philips universal remote is the for the ReplayTV DVR. Then I taught LIRC to understand the codes out of that mode using irrecord.

The Outcome

Perfection.

Note: Here we will assume that ProFTPd has been configured for SQL authentication.

Restricting Access Via Shell

The first thing that needs to be done is to restrict permissions on the FTP disk so that shell users aren’t allowed to read it. This requires some simple UNIX permissions knowledge, and I used the following to get the job done.

chown -r gongloo:ftp /var/ftp
find /var/ftp -type f -exec chmod 640 {} \;
find /var/ftp -type d -exec chmod 755 {} \;

That’ll set the permissions for all directories so that they can be opened by anyone but written to only by gongloo, and permissions for all files so that they can only be read by those in the ftp group and, again, can only be written to by gongloo. This means that any users who have FTP access as well as shell access will be able to list, but unable to read, the files on the FTP disk via shell.

Now all that we have to do is make sure that the ftp UNIX group contains only members that should have access to the FTP disk via shell.

Allowing Access Via FTP

The second thing we need to get done is to allow access to the files via FTP for those users who should have it. This is fairly straightforward if we configure ProFTPd to assign GIDs directly from the SQL database that it uses as its authentication backend. We simply create an entry in the SQL table for ProFTPd groups matching the ftp entry in /etc/group. I used something like the following:

INSERT INTO groups (groupname, gid, members) VALUES
('ftp', '21', 'userid1, userid2, userid3, ..., useridn');

And that’s it! Users listed in the ftp group in the SQL database are now able to grab files off of the FTP disk. Huzzah!

Definitions & Limitations

First, I should provide some definitions and/or limitations; in order to make any claims we first need to lay down some commonly accepted premises. I’m not going to argue that the following definitions are universally correct or even that they represent any general consensus; this is just how I define the following terms and what these definitions mean — subjectively — to me.

1080p

This one is going to be controversial. Technically speaking, a video is defined as within the 1080p standard if (a) its picture is progressive (non-interlaced) and (b) the picture is made up of 1,080 rows of pixels. What is implied but not specifically stated in this definition is that the aspect ratio of a 1080p picture is 16:9, yielding a resolution of 1920×1080. However, since many movies are filmed in wider aspect ratios, commercial 1080p media is often letterboxed in order to avoid cropping. As such, for my purposes, I define 1080p to be any picture with 1,920 columns of pixels.

H.264

The H.264 codec is an ugly multi-headed beast. The specification for this particular video codec provides many different profiles which all require different amounts of processing power to encode or decode. There are all sorts of available ‘options’ within the standard and many of them probably require a supercomputer just to decode (in 1080p) in realtime. For the purposes of this discussion, I’ll say that we’re dealing with the baseline or main H.264 profiles, using a reasonable amount of b-frames and reference frames — say, one to three — at a reasonable bitrate of about 10mbit (average) for 1080p films, using CABAC. Most of my test clips were encoded using the wonderful x264 open-source H.264 encoder.

Hardware

When I set out to build a Home Theater PC (HTPC), I wanted to keep 1080p H.264 playback in mind, and knowing that this problem is computationally difficult, I bought fairly high-end hardware with budget somewhat in mind. I won’t argue for or against my hardware, since that’s a whole different debate better suited to people more so inclined. I will say that my hardware works me.

Processor

Whilst not getting into the AMD vs. Intel debate, I will say this: I feel that going with AMD is more cost-effective. At time of purchase, the chip I bought had just had a huge price drop and as such became quite attractive. Once I got the components together and verified that everything worked, I overclocked this bad-boy from its stock 3.0Ghz (200Mhz x 15) to 3.15Ghz (210Mhz x 15) just to squeeze a bit (5% to be precise) out of it. Whilst I could get it to run at 3.3Ghz, it wasn’t stable and I wasn’t willing to bump the voltages up too much on the stock cooling I have. Currently this processor runs at around 35°C idle and around 65°C under load.

Motherboard

This is where I spent a lot of time researching. I wanted a motherboard that had as many integrated components as possible. Most motherboards these days have integrated sound but not all have integrated sound with optical out, which was an absolute necessity for me. I was also looking for a motherboard with integrated video. I found this one with the added bonus of having integrated HDMI. I couldn’t get the sound pass-through over HDMI working under Linux, but since I have an optical connection to the receiver anyways I’m not too fettered about it.

RAM

Quite simply, just whatever cheap dual-channel 800Mhz RAM compatible with my motherboard I happened to find on newegg.com.

Video

As I found out just after putting all of the hardware together, ATI’s drivers for Linux do not support XVideo (hardware accelerated video scaling, color-space conversions, and display), rendering the integrated video card on the motherboard less useful. I decided to buy the cheapest PCI-Express NVIDIA card I could find, making sure that it was fully supported with the latest NVIDIA Linux drivers. More on this in the software section below.

Display

Most new HDTVs now have some sort of direct-from-computer input — mine has a DVI port right on the back. Some HDTVs, however, do some overscanning and other image processing on the signal received, even for digital signals. Depending on the source, this can be good or bad, but in general when attaching a computer to a display you want a 1:1 (no overscan) pixel mapping. Fortunately my display supports this via its DVI port.

Software

There was no doubt in my mind that I’d be running Linux, so hardware acceleration of H.264 playback was immediately a no-go: the driver support just isn’t there yet. It turns out that I’m pretty much stuck with ffmpeg’s H.264 decoder for playback (I won’t get into the controversial CoreAVC-on-Linux fiasco here other than to say I’m not about to go hacking up mplayer code to get CoreAVC on Linux under 64bit). But there’s more to playback than just decoding the input video stream; once the stream is decoded, there is an often necessary colorspace conversion to do, there may or may not be some scaling involved, and of course you have to get the decoded image to the display somehow, which can take significant amounts of compute time.

Decoding

The ffmpeg H.264 decoder is really great with one major caveat: it’s not multithreaded. This means that no matter how many cores you have, H.264 decoding will use exactly one. I hear there’s some work being done on parallelizing said decoder, but as of yet I’ve heard of no working prototypes let alone a release. Knowing this is mostly why I wanted such a high clock speed for my main processor, regardless of how many cores it has — for sure I would have bought a cheaper, slower dual-core processor had the ffmpeg H.264 decoder been capable of taking advantage of two cores simultaneously.

That having been said, there are some decoding options that you can pass to ffmpeg’s H.264 decoder via mplayer that will improve performance at the cost of quality. Specifically, there’s the ability so skip all of the in-loop filters (deblocking, mainly), which should yield a performance increase of ranging from zero to three hundred precent or more depending on the source material and encoding options. Simply invoke mplayer with the option -lavdopts fast=1:skiploopfilter=all — you can read more about these in your mplayer manpage. If your processor just isn’t capable of handling H.264 videos you’re trying to play, a good first pass is to try disabling in-loop filters. If your processor still can’t handle it, it’s time for you to upgrade — there’s pretty much nothing else you can do.

Displaying

Once a video stream has been decoded, it is typically sent to a display for viewing. Often this involves colorspace conversions and/or scaling. In my case, with 1080p playback, there is typically no scaling necessary as my display is exactly as large (at least in the limiting dimension) as the image being displayed. In the case of 720p on a 1080p display, however, some upscaling needs to be done. Some upscaling and colorspace conversion computations can be done in hardware on your graphics card if your graphics drivers are capable and set up for it. One such technology under Linux is XVideo, or XV for short.

XV can handle colorspace conversions and upscaling natively in graphics hardware so that your CPU doesn’t have to burn cycles doing so. In the absence of XV, I have found mplayer’s X11 output driver to be the best on my setup. Even though the X11 processing seemingly went on in the X11 server (according to top), which of course does not run on the same core as mplayer so as to maximize performance, I found that using the X11 display driver cause a significant decrease in video playback performance — enough to drop a few frames in some test clips. Since the ATI drivers for the integrated graphics chipset on my motherboard do not provide XV capabilities at time of writing (note that this is a specific case for my video chipset, the X1250 — most other ATI chipsets boast XV support in the proprietary ATI drivers), I bought a cheap NVIDIA card that I knew would work with XV. Once I had XV working, I was able to play back clips that had previously stuttered due to dropped frames.

It is my preference, however, to not upscale videos using XV, as generally I find the results to be much better when using a decent software upscaler. This is especially visible when viewing, for example, NTSC television captures on a 1080p display. There are a number of software upscale implementations bundled with mplayer, and for most people the default will suffice. If this is a bit too CPU-intensive, though, I find that the fast bilinear algorithm does a fairly good job and is a little bit less CPU intensive than the default bicubic algorithm. To select this, simply invoke mplayer with the -zoom -sws 0 arguments. Of course, the quality of the upscale will depend on the source and the algorithm of choice, so as with anything else, try a few of the different options and go with what you prefer.

A Note On Sound

I run an optical line between my HTPC and my sound receiver and use it for both PCM and surround (Dolby or DTS) sound. While this article is, as the title suggests, about video, I feel compelled here to mention that decoding surround sound in software does take a nontrivial amount of CPU time. You’ll be much better off — for a number of reasons, compute time inclusive — sending the audio stream to a hardware decoder (read: sound receiver) for playback there. Sometimes the little bit of difference that decoding sound can make is what you’ll need to avoid a few dropped frames here and there.

The bad news: One of the drives in the FTP array died.

The ugly news: LVM didn’t want to activate the array in partial mode.

Read on for technical details and how I revived a dead LVM array with a missing drive.

About a week ago, I realized that one of the disks in my LVM array was dying, with I/O errors on certain sectors of the drive. Not wanting to take too much of a risk (of course, no backups and no mirroring, ’cause the cool kids live on the edge like that), I decided to initiate a pvmove immediately. Trying to be smart about it, I decided to do the pvmove in chunks rather than have it process the entire drive at once. Of the 3500 or so physical extents of 32MB each, I did my moves in the following fashion and order.

Amazingly enough, the drive died completely during the metadata update phase of the move. This means that all of the data was actually mirrored by that point (or at least as much of it as could be read from the device without error). What threw me off was that LVM simply refused to activate the volume group and logical volume(s), even in --partial mode.

After failing to bring back the volumes using partial mode, I started to try a bunch of random, even crazy, solutions. Word on the grapevine is that you can sometimes revive a dead drive by freezing it — literally, in the freezer. So I left the culprit in the freezer for an ninety minutes, and then gave it a shot. Still no dice, though this technique has apparently worked for others.

Just before deciding to completely scrap the entire volume group, I thought of something only half-crazy. Why not complete pvmove‘s job by hand? It should be fairly straightforward to manually modify the volume group configuration and overwrite the currently loaded configuration with my modified version. I was able to do just that, with some calculations as to which physical extents belong in which sections of which logical volumes.

Somehow, I ended up getting things right on the first try (if I had a dime every time that happened, I’d still be dirt poor), and am pleased to announce that I don’t see any data integrity loss! After checking a routine check of all of the remaining devices for bad blocks (lest this happen again right away) and then a routine e2fsck -y to fix any errors on the filesystem, all was well! Thankfully the aforementioned dead sectors (on which those I/O errors occurred) stored blank nodes on the filesystem anyways, so things just worked themselves out.

That having been said, I’m definitely keeping an anxious eye on ZFS and specifically its port to Linux. Looks like it might solve some of my problems!

After some quick reading online, and the lovely tab-completion available in bash, I found the pvmove command, and decided to put it to use. After not receiving any output for several hours, I decided that the process had hung and killed it. When running pvmove --abort, I got a few instances of the following error.

reload ioctl failed: Invalid argument

So I hit the books internet again, and happened upon a similar bug report on Debian’s bug tracker where it was suggested that perhaps the version of the kernel drivers for lvm2 and the versions of the userspace utilities/libraries were out of sync. Since I’m running almost the latest kernel (2.6.17; 2.6.18 was just released), I decided to upgrade to the latest released lvm2 utilities and libraries. Once this was done, everything worked like a charm!

Oddly enough, the old configuration reflects the latest available packages as keyworded stable for amd64. The new configuration reflects the latest packages as keyworded testing for amd64, excepting the kernel. I’ll probably go about upgrading my kernel very soon, but since LVM with pvmove works just fine, I have no strong pressure to do so. Besides, my box is still busy moving data hither and thither.

The CPU

I’ve overclocked the 2000Mhz processor just the tiniest bit — to 2050Mhz — in order to push the total bogomips to just over 4000 (real nerds like round numbers). I don’t want to push the machine too much, as I’d instead prefer for the processor to last a lifetime (okay, I’ll settle for five years).

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3200+
stepping : 2
cpu MHz : 2050.033
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm
bogomips : 4063.23
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

So that’s where it stands. I’m a bit upset about not being able to purchase the 1MB L2 cache model, but it was just too far outside my price range. Despite having the same L2 cache as Lina’s Pentium 4 (currently the processor in PowerBox) and just a 250Mhz clock speed increase, it seems to be approximately twice as fast. If I care enough (or am bored enough), I may do some proper benchmarking at some point.

The Memory

The Corsair ValueSelect RAM I bought performs well but not amazingly. It’s rated at 2.5 CAS and some users commented on review sites that they were able to run it just fine at 2. I had no such luck, though I didn’t look into it too deeply. Right now there’s two sticks at 512MB apiece (1GB total) running at 410Mhz (205Mhz DDR) in dual channel mode. Let’s just say I’m satisfied.

$ cat /proc/meminfo | head -n 1
MemTotal: 1027300 kB

The Motherboard

The motherboard is nothing short of excellent. The only thing I’d ask for above and beyond what the MSI K8N Neo4-F provides is IEEE1394 (FireWire). I can always buy a PCI card for that, though (or even PCI-Express if I really need excellent latency/bandwidth.

All of the onboard features appear to work out of the box with the Gentoo 2005.1 minimal amd64 LiveCD. I’m no kernel expert, but I was able to get the kernel working perfectly with everything I need in one shot. I have yet to play with ACPI and CPU frequency scaling (I really have no clue about this Cool 'n Quiet stuff), but I hope to get around to that eventually.

The Results

As for right now, things are working great, and I’m overjoyed with the products and service I got from both of the vendors I went with. I have posted excellent reviews for both of them in the appropriate places.

Finally, I have a stable server that actually works.

Alright hardware-accelerated-X guys & girls, you’ve got my attention yet again. And I thought XDirectFB was cool.

It’s got to be only a matter of time before we have something equivelant on Mac OS X. As really the first operating environment to provide hardware-accelerated rendering of windows and widgets, Mac OS X can’t be far behind. I’m praying that someone develops some sort of haxie to enable this sort of thing globally on OS X.