@lindsay.at

I wish Brian and Tristan and the whole echonest crew the best of success. Beyond dropping the Analysis API on the public last autumn, they've finally come out to the public with a real corporate website and a hint of what they do.

The real treat is their this is my jam web application. It's audio mosaicing made popular and fun. Best of all, it's let me realise something I've dreamt of doing for years upon years:

Bill Withers' Ain't No Sunshine has been my personal earworm for about 30 years, back to when I first heard it on AM radio. I rediscovered it late in college, early grad school, and then around 2001, I discovered just how many covers were out there, via a long-forgotten file-sharing protocol. It's immensely satisfying to have a terse mix of fifteen versions of the song with a couple minutes' effort.

It would be nice to be able to return to the mix and tweak it a little, without creating another one, but then there's a rough perfection to it already. It's also worth noting that the RSS created on each page is also an iTunes-enabled podcast, if you want a way to get the MP3s onto your computer. My feed has already been duly added to my everywhere feed.

After seeing the appropriate portion of the Macworld Expo keynote presentation by Steve Jobs, I have some thoughts about the revamped AppleTV.

First off, I'm pretty happy about it. I'm very pleased that the "version 2" is just a software upgrade. It was pretty clear that the original hardware was over-specced for what it did at the beginning, so I bought early with a lot of confidence that the hardware would last. (Subsequent teardown reports that suggested tiny margins on the hardware increased that confidence.)

It's interesting to note that the UK prices haven't changed. At £199 and £269, Apple is treating the UK AppleTV as a niche product. If you know you want it, you've probably already gotten it. As soon as movies are available internationally, then I would expect the price to go down a bit. You gotta have the blades ready to go, if you want to sell cheaper razors...

Looking at the demos available online, it's unclear where the "source" menu has gone. We have a 40GB unit, and when Rosemary or I are feeling in an aimless mood, we'll mount our 500GB iTunes library and browse that for inspiration. I worry somewhat that streaming from arbitrary sources might be compromised in the new software.

The store integration is very impressive, and very inviting. It's what's needed to make rentals work: highly visual, presenting a multitude of choices, and accommodating to impulse buys (or rentals). It looks like a model that all others should follow.

However, the AppleTV now appears to be little more than a portal for the iTunes Store. The menu system puts an extraordinary amount of attention on the Store, and pushes one's own content to the bottom. It seems odd that streaming content over the internet is given such priority after the first version: Apple's view always seemed to be, "Don't trust the internet's quality of service, but you can stream over the LAN." LAN-based content, as far as I can tell, seems to be hidden.

I always viewed Podcasts as a back door for (free) content onto the AppleTV. They are the "other easy way" to get content pushed (automatically) into the living room. Before, entering arbitrary URLs into iTunes (perhaps via a clickable itpc: link) was about equivalent to subscription via Apple's iTunes Podcast directory. Now, via the AppleTV, the iTunes store solidifies its position as an orifice to podcasts. It looks inviting, instantly gratifying, and well done, but it makes Apple more of a gatekeeper to free content.

The fact that high definition finally makes its appearance is exciting to me. It's not how I originally imagined it would be, but everything I've read suggests that SVC scalable video encoding isn't ready for prime time yet. It may make an appearance, once hi-def moves to a purchase model/off the AppleTV exclusively.

There has been some speculation on why hi-def is AppleTV only. Some think it might be due to piracy concerns by the studios, but I think there are technology reasons as well. For 5.1 surround sound, there is no reliable, universal way for Mac or PC users to enjoy content encoded that way. High-Definition video cannot be played out on any of the iPhone/iPod family, either, so simply placing that content into iTunes creates a confusing situation ("this content is not compatible with your iPod") for those much-beloved users. In other words, hi-def is AppleTV-only because the technology isn't ready to accommodate the other devices in the ecosystem. I've outlined the ways it could happen, eventually, but for now, a closed, black box solution is sufficient for content that will not have a lifespan beyond thirty days.

I'm really eager to see the updated software myself, but I do worry that Apple may have made itself too much of a gatekeeper to content in the rush to give people the movie rentals they wanted.

So, when last I blogged about the ZFS RAID server, I may have ended on a down note, suggesting disappointment. I hope readers will understand that's not the case.

When I started this project, I sat down and examined what was most important to me in the server.

My requirements:
• Saturate an aggegated 2× GigE link for sustained reads and writes
• Do it cheaply

My strong desires:
• ZFS for its reliability, redundancy, flexibility, and ease of use
• Maximise the amount of usable space

ZFS wasn't a requirement. It couldn't be: it's a solution, and defining requirements in terms of pre-ordained solutions is, at best, compromised. Maximising IOPS wasn't a first priority, sustained write performance was. Still, I want to have decent random seek performance, because there will always be a case where performance falls to that level.

I ran some additional Bonnie-64 tests to see the difference between the SATA controllers and their PCI-X buses. There was a small (a couple percent) but consistent difference between the two controllers. I believe one ran at 133MHz, and the other ran at 100MHz (but, to be honest, I don't know what tools I would use to verify such a thing). So I moved a disk controller from the 100MHz bus to a PCI-X slot on the shared 133MHz bus, and ran the same tests as before.

The results are as follows:

I perceive a strong levelling-off of streaming write performance, even lower than with the previous test. The peak for three 4+1 RAID-Z groups is 387.5 MB/s, while the peak for five 2+1 groups is 354.5 MB/sec. The mirrored scenario's limits are even lower, at 258.5 MB/sec.

The continuous read performance is even more interesting. Now, it's clear that the two controllers are maxing out a single, contended PCI-X bus where they hadn't before. The read limit is at 520 MB/sec. That, to me, sounds very much like one half of the throughput of a 64-bit, 133MHz bus (1064 MB/s). (It's within 2.5% of half that figure.) One conclusion could be that ZFS performs two reads for every block requested from disk, whether it be RAID-Z or mirror.

Taking a step back, should we find significance in the fact that one-third of our PCI-X bus throughput is 354.67 MB/s, while the most we could squeeze out of the 2+1 RAID-Z configuration was 354.5? It would certainly square with what commenter "mrb" stated: for 2+1 RAID-Z sets, expect 50% higher throughput on reads than writes.

The random seek performance doesn't yet tell me much other than the theory of IOPS scaling linearly with the number of vdevs or mirror disks simply does not hold on my system. Frankly, I'm stumped at how it only increases logarithmically. Well, at least it increases monotonically.

Let's pit theory against practice. I originally posted a crude, back-of-the-envelope model of read/write/random ZFS performance for 14 or 15 disks in 2+1, 4+1 or 2× mirror configurations. What happens to our experimental results when I factor out the (estimated) base performance of a single drive/vdev set?

		Sequential I/O
config	Random Reads	Read	Write	Capacity
RAIDZ: 3×(4+1)	3y	12z	12z	6.0TB
RAIDZ: 5×(2+1)	5y	10z	10z	5.0TB
mirror: 7×2	14y	14z	7z	3.5TB

	Random Reads ×90/sec	Sequential I/O ×72MB/sec
config		Read	Write	Capacity
RAIDZ: 3×(4+1)	2.3y	7.2z	5.3z	6.0TB
RAIDZ: 5×(2+1)	3.3y	8.8z	5.2z	5.0TB
mirror: 7×2	3.8y	10.2z	4.8z	3.5TB

It's clear that ZFS is demanding enough that it can hit the limits of the PCI-X bus on a poorly thought-out system. I can sketch out those limits on my own system, in some cases. It's also true that I could have chosen another motherboard with 2 independent 133MHz PCI-X buses, or gone with a PCIe solution that would have eliminated any concerns about bus bandwidth. In theory, with this many disks, I could be seeing twice the performance in some situations. However, I should look at the numbers: 390MB/s far exceeds my ability to get data into or out of the machine via the network.

The machine does what it is supposed to, and surprisingly affordably, too. Any "disappointment" I have is purely theoretical.

As a postscript, I should make a call out to anyone who would like further data with the 133+100MHz controller configuration. The server is leaving the workshop and going into the rack now, but the system will be under test for a few weeks more. Contact me via the comments, the contact form on this site, or the zfs-discuss list if you have a particular scenario you'd like me to run.

This is the last time I'll indulge in this sort of iTunes-HD speculation until at least January 2008. I will freely admit that it's colored by wishful thinking, but here are some thoughts about Tuesday's upcoming press conference at the Regent Street that allow me to hope that Apple could possibly advance the state of the art in Hi-Def video delivery.

I'm not denying an iPhone announcement. That would be a fool's bet. I just think there could be something else cooking as well.

1) It's been quiet on the new television season front. While there are a few US shows whose seasons have already started, the big series seem to be starting from Sunday (23 September). Last year, many pre-paid, discounted season passes were trumpeted and pushed on the iTunes store. The distinct impression I get is that the store is waiting for something.

2) As I've pointed out before, if Apple wants to include high-definition televisual content on its store, it is best done at the start of the US TV season. Changing mid-season will confuse and frustrate users. The next opportunity will be September 2008.

3) The BBC has a lot of high-definition content that's just begging to be more widely distributed than it currently is. "Planet Earth" is consistently cited as a best-selling title in both HD-DVD and Blu-Ray formats. Selling titles like "Hotel Babylon," "Robin Hood," and "Torchwood," for example, might actually benefit from the one-at-a-time taster format of the iTunes store (rather than the outlay required for a whole season on disc).

4) Partnering with content producers like the BBC may well be a way for Apple to soldier forward with its ambitious plans: Hollywood and the major American TV broadcast networks have been digging their heels in response to Apple's increasing power as a digital content distributor.

To recap, the major components of the ZFS storage server were:

• PCI Case's IPC-C3E-BAR65-XP-SAS 3U chassis w/16 hot-swap SAS/SATA2 bays
• 2× AMD Opteron 275 processors (dual-core, 2.2GHz)
• Tyan S3892 (K8HM) motherboard.
• 8GB ECC memory
• 2× 80GB boot drives (connected to the motherboard)
• 2× Supermicro AOC-SAT2-MV8 SATA 8 port RAID controller
• 16× 500 Gb Seagate enterprise class SATA Hard drives

This configuration is intended to act as a streaming multimedia recorder/server, with the most demanding disk I/O workflow intended to be writing a stream of data coming in from two GigE links. Imagine what it might take to store uncompressed high-definition video. There are likely to be other demanding tasks, but this was the most extreme.

Tyan's S3892 suffers from some ambiguous documentation. The PDF specification sheet states in the text that there are two 133MHz PCI-X slots, and one 100MHz slot, whereas the block diagram says they all run at 133MHz. The manual says nothing about it. There was no answer from emailing Tyan support. Using the block diagram as my guide, I split the two Supermicro controllers amongst the two PCI busses, and decided to start testing the hardware configuration to be sure.

Basically, I wanted to test and compare the model I previously blogged about.

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.

Bonnie-64 was designed to turn up performance bottlenecks. That is precisely what I was looking for. Can I tell that one controller is on a bus that runs 75% the speed of the other? I could, in fact, but the overall combined performance was very decent. The tests did show limitations in my hardware, however.

I compared configurations from two to fifteen disks (I always want to have a hot spare running), with 2+1 RAIDZ vdevs, 4+1 RAIDZ vdevs, and (single) mirror vdevs. So each graph reflects fifteen runs of Bonnie-64:

• With the 2+1 RAID-Z: 3, 6, 9, 12, or 15 disks in the zpool,
• With the 4+1 RAID-Z: 5, 10, or 15 disks in a zpool, and
• With the mirror configuration: 2, 4, 6, 8, 10, 12, or 14 disks in the zpool.

All of the graphs measure the number of data disks (i.e., the total number of mirror disks, but only the number of non-parity disks for the RAID-Z configurations), or in the case of random seeks, the number of RAID/mirror sets. All of the tests were performed with 32GB test files: from the results, it's pretty clear we're exceeding any cache issues.

Block writes were always going to be the metric I was most sensitive to, because of the above-described workflow. You can see that there is a strong levelling-off of block write performance just below 390 MBytes/sec. The mirrored configurations increase their write speed at half the rate of the RAID-Z configurations, as we would expect from the slower writes indicated in the model. The "ideal" line is fairly arbitrary, as it's an extrapolation of performance from fairly few data points. It is, however, indicative of what the performance model might predict.

Sustained read performance is much less limited than with writes. The "ideal" line also has a 33% steeper slope than with the writes: it appears we consistently achieve four block reads in the same time as it take to do three block writes. Strangely, the 4+1 RAID-Z groups underperform by a fair bit (I can't comment as to the statistical significance, at the moment, but it seems fairly consistent). The 7×2 mirror configuration tops out at 735 MB/s on reads, which seems fairly decent.

I'll admit that the random seek performance figures baffle me a bit. Everything I've read so far suggested that random seek performance would scale linearly with the number of vdevs (or disks in the mirror). Instead, the numbers line up fairly well with a logarithmic graph. Am I running into lots of vibration? Am I hitting an unexpected bottleneck that's unrelated to data transfer over the bus?

This is a beast of a post already. I'll push this out to the world, and start writing up the next installment, wherein I note that one of the SATA controllers is, in fact, on a slower PCI-X bus, and what I do to fix it.

edit: All of this was on Solaris Express Community Edition, Nevada 70, with the ZFS boot patch applied.

I live in hope.

Apple's announcement yesterday was about music. I had hoped that it would fill in the picture for high-definition video delivery to the home. I still think the pre-holiday season is the ideal time to deliver this, for Apple.

So, because it's my nature, I'm continuing to speculate on Apple's hi-def delivery possibilities until it does happen. I think if it happens this year, it'll have to happen soon, like, by 18 or 19 September by the latest. Why? The major US networks' television season starts in earnest on Sunday 23 September, and that will be a well-established, rich stream for ready high-definition content. The movie releases will probably be a trickle, but seeing downloadable television in hi-def will get consumers used to seeing it on their big-screen, flat TVs, and demanding it in greater quantities.

Since I'm engaged in reckless speculation, I may as well add that I believe that that sort of deadline is what led to Apple's particular urgency in the negotiations with NBC, and the public spat that followed. I think the $4.99 price point that has been the focus of the dispute, and has since baffled commentators, was the price that NBC was pulling for with HD downloads. Why, if NBC is doubling the wholesale price, would the end-consumer's price go up by 150%? Only if Apple's costs were increased. I'm guessing they would triple from where they are.

I imagine that Apple was pulling for a slight wholesale premium for high-definition television downloads. Maybe they were pulling for a $2.99 price, more likely they were willing to go up to $3.99. NBC may well have said, "If you're charging double, we want to charge you twice the price." The bandwidth costs, however, would eat into Apple's margins, and they reached an impasse, made particularly painful because Heroes in hi-def would be the ideal flagship launch title. Apple's response was to pull NBC's new season launches, to eliminate confusion about standard-definition downloads, living in hope that the NBC-hi-def picture would resolve before year- (or season-) end. (If a program is upgraded to HD mid-season, what happens to the existing downloads? A solution is technically possible, but it will cost money, and create a logistical nightmare for billing of – and communications with – customers.)

I want to believe that Apple had planned HD for yesterday's event (and had ABC, CBS, FOX, and the CW lined up), but pulled it in hopes that two weeks' more negotiation would make the difference with NBC. For once, I think that Apple does not hold all the cards at the negotiating table. They scored an early win in public opinion, but NBC's move to Amazon's Unbox service was a clever counter, confusing people with regards to Apple's stated prices. Ultimately, these public moves won't count for much during negotiations.

Me, I really am hoping to see Heroes in hi-def, offered on the iTunes store. I would pay a reasonable price for the season. So long as Apple negotiates the right price for the bundled package, I don't care so much what the individual episodes cost.

This is a followup to the first in the series.

After an encouraging comment to my last OpenSolaris blog entry, I decided to do what was necessary to make a patched ZFS boot installer. I used the Netinstall script/procedure from Lori Alt. The name is a bit misleading, as I was able to run the install from a DVD, as I'm usually comfortable doing.

The actual install was much easier than expected, and – because of the pfinstall procedure – much more efficient than the usual rigamarole I go through. Creating the modified boot DVD was the hard part, and really, that was mostly in the logistics of moving DVD images back and forth. I would

• download the DVD segments to my desktop,
• assemble the pieces, (really, I have to complain about Sun's download policy: it really gets in the way when trying to do this kind of work.)
• upload to the Solaris box, (and try again with newly split files because of a 2GB limit),
• mount the ISO image,
• copy the image to a working directory,
• apply the patch, and include a draft install profile on disk,
• create a bootable ISO image, and
• move it (in pieces) from the server room to the MacBook Pro so I can actually burn it.

Google led me to Tom Haynes' blog, and the linked entry along with the followups that follow in sequence give enough magic sauce to get a bootable/installable ISO image. With the disk burned, installation was a snap. And a ZFS boot disk… simply works. (I do need to dig deeper into arranging a ZVOL or some such as a dump volume. At the moment, it's on one of the unused array disks.)

When I last saw the machine, I had started running Bonnie-64 on it, and looked good so far. I hope to have very comprehensive test results to post.

In my previous entry, I vowed to give more details about the hardware.

My requirements were to come up with high-density, high-throughput, easy-to-manage storage on a budget. This will be doing multimedia streaming all the way up to (potentially uncompressed) Hi-Def. It's not your typical mailserver, in other words. My interest in ZFS has been in its reliability, ease-of-administration, and conceptual simplicity: disks are dumb and all too prone to failure. If an all-software solution allows me not to worry about the disks and not put the workload onto another point of failure between the application and the hardware (read: RAID cards die, get old, and obsolete), then I'm all for it.

A local systems integrator (with whom my department has had a long relationship) provided the system, and collaborated a fair bit on the specifications (but he readily admits that Solaris is not his speciality).

We started with the chassis: Steve works fairly exclusively with PCICase, and recommended their 16× SATA drive chassis in a 3U rackmount. It's a bit anonymously black, but it certainly looks like it will do the job of high-density storage on a budget.

After going back and forth, we settled on a motherboard from Tyan. The S2892 seemed just the ticket, and got a thumbs-up from the ZFS list. Unfortunately, Steve couldn't find the board from any of his suppliers, because it's apparently been end-of-lifed. He suggested the S3892 (Tyan Thunder K8HM) in its place. Having seen some measure of support for the southbridge controllers on the HCL (thanks to Paul Richards) from a kissing-cousin relative of the new motherboard, I agreed.

Originally, Steve proposed a 3.0GHz dual-core Opteron. I wanted something cheaper with more cores (cos Solaris tends to handle that rather well), so we ended up agreeing on two dual-core AMD Opteron 275 (2.2GHz) processors.

Combine this with 8GB RAM, dual boot drives (internal to the case, connected to the motherboard), 2× Supermicro's AOC-SAT2-MV8 SATA 8 port RAID controller, 16× 500GB Seagate SATA hard drives, and we have a pretty serious 8 Terabyte system for under £5000. The question at this point is how serious. I'm waiting for benchmark results to tell me just that.

I, like Blackfriars, am holding on to my hope that next week's iPod announcement will offer the beginnings of Apple's high-definition strategy. Blackfriars asks, "High-definition video putting the special in next week's Apple Special Event?":

Speaking of the Internet bringing the end of TV as we know it, everyone seems to be expecting new music and iPod offerings at the Apple Special Event in Moscone Center on September 5. But what has gone more or less unnoticed is the fact that Akamai, Apple's long-time Internet content partner, has announced that it is adding high-definition video to its Internet distribution offerings.

A coincidence? Perhaps. But add the fact that Apple TV, a product whose revenue is being recognized as a 24-month subscription model like the iPhone, sports high-definition outputs, yet has no high-definition iTunes content yet, and you've got a high-definition shoe ready to drop sometime; the only question is when.

Well, I've been wondering the same thing. Back in April, I outlined that it's certainly technically feasible: There's a new extension to H.264 that allows an additional video stream to enhance the basic stream that's there. iPods and iPhones would only need to sync with the basic 640×360 pixel stream that the iTunes store already delivers. An AppleTV, Intel-based Mac, or G5 Mac would be able to read both video streams at once, combine them, and show 720p high definition.

I could once again be blinded by the possible and the (personally) desirable over "likely." Apple could well excite people enough with the new iPods. The movie studios may well be holding out for rentals (though Blackfriars has some thoughts on that, as well) before handing Apple the keys to the HD castle as well. The combination of the Beatles, new iPods, and Hi-Def may well be too much for such an event: Hi-Def may not materialise this year.

But I'm hoping.

(Via The Macalope.)

I took delivery of my project's RAID server yesterday. It's a heady bit of hardware, and I'm sure I'll blog about that part soon (once I know what does and doesn't work). The idea was to do some serious RAID (16 spindles), but using the end-to-end software approach from ZFS.

I was debating whether or not I would try to tackle the somewhat baroque instructions for the much more experimental ZFS boot support. I was pretty put off by the instructions, however, so I set them aside. Instead, I jumped in and decided to install using the more familiar UFS/slice method.

So I just got back from setting up one of what I'm sure will be the first of many attempts to get the server configuration just right. And the experience of setting up the fdisk and pdisk slices, with their permanent choice of size, and with the involved UFS mirroring procedure still ahead of me… Well, I think I will give ZFS boot installation a try.

(next in series)

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.