OnLive One Step Closer 175
hysma writes "It looks like OnLive, the remote gaming system that streams HD video over the Internet, is one step closer to becoming reality, according to an article on DSL Reports in response to a lengthy video presentation by founder & CEO Steve Perlman at Columbia University. Perlman demonstrated the UI, spectating, using the service on an iPhone, and other features."
Re:I'll believe it when I see it (Score:3, Interesting)
Having used the beta they are giving out right now on a random computer outside of their controlled settings I have to say that their technology works. Don't know what form of magic is involved but it is playable and actually really fun. I am all for the gaming experience being opened up to people without having to keep a bleeding edge gaming rig going.
Re:Games? (Score:4, Interesting)
Yeah remote desktops are the wet dream for outsourcing where I work. Imagine a system where the evil (cheap) foreigners see a video of the actual code so they can't take the revision history home on an SD card and sell it in the flea market for one tenth the real value!
Re:Latency sensitive people (Score:4, Interesting)
Assume 60 fps, synced with 60Hz monitor. That's 16.7ms per frame, and usually means a target budget of 16.7ms per iteration in the game loop - and input is probably processed exactly once in the game loop. Consider also that many decent displays already lag by a frame or two. So in a local hardware situation, you already have a built-in lag somewhere in the region of 30ms or so, pretending there isn't any lag in the actual hardware path between devices and what the OS surfaces to apps.
Now, given the above assumptions, but factoring in your posited reactive input model (i.e. no delay from game loop), you think that's good enough? The way I see it, it can only be good enough if the round trip averages to less than 16ms or so; and even then, it's not great. I've long noticed the lag in games since moving from CRT to LCD, and I can even see the lag between moving my mouse and the pointer moving across the screen - it's small but perceptible, and is either caused by the mouse / usb / driver path or by the LCD delay.
But I can't realistically see a 16ms or so round-trip being achievable outside heavily populated areas and without lots of expensive hardware very close to local loops. As it is, Google.com is 29ms away from my machine, and it's still slow to download the front page's HTML content - (yes, I know, TCP connection, several round trips, etc.) - on the order of 200ms or so.
It seems to me that round trips on the order of 50 to 100+ms are more likely, and delays of that nature are highly, highly noticeable in twitch FPSes - especially when it comes to things like changing the view direction. Pretty much all multiplayer FPSes don't wait for a server round-trip for changing the view direction. In that situation twitch FPSes will suck.
Other kinds of games may work better.
Re: video as anti-copy protection (Score:3, Interesting)
If ofuscated text is easily readable (anti-captcha spam bots), text with not distortion at all will be perfectly readable, so if you send video, the other side will save that video (either with hardware or software) and use OCR to get back the text.
It still wouldn't work well for rock band (Score:4, Interesting)
A game like rock band could 'tune it in'. [it=500ms lag]
I really don't think it could.
Here's the reason: suppose I'm to go red-green-blue-yellow-orange-yellow-blue-green-red really fast (say, at the end of the TTFAF intro), and it's one big hammer-on-pull-off sequence which can't realistically be strummed (or the rules of the game have changed so I have to HOPO).
I miss the first green.
I only get to know that I missed the first green 500ms later. I have already HOPO'ed the rest of the sequence. There's no way I can go back in time 450ms and strum the blue I HOPO'ed, undoing the not-playing-correctly.
It's not just that you have to compensate for lag between inputs and outputs. You also have to make the lag inside a feedback loop very small. A minimal lag of 500ms is too much for rock band. ... Even if the audio and video is perfectly synchronous, and the game compensates for the output lag by virtually moving your inputs back in time. The game can never move the reaction to the output, which happens in your brain, back in time to before the output.
Play music? Can't even *talk* (Score:2, Interesting)
I remember reading in the Time/Life book on the brain that adding an appreciable delay to the auditory feedback you get makes it very difficult even to talk properly. But I'm sure that's old research.
There doesn't seem to be that much on it on the net (or maybe I'm not searching properly). The WP article on Delayed Auditory Feedback [wikipedia.org] has a link to a paper with similar work but it is also from 1979.
Compression? (Score:4, Interesting)
I think the most interesting part was the (lack of) answer about how the compression works.
They claim 80ms round-trip latency from button push to image display. Running a game on a server and screen-scraping in ~20ms is fairly easy. With proper datacenter placement and peering agreements ~50ms round-trip ping times are reasonable (if somewhat optimistic). The issue is how do you compress the 720p image and send it back in 10ms with reasonable bandwidth.
They're claiming 1ms compression, 8ms decompression (125hz), and 5mbit 720p streams. The compression is using a custom ASIC, so that's completely believable. Decompressing at 120hz on any generic hardware (they specifically said no GPU help) means it has to be an extremely simple protocol. The biggest question is how do you reach "HD-quality" at only 5mbit when you are not doing group-of-pictures compression (keyframes and diffs from the keyframe). Mind you that a standard DVD is 10mbit, so they're claiming higher resolution with half the bitrate and no keyframing. Obviously H264 gets better quality/bit than DVDs, but it does so by using even more complex keyframing and diffs and is far too CPU intensive for their target platforms (it's hard to watch 30fps H264 trailers on many machines, let alone a 60fps stream). The only hint he gave was some mumbling about visual perception, and the statement that their compression only looks good in motion (if you paused the stream it would look terrible).
Any ideas as to how the compression works?
Re:Play music? Can't even *talk* (Score:4, Interesting)
Re:It still wouldn't work well for rock band (Score:3, Interesting)
I'd imagine he gets it from reality. This service not only has bandwidth requirements but serious latency requirements. We're talking considerably higher than your average hardcore counterstrike player's latency requirements. Ala 60ms pings will be required and unless onlive plans to install itself in every single state, there's no way they'll make that kind of bandwidth.
See, it's not like streaming an application, where bandwidth isn't an issue (nor resolution), and it's not like streaming video, where latency isn't an issue. You literally would need to be on a 100mb/s lan equivalent to get this to reasonably work without bandwidth and latency issues.
It just highlights that our infrastructure simply isn't there at the moment for gaming. Saying they can make 80ms within 1000 miles is a flat out lie. Someone playing in X state with the fastest server 1000 miles away is going to get at least a minimum 200ms ping.