It's quite a bit more complicated than what you're thinking, they haven't simple adapted an existing codec, they're written an entirely new codec, and redefined the logical constraints, to deal strictly with the issue of lag/response time. Specifically, they've loosened constraints on errors and failures, and added what sounds like very robust error correction, and they've thrown out the standard GOP method of encoding.
Ugh. No, I am approaching the tech from an analytical point of view and not just swallowing Perlmen's marketing speak which is what this entire presentation is - a more informal version of his GDC 09 presentation. What amazes me is that in a room of engineering students, they completely swallow his explanation of the codec as being "perceptual stuff and a bunch of mathematics" - what he is actually saying does not bear up to any kind of scrutiny whatsoever and I can't believe the students didn't pick him up on any of it.
BTW the GOP method of encoding only introduces lag if you are storing frames from the "future". There's nothing to stop you retaining information from the past. You'll notice that Perlmen stayed well away from using the phrase "intra-frame" even though that is what he expects us to believe it is.
Anyways, what he says is the basically threw out all the restrictions on the codec with regard to looking good when in a still frame, this codec is only dsigned to look in motion, i.e. you will only ever see this feed once: as you're playing. It's specifically designed to tolerate and expect errors, and has a whole bunch of code built in to hide or correct errors on the fly, and an active feedback loop to the server itself.
Um... that would be his "perceptual stuff" and all codecs are the same. h264 in particular, funnily enough. The "feedback loop" stuff - well, I will refer you to Microsoft Smooth Streaming. Also, I should say that Gaikai does something very similar. It's all about switching the quality of the stream according to network conditions. That's what they saying on the showfloor at GDC away from the glitz of the presentation.
There's quite a lot of OnLive info floating about in certain circles which unfortunately I can't repeat but does clear up a lot of the smoke and mirrors.
they had custom chips fabbed, and their sole purpose is to run their codec, this lets them get the per user hardware cost down to something like $30/person (initially the costs was around $10000/person using existing hardware), and literally encode a frame in 1ms. Sounds pretty cool...also shows alot of faith in this codec, that they would go as far as to fab chips for it.
You see all you are really doing here and in most of your post is reciting what Perlman is saying and not questioning any part of it. He said it, so it must be true. A $30 encoder that encodes 720p60 in 1ms, outperforming the best of the broadcast encoders at $50,000 a pop? Doesn't any kind of alarm bell go off, at all? There really is no such thing as a free lunch when it comes to designing silicon.
OnLive is obviously real and it has some amazing features that Live/PSN will probably end up copying (specifically the video capture stuff and integration with mobile devices), but many of the claims simply don't stack up. But they are claims that need to be made in order to position it as a "replacement" to the traditional console/PC.
I would take a look at
the Gaikai demo, with all its onscreen stats, use of h264, and general feel of plausibility then look again at OnLive. Assuming a certain amount of "givens" (ie there really is no need to be 60fps), the nuts and bolts of what you are seeing behind the flashy interface is not all that different.
.