21st Century Digital Boy

So notdefined and mh58 are building a tiny, cool PC to act as a streaming media client for their TV, using the PLEX client/server applications. I've been watching PLEX for awhile, and while their earlier incarnations seemed quite flawed in their usability, the modern ones seem to do well, coupled with the speed of modern hardware to decode complex media and output 1080p signals to a TV via HDMI. Now, they also have IOS/Android apps to both act as clients, or as remote controls for other clients. Suddenly we have convergence.

I'm taking a slightly different tactic: I'm not going to build a micro PC, I'm going to buy one of the new Mac minis which use very little power, and almost no power when sleeping. The form factor is perfect, and it has HDMI-out. In the past, people have hacked earlier minis to be media servers, but with varied success (they were underpowered, and they didn't have HDMI, so getting it to the TV was a pain, and they often couldn't decode a proper 1080p/24 file without stuttering).

Why not an Apple TV? They're great toys, but they're closed devices. They don't do 1080p, and they only do a limited subset of H264 decoding (luckily it's done in hardware). With the mini, I can read any file any mac can read, which includes the ubiquitous .MKV files the kids get off the interwebs, and with the new multi-core i5/i7 processors, and dedicated GPU, I'll always be able to send 1080p content to my TV.

So over the week-end, I started ripping my DVD collection. It's small by some standards, but it's not inconsequential. I have a mix of old, unrestored films, B&W films, foreign films, some modern digital transfers, and both old and new animation. Logically, this means I had to do some homework to figure out what settings were best for the source material. Finding proper encode settings however, was like pulling teeth — painful, messy, and occasionally, inaccurate ;-). I rip all my DVDs to the hard drive prior to transcoding to H264, then batch transcode overnight. Here are some insights:

• Ripping (transferring but not transcoding data from the DVD to the hard drive) is far slower than merely copying bit-for-bit. This is due to the bullshit copy protection where they purposely corrupt sectors in the DVD, making the read-head dance from track to track trying to follow the programme material. Nothing can speed this up, as the DVD drive is the bottleneck, and you can't have a read-head move much faster.
• Transcoding is resource intensive. You're CPU bound, and potentially memory/disk IO bound, but there are workarounds…
• Rip to one disk, transcode to another. All disks should be fast. Don't use anything USB, unless it's USB3 (even then, just don't). Use Firewire 800 (minimum), or SATA/eSATA, or in my case, Fibre Channel (FC, fuck yeah!). This will have a massive impact on how many frames per second you can transcode. Nothing sucks more than having to read from one area of the drive, and write to another area of the same drive.
• Use fast, 64bit apps. Transcoding is a lot of very scary maths. In 64bit mode, not only can you twiddle giant numbers without rounding/truncating (or being forced to use double cycles to perform the operation), you also get access to *way* more registers, which means more efficient use of the CPU (32bit mode uses the legacy register system from the old 8088 days which is crippling in a modern compute environment). If your transcoding apps aren't multicore aware, get new ones.
• If your primary target device is IOS-based, amp up the bits-per-second, as each IOS device seems to be able to understand different bits of the various H264 profiles, and they're not merely additive (ie, AppleTV2 isn't 'everything the iPhone4 can do, plus some'). Throwing more bits-per-frame will always give you a better picture. All those fancy features are ways to achieve higher quality at a lower bitrate. Give yourself a big bitrate, and you don't need to rely on the fancy bits that will make your file unreadable on your target device.
• Check your audio tracks! Sometimes the 0 track is not the main audio track. If you're not encoding all the audio tracks, double check that you're bringing in the correct one. Personally, I encode a number of audio tracks, including an AC3 passthrough of the original audio. For commentary tracks, and down-mixed main audio, I use AAC at 256kbit/sec.
• Do yourself a favour, and DO  NOT burn-in your subtitles. Just trust me on that one. 

For transcoding, I prefer using the latest Handbrake, as it uses the very fast x264 engine for encoding to either .m4v or .mkv H264 containers. I looked around to find a good optimal encoder setting as a jumping-off point, but most sites had old information which wasn't directly applicable to the latest version of the app. I did however, learn about some of the advanced options which did have a relevance. 

I settled on starting with the "AppleTV 2" preset for my non-animated DVD content, but that yielded an image that I found unacceptable in most of my test material. In most scenes, the entire screen seemed like it was underwater. The macroblocks would shimmer and shake, making it difficult to concentrate on the material. From this, I made some minor adjustments, and I am pretty happy with the results.

• First thing I did was raise the 'constant quality' slider from the default position of 20, to 18. This is actually a logarithmic slider where the smaller number indicates higher quality.
• I also ticked the "No DTC Decimation" box which helped in areas where there are large areas of a single colour (or subtle fade)
• Set the "Adaptive B-frames" to "Optimal" which gives a boost in efficiency to the Pyramidal B-Frames.
• For cel animation, I increased the number of reference frames and B-frames to 6, and amped the 'constant quality' slider to 16
• For B&W source material, I used a variant of my cel animation settings, but brought the B-frames back down to 3, and used the Greyscale filter in the Picture Settings sub-menu. This greatly reduced macroblock collapse which often happens in B&W and cel animation transcoding (large splotches of the same colour).

Now all I have to do is pop the resulting files onto the server, and ingest them into PLEX's database.