A HD VUDU Download: How Hefty Is The Payload?

Continued from ‘HD VUDU: Delay-Induced Doo-Doo‘…

Quick benchmarks enabled me to discard the second and third contenders; AT&T’s service was running fine, as was my network. Regarding candidates 1 and 4, check out the ‘current bandwidth usage’ report in the lower left quadrant of this snapshot:

When VUDU had earlier classified my service quality as ‘2 Mbps’, I assumed that this was an intentionally tiered simplification of reality, and that the box would pull the full 2.4 Mbps of WAN bandwidth potential if my router and companion QoS processor enabled it to do so. But based on the statistics above, which held steady for over a half hour, this doesn’t seem to be the case…when VUDU says it’s pulling 2 Mbps, it’s pulling exactly 2 Mbps.

I realize, as I type these words, the potentially apparent irony of my complaint. Wasn’t I just grumbling two days ago about VUDU’s over-enthusiastic bandwidth conquest? Well, yes, but the scenario’s quite different this time.

• The root of my issue back then was that the company employed P2P ‘by subterfuge, in an overly aggressive and unpredictable manner, and without providing any meaningful means (such as the upstream bandwidth throttle settings found in Bittorrent clients) by which VUDU’s consumers can tone down the service’s bandwidth grabs.’ Conversely, I’d argue that when a consumer presses ‘rent’ (or for that matter, ‘purchase’), it’s reasonable to expect that he or she should know (or will quickly learn) and accept that web browsing and other LAN- and WAN-tapping functions are going to subsequently slow down for a while, and
• Last time, I focused on unannounced, uncontrollable and unpredictable upstream bandwidth usage. This time, conversely, downstream data flow dominates.

What about the last two potential progressive-download throttles in my above list? Whereas The Darjeeling Limited has a 91 minute listed runtime in IMDB’s database, The Bourne Utimatum stretches to 115 minutes. But still…only 28% downloaded after a 1 hour and 40 minute delay? Let’s see if we can figure out the encoded film file size. Extrapolating the already-provided data, we can estimate that the download completed ~357 minutes (i.e 5 hours, 57 minutes) after I pressed ‘rent’…and indeed, judging from the absence of abundant LAN and DSL activity, it had finished by the time I woke up this morning.

At a 2 Mbps download speed, that means that the total file size is ~5.38 GBytes (please check my math, people!). And dividing that formidable number by the 115 minute film runtime results in an encoded bitrate of just over 6.2 Mbps…indeed much higher than my earlier 4.4 Mbps estimate for HD Apple TV material. Will this Apple-vs-VUDU contrast hold across other titles, or did VUDU intentionally encode the Bourne films at a higher bitrate than other material in its library, thereby creating ‘trophy’ content? And bitrate differences aside, we already know that Apple’s leveraging H.264 (aka MPEG-4 AVC, aka MPEG-4 JVT, aka MPEG-4 Part 10); what video codec is VUDU employing?

The entirety of my information resides in a brief ‘MPEG-4′ mention (which could mean an almost infinite variety of things!) in the reviewer’s guide. I suspect (and teardown analysis concurs) that VUDU is tapping into the same H.264 infrastructure as Apple, in order to leverage the industry’s high volume cost efficiencies driven by commoditization, but I can’t say for sure until VUDU tells me more (and right now the company isn’t talking). Let me know your theories in the comments, please.