Steve Perlman, CEO of OnLive, recently gave a talk at Columbia University outlining his vision for the future of how you will play video games. I watched the 48 minute video and let me tell you, the man means business. There has been quite a bit of skepticism regarding the OnLive business model and how something as compute intensive as video games would be able to scale in a centralized cloud environment. When OnLive first burst onto the scene earlier this year the tech community was buzzing with all sorts of doom prognostications. For the most part there are those that would have you believe that doom would rain down upon Steve Perlman's head because of a few major considerations: video compression, network bandwidth, data center meltdown, Nintendo assassins, etc.
In a very well thought out piece over at eurogamer.net, Richard Leadbetter talks hard numbers regarding known compression limits in existing video codecs, specifically h264. Granted, Richard's post is from the early days immediately following OnLive's demo at GDC 2009. Crunchgear has been following this story as well and earlier published a writeup of this video. Something that struck me about that post is that the author goes out of his way to talk hardware price. For the record I think his numbers are way out of whack in regards to what OnLive would pay to power this gamers paradise. In point, Steve specifically mentions that the hardware will be leased (27m). That in combination with the performance gains of custom hardware will significantly skew the capex of this venture.
In the presentation recorded at Columbia (December 2009), Steve goes into quite a bit of detail regarding the design of his video codec, how it differs from everything else that is out there and even so far as to talk hardware. In particular asics. These people are so solid on their codec that they are minting their own silicon which will have major implications for the data center in regards to power, heat, cost and performance. Steve goes on to challenge Shannon's Law (~39m) by fudging what is actually compressed. According to Steve, existing codecs breakdown video such that every frame will look good when you pause it. The OnLive codec is optimized for video in motion when being viewed live by the end user and in addition has a second compression stream that powers playback and spectating. It's not my field so I won't claim to understand it all but there seems to be some serious engineering going on here.
Lets talk network issues of which there are many and all are considerable. I'll just pull from the tape and say that OnLive have spent considerable time and effort to overcome this issue. The first acknowledgement is physics. Data can't travel faster than the speed of light so if they want to hit their max latency of 80ms (~3m30s) they need to position their data centers at no more than 1000 miles from the end user so that the maximum transit time due to distance is no more than 21ms (~9m). Now what about strange network hops? They have a solution for that too and it's quite simple: partner with all the major network providers. By partnering with all the network providers their service is able to negotiate the best possible route to the end user. OnLive is so concerned with latency that they even came up with their own wireless protocol with sub-millisecond resolution for wireless input devices (~46m). They had been looking to use the standard xbox controllers but the wireless chitchat just added too much latency especially when utilized simultaneously by multiple players.
Below are some quick notes on the 48 minute video. What my notes won't convey is the almost fanatic resolve, total belief and mad scientist vibe from Steve Perlman. There's a lot to say for that kind of passion from a CEO. Shades of another Steve CEO come to mind... A quick look at the OnLive bio page and you will see that these people have the skills and the seed money to make this happen. When your CEO knows every detail - technical, business and operations - that Steve does you can't help but think that they actually might be able to pull this off and make it a reality.
~02m00s servers in virginia for east coast
~03m30s has to be within 1k miles <80ms latency (threshold of perception)
~04m50s no pirating; no used games
~05m15s beta testing, telemetry
~06m10s interactive video compression (he worked at apple)
~07m20s bit of background on how the codec works vs. traditional video codecs
~08m30s network issue consideration, jitter
~09m10s physics = speed of light = limited range.
~09m40s breakdown of latency slices by type. distance, compression, decompression, last mile, routes.
~10m20s routing optimisation; deals with all the providers so they can control their route; keep connecting for best route
~11m50s demo; "night and day" vs vnc
~12m40s ip multicast generated at the center, you can zoom in and watch people play. this is all live.
~14m20s 1k streams on ip multicast, put them in a tree to max to 100k ppl watching.
~17m00s update servers every 6mo; specialized chips w ray tracing
~18m00s instant replay on other devices - iphone
~20m00s play on 3g networks : 150ms latency w 3g tech, better w wifi
~23m30s 3d generated avatars
~27m00s lease servers. as long as revenue > payments youre in business.
~28m00s power considerations in the data center, not everything needs a gpu. world of goo, 2d, cpu only
~30m00s ecosystem costs. good amount of time on the cost breakdown for the games
~33m30s quesion on video codec alg. perceptual science, mathematics, jitter, engineering, practical refinements.
~37m00s deep dive into compression algorithm. two simultaneous compressions. one for you, one for spectators.
~39m30s shannon's law teardown.
~40m30s dual quad core xeon used to develop compression. they have their own asics. 10-20$ per chip.
~43m30s business side... sell for 60$? no. fixed monthly fee. games sold a la cart. episodic games, bought in stages. micro transactions.
~45m30s they will support motion and other non standard input mechanisms. up to 4 controlers on the micro console.
~46m50s new wireless protocol at microsecond latency because of multiple controler usage.