@lindsay.at

When Apple's iTunes Music Store introduced video at 320×240 resolution back in October 2005, it raised a number of questions: how would it scale up? How could they manage movies at that paltry resolution? The iPod's video hardware is so limited, how could it even scale up to 640×480? All of the anxiety about complex solutions were laid to rest after Apple introduced the movies and a firmware upgrade that got a lot more performance out of existing hardware. I argue that similar things will happen in the transition to High-Def video for the Apple TV.

In answer to the above questions, a lot of theories were thrown around in the buildup to the much-rumoured and much-anticipated introduction of movies to the iTunes Store. Theories included having to deliver video at two different sizes and/or bitrates at once, or supporting preferences favouring mobile or high quality. All of them added unnecessary complexity to the simplicity of the iTunes store experience, and felt like a "kludge."

Apple's solution was simple: all videos would be delivered at a high-quality 640×480 maximum resolution, encoded with the H.264 video codec. The firmware on the fifth generation iPod was updated, and impressively so (from 900 macroblocks in MPEG-4 to 1200 with H.264 encoding), so no dual delivery formats were needed. Simplicity is maintained.

With the introduction of the Apple TV, and the accompanying hand-wringing about the relatively poor quality of 640×360 pixel movies shown on HDTVs, attention is turning to how Apple plans to deliver High Definition content to the Apple TV. I don't think the current iPods can be made to understand a high definition stream. While some may imagine a multiple format delivery scenario as predicted before the introduction of movies, I think Apple has another potential trick up its sleeve.

The technology is an extension to H.264, Scalable Video Coding (SVC), and it was scheduled to reach the Final Draft Amendment stage last week. Normally¹, that stage means that the standard is all but finalised; nothing but editorial changes are allowed. An aggressive company often can feel confident in releasing a product based on it if, say, they controlled the whole ecosystem around the product....

The idea around SVC is that you have a normal H.264 base layer, and you can add enhancement layers on top of it, whether they be spatial, temporal, or SNR enhancements. That means that you can improve the resolution, frame rate, and/or picture quality by adding additional streams to the base layer. Consider that the 640×360 standard 16:9 videos have half the pixels in each dimension from 720p videos with 1280×720. This is perhaps the most basic application of spatial scalability, but it's also very relevant. I find it very easy to imagine an additional "track" in QuickTime that fills in three additional pixels out of every four. If a computer (say, my G4 PowerBook) is incapable of handling the full high-def combined stream, it can conveniently fall back to the base layer.

So, in the context of the iTunes ecosystem, these multiple streams and the increased file size need not be delivered to the iPod: with iTunes as the designated hub, the enhancement stream could quite feasibly be stripped when syncing with the iPod. One download, both standard and high definition are there for the appropriate device.

The only thing I'm not sure of is how the audio scenario is going to play out. Encoding and delivering the AC3 (Dolby Digital) stream (as an alternative soundtrack) that most home theatres expect seems very inefficient. AC3 and AAC are kissing cousins, so one could hypothesize a bitstream-to-bitstream transcoding from 5.1 AAC to 5.1 Dolby digital to pump through the optical out, but it also seems unnecessarily computationally expensive.

So the how of High Def seems to have a fair shape. It's the "when" that isn't yet clear. In the punditry vacuum where product development is instant and QA is not a factor, it's feasible to push out updates right away. Strategically, it seems like "as soon as possible" is the answer, as well: a lot of people feel that the HD-DVD/Blu-Ray format wars aren't close to a resolution, and there's a window of opportunity for HD video downloads to become the preferred delivery medium.

On the other hand, Apple will want to do it right the first time. It's a radical enough change to necessitate a new version (perhaps version 8.0) of QuickTime, and a new version of iTunes as well. Would it accompany an announcement of movie downloads in Europe? Would it accompany the "true" widescreen Video iPod? Would it wait for the end-of-year Christmas cycle, when the Apple TV suddenly becomes the must-have accessory that is even more important than the iPod?

I don't know, but I'm keen to find out. I hope for "soon," but I suspect it'll closer to the end of the year.

[disclaimer: This blog entry is merely informed speculation. Although I have some old ties to MPEG, none of this is gleaned from privileged information. The only research I did of this was on public sites. If you follow this blog and past predictions I have made about Apple's products, you will already know not to lend me too much credence.]

[1] My experience with MPEG standards can attest to the fact that this isn't always true: I'll only say that things got complicated in the final stage of standardisation of the MPEG-7 Systems standard, and I personally pissed off a lot of people during one late Friday night's plenary.

I've been spending a fair bit of the last week puzzling through the various postings on ZFS performance. While Richard Elling's blog posts were informative, they didn't really tell me much about the workflow that interested me most: high-throughput multimedia streaming. I eventually took the question to the ZFS-discuss list, and got a lot of knowledgeable feedback. The essence of what I learned about various ZFS configurations, for my purposes (once I understood the superficial size/reliability/performance tradeoffs), gets boiled down to one choice:

Which is more important to your ZFS workflow:
random access or write performance?

I suppose this is old hat to people who are very familiar with RAID systems and/or ZFS, but it took some digging for me to find out. I'll set it out in words, in contrast with the pretty but dizzying graphs at relling's site. These guidelines obviously set aside any other bottlenecks, but as was consistently pointed out, media speed is usually the bounding factor with performance.

For mirrored configurations:

• Small, random reads scale linearly with the number of disks; writes scale linearly with the number of mirror sets.
• Sequential read throughput scales linearly with the number of disks; write throughput scales linearly with the number of mirror sets.

For parity (RAID-Z, RAID-Z2) configurations:

• Small, random I/O reads and writes scale linearly with the number of RAID sets.
• Sequential read and write throughput scales linearly with the number of data (non-parity) disks.

In other words, mirrors suffer on writes, collapsing to the number of mirrors, essentially. RAID-Z groups suffer most with random I/O, collapsing to the number of RAID groups, performance-wise, in those situations. A hypothetical table with two different configurations of 12 disks (four 3-way mirror sets vs. two RAID-Z2 sets) helps show the strong contrast:

where y is the number of random, short IOPS and z is the sustained media throughput on the drives

My case is fairly clear: I want to both read and write multimedia streams fairly equally, so I favour RAID-Z groups. I don't need the same sort of long data life that others do, so I set RAID-Z2 aside for now.

In my particular case, I have 16 500GB SATAII drives to work with for the RAID. I am committed to one hot spare, so I'm down to 15 drives. Once I get my server, I need to know how much—and when—performance degrades when excessive numbers of streams are added and/or Random I/O requests are added to the mix.

For a long time, I had assumed I would use three sets of five-drive RAID sets. Looking at three-drive sets, I have to consider whether a ~17% drop in peak streaming performance is worth a 67% improvement in baseline small, random I/O (essentially the worst-case scenario).

How do I arrive at that? Five 2+1 RAIDZ groups have 10 data disks compared to the 12 in three 4+1 RAIDZ groups. If I go from 4+1 to 2+1 groups, I lose 2 disks worth of data storage and the equivalent amount of max streaming capacity, but gain two more RAIDZ groups for working on the seeking for random I/O. Actually, another table really makes the picture quite clear. I throw in a set of mirrored drives as further food for thought.

If you've stumbled upon my Twitter feed, then you probably already know that the arrival and installation of my much-anticipated Apple TV was less than trivially easy. Our old television wanted nothing to do with the component output from the device (sound, no picture), so plans to obtain a new HDTV were moved up.

We ended up going to Costco for a 32-inch Samsung LCD, which has been a real pleasure so far. Once the AppleTV was hooked up, however, a new problem emerged. The network really was unkind to the AppleTV, and frequently dropped the connection between it and iTunes. No synchronisation was possible, and both iTunes and the AppleTV frequently got confused.

After some examination of the Apple discussion boards, it quickly became clear that the problem was my old Linksys wireless router. It limps along enough to provide ADSL connectivity and wireless access at home, but the ethernet ports on it are fried, and both ADSL and wireless have their bad days. The solution (reached after far too many trips between the ground floor and the attic) was to pull out an unused Airport Express, use the Mac mini as a bridge from the wireless connection to the router to its ethernet port, and set up the Airport Express as another wireless network to which the AppleTV connects. Ahem. So, put another way:
AppleTV --wlan-> Airport Express --e'net-> Mac mini --wlan-> Linksys --adsl-> Internet

I hope this is just a temporary measure, but it seems to have solved the problem for now. I now have a working AppleTV.