Streaming Assistance: VUDU's Cleverness

Continuing with today’s storage focus…as previously promised, I watched my first streamed standard-definition film through VUDU last night. My Kid Could Paint That was a compelling documentary although, as I quickly ascertained, it wasn’t an ideal selection from a video quality evaluation standpoint since it was seemingly shot with DV camcorders.

Nonetheless, as VUDU’s promotional materials promised, the movie started up as soon as I clicked on the ‘rent’ link (strictly speaking, within 10 seconds or so…close enough, in my estimation), and was hiccup-free throughout the entire 82 minute runtime. The contrast between my VUDU experience and my earlier standard-def progressive-download Apple TV experiment, over the same 2.5 Mbps DSL tether, was a real head-scratcher. How did VUDU obviate the 2-minute purchase-to-play delay that I’d previously encountered with Apple’s product and service?

My theories, keeping in mind that VUDU’s documentation explicitly indicated that the company was using ‘MPEG-4′ as its video codec, included the following brainstorms:

• VUDU was more aggressively compressing its content as compared to Apple, thereby enabling the stream to fit within my broadband bandwidth parameters in a no-buffer fashion.
• VUDU, like Sirius, was employing a proprietary derivative of H.264 or some other MPEG-4 codec profile, or
• VUDU’s initial stream was sub-standard definition and otherwise quality-degraded in nature (and subsequently up-res’d and otherwise quality-patched to the perceptual degree possible within the VUDU unit) to reduce the stream’s bitrate, such that the VUDU box could simultaneously play back the stream at real-time rates and construct a buffer of to-be-played future material. Once the buffer was full, the box sent a signal to the server, which switched to a higher bitrate (and higher inherent quality) stream.

I was in email dialogue with a VUDU engineer last night regarding my earlier mentioned initial setup glitch, and as an aside I asked for an explanation of VUDU’s ‘instant playback’ capabilities in more detail. Usually, when I pry like this, I get a ’sorry, proprietary, no comment’ response. However, I was happy to find my VUDU contact more forthcoming, and the explanation revealed to me that none of my above guesses was spot-on:

Thanks for asking. We can provide instant play back for the following 2 main reasons (patented):

• the beginning of every movie (head) is stored in our hard drive (same resolution, bit rate)
• the peer to peer networking model is better for scalability and has less problem with handling heavy download requests.

If the box is not always connecting to the network to download updates (movie database, head - the beginning of the movie) then the movie without the head might have delayed viewing (and we clearly tell the user why he/she gets delayed viewing).

I’ll discuss the P2P bit in more detail in a coming-soon dedicated post. For now, however, I’d like to focus on the first bullet. I’d wondered if the voluminous 250 GByte HDD in VUDU’s box (versus the comparatively svelte 80 and 160 GByte Apple TV options) served a more substantial purpose than just caching ‘previews and meta-data’, as VUDU’s documentation had already revealed to me. And in fact, per my contact’s revelation, it does.

By virtue of the system’s pervasive Internet connectivity, it’s constantly updating itself with the first few minutes’ worth of every piece of video content VUDU offers for rent and sale. While it simultaneously plays back this cached material, the VUDU box is simultaneously filling a streamed buffer. And, once the buffer’s full, it seamlessly switches over to the stream for the remainder of the presentation.

Way cool. More than six years ago (in the pre-blog days!), I suggested in a print editorial that systems engineers would soon begin using the burgeoning capacities of rotating storage devices in non-traditional, innovative ways. I daresay VUDU’s implementation handily qualifies. Do you agree?