OnLive One Step Closer

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."

Comments

I'll believe it when I see it

[BoberFett]

Until round trips between the server and client are guaranteed to be under 50ms, the lag will feel unbearable. If someone is playing a racing game and has to deal with a second between the time they begin turning and the time they actually see it turn this service will be dead before it begins.

Latency sensitive people

[xororand]

I also strongly doubt that any kind of game on this platform can be enjoyed by people who are sensitive to input latency. For example my old high quality PVA TFT panel used an overdrive circuit to reduce ghosting. The overdrive logic in TFT panels usually buffers about 1 or 2 full frames to analyze and optimize the pixel voltages which leads to about 20-50ms input latency. I for one already notice it when I just work to the point where it annoys me when the desktop or terminal sessions somehow always feel sluggish, let alone fast 3D games.

I can't imagine that the complete round-trip time for sending my input over the internet, waiting for a frame to be rendered and encoded remotely, sent back over the internet, decoded and displayed locally would be less than 20ms and then you'd still have the latency of your display. It might be bearable with a very fast internet connection and a CRT display which has 0ms input latency.

Maybe others aren't that sensitive to latency and can enjoy at least slower games like turn-based strategy with this service. Good for them.

Re:Latency sensitive people

[Toonol]

Game engines have latency in them... OnLive runs those engines at faster than realtime, so when the packet from your controller gets to the engine 300ms later than it normally would the engine has plenty of time to do its thing.

That's nuts. They can't run the engine out in advance of your input... unless they're rewriting core functionality of the engines, adding prediction like online FPS have. And... they aren't doing that.

If you have a ping of 100ms, you will press a key; 100ms later the onlive server will know you started turning. It generates, renders, and COMPRESSES a frame; sends it back to you. 200-250ms have elapsed. It will be like playing on a machine getting 5-10 frames a second.

Is this a giant scam?

[syncrotic]

I still maintain that this simply can't work, and that it's an absolutely braindead money pit of an idea if it's not a total scam.

Idea: let's take the most latency sensitive, computationally demanding, and visually intensive thing you can do with a modern computer and try to apply the thin client model to it.

A single instance of the application in question will demand the full resources of the most powerful PC you can throw at it, but we'll just wave our hands and mutter something about virtualization to convince stupid investors that we have magic at our disposal. Because they are morons and because we put on a good show, they'll believe that you can somehow run many instances of a game on the equivalent of a single PC. We'll also be encoding 720p video in realtime at a quality / bandwidth ratio that no codec today can deliver; this will presumably happen on the same computing hardware that's already running multiple instances of cutting edge 3D games.

Finally, we'll throw in some shit about the iphone, because people can't stop fellating apple lately.

Anyone who believes this is technically feasible, much less economically viable, is fucking *retarded*.

Re:Is this a giant scam?

[tbradshaw]

You obviously didn't watch the video at all. While you're being an asshole about the idea, the guy presenting during the presentation covered all of your strawmen.

1) "fill instance of the most powerful PC you can throw at it" - Uh, no. When you move from workstation class hardware to server hardware, the "ceilings" change. But, for games like Crysis, they do, indeed, use a big GPU per instance.

2) "720p video in realtime that no codec today can deliver" - Too bad you didn't watch the video. Turns out, this is the same team that brought us QuickTime before video codecs were even discussed. He also describes exactly how they pulled it off, started with scrapping the stream-based design paradigm, using a feedback loop based design paradigm, and creating a new encoder that looks great in motion encoded and decoded in real time (as one of the weaknesses, you can't pause it or it looks like shit).

3) "Presumably happen on the same computing hardware..." - Actually, no. As the presenter describes, the codec taxed even the dual quad core xeons that it was developed on. Then they fabbed custom chips that do nothing but implement the encoding algorithm. It's entirely hardware accelerated encoding, two chips per user on custom boards.

I also thought the entire process sounded like a big stupid scam, but before I declared the mighty victory of common sense, talking out of my ass, I went ahead and watched the video.