Print 31 comment(s) - last by MatthiasF.. on Apr 11 at 1:25 AM

OnLive allows modern video games to be played without a traditional home console or a powerful PC

OnLive, a company founded by internet entrepreneur Steve Perlman, demonstrated its new video game delivery service at this year’s Game Developer Conference 2009. OnLive is a new system that deviates from the traditional way in which video game content is delivered and played using consoles and PCs.

OnLive games are not played off of media disc or local hard drive installs, but are instead processed on OnLive servers and delivered via broadband to the player using a low cost "micro console" or a low end PC or Mac.

The “micro console” is a small, low-cost device that does not contain a GPU and acts only as a video decoding control hub. The device will have two USB inputs and support for four Bluetooth devices, it will output audio and video via optical and HDMI connections.

In theory mainstream games such as F.E.A.R. 2, Bioshock, Far Cry Warhead, and Prince of Persia will be playable without the need of a powerful video game console or computer. The heavy processing will occur on OnLive’s servers and streamed back to the game player.

According to Kotaku, OnLive uses patented video compression technology combined with a system designed to compensate for lag and packet loss. OnLive will deliver video at up to 720p resolution and 60 frames per second. The Kotaku article states for standard definition television quality, a broadband connection of at least 1.5 megabits per second is required. For HDTV resolution, a connection of at least 5 mbps is needed. The OnLive technology is claimed to have a ping of less than one millisecond for video feeds.

The main benefit of OnLive is the need to have a powerful system locally is eliminated. Local installation of games is not necessary and hard drive storage space is no longer an issue. The power of the local system dictating the type of games that can be played would become less of an issue.

According to Kotaku the Crysis Wars demo of OnLive worked well enough in a controlled environment. Major game companies such as EA, Ubisoft, Take-Two, and Eidos have signed on and partnered with OnLive. A subscription based system for the OnLive service is planned and the company is currently searching for beta testers via their company website.

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

Three main problems with this.
By Chris Peredun on 3/30/2009 10:20:21 AM , Rating: 5
1. Their claim of being able to process 720p60 and retain quality video in "1ms" is laughable. Even if you give them the 16ms limit for "real-time" compression, it still comes out awfully blocky. Games will look like YouTube videos.

2. Input lag is a major factor. Ping Google from your machine now. I'm on a fairly good connection, and I get 40ms. At 60fps, that's three frames of additional delay between input and processing. If you're having trouble visualizing how this would affect you, check out this handy Flash demo. Slider at the bottom changes the lag, and clicking causes two boxes to pop up with the stated differential.

3. The costs to have an array of computers capable of running these games and the associated bandwidth is staggering. While 1280x720 doesn't put huge demands on machines (you could probably manage with a 9600GT-spec video card and a Pentium Dual Core) you still need one of those pairs per player.

I'd love to be proven wrong but for now I shall remain skeptical, as this feels like Phantom 2009

RE: Three main problems with this.
By Alpha4 on 3/30/2009 10:36:17 AM , Rating: 3
I was in the process of less-eloquently phrasing these concerns when I saw your post, so I'm glad you beat me to it.

The only way I can see this service succeeding is if Phantom/On-Live can arrange to have all major Internet Service and Internet backbone providers designate their streaming packets as high-priority... And even then we'll experience unplayable latencies, unless On-Live miraculously invents a Quantum Data Bus through Quantum State Transfer or something.

I agree 100% with VooDooAddict's post. This is simply a patent-establishing effort by On-Live.

RE: Three main problems with this.
By tjr508 on 3/30/2009 11:19:22 AM , Rating: 2
With endless hours of 5mbps streaming, I don't see many ISPs being too excited about this.

RE: Three main problems with this.
By omnicronx on 3/30/2009 11:35:52 AM , Rating: 1
1. 720p compressed with an Mpeg4 codec is not impossible with a 5mbit connection. Not saying it is going to look like a BD movie, but it surely will not look like a blocky youtube video. On demand 720P mpeg2 video that you receive from your cable company rarely passes the 10Mbps mark. As for the speed of the video compression, they really have no released enough information to have any idea what they are actually doing, although I do agree it seems a bit far fetched, although this probably won't matter anyays.

2.This can all be compensated for. How do you think online games work now with people having different latencies and different machines powering their games. There is no reason the server cannot poll each client to figure out the delay it has to apply to each individual. They have been doing this in games since the late 90's.

3. I disagree, there is no real video output, thus it requires much less power. Ever tried the program streammygame? It works in very much the same way, it is just a local version. I can be doing various other things on my computer while streaming a game to a feable linux box across a network.

This could really be the next big thing, especially with the rise of small lower power PCs and laptops. I'm sure there will be many kinks to work out, but I don't think it is impossible.

RE: Three main problems with this.
By FITCamaro on 3/30/2009 1:05:08 PM , Rating: 4
With MMOs the game itself is designed for that input lag. They want to do this with games that are not designed for it.

RE: Three main problems with this.
By omnicronx on 3/30/2009 2:07:38 PM , Rating: 2
I'm not talking about MMO's, all online first person shooters have some kind of netcode to deal with different latencies of different users.

All games are subject to input lag, it is just much easier to deal with it when the client is actually rendering the game directly. The problem here lies in the fact that the data must be sent roundtrip before the client can perform any actions. i.e you press a button, send the data to the server, the server encodes the video with that button pressed realtime, and sends it back to you. This adds two times the trip of a normal client/server model, without taking into account the time it takes for video compression/decompression.

For comparison most gaming engines will have some kind of algorithm that allows the client to send actions to the server, and to start performing them a few MS before the server even gets it. If you ever wondered how when you walked around a corner and you got shot in the face so fast it seems like the enemy just came around the corner, you know what I am talking about.

Of course this is a major oversimplification, but I just wanted to show the difference in 'input lag' will not be the main problem, lowering the time to encode and decode the video will be a much harder job to accomplish

By Icelight on 4/1/2009 4:28:57 PM , Rating: 3
For comparison most gaming engines will have some kind of algorithm that allows the client to send actions to the server, and to start performing them a few MS before the server even gets it. If you ever wondered how when you walked around a corner and you got shot in the face so fast it seems like the enemy just came around the corner, you know what I am talking about.

I hate to break this to you, but single player game engines (or single player components of a game) do not have this...because there is no server that will do this, it's single player! Enjoy your input lag in single player games...

RE: Three main problems with this.
By Chris Peredun on 3/30/2009 2:29:08 PM , Rating: 2
1. Compressing 720p to a 5MBps stream is entirely doable, and it can look good. You can even compress 720p60 and have it still look good. What you can't do is run that in realtime while maintaining quality. Encoders are set up so that the longer they have to work on a scene, the better an end result they can make. A high-quality, CPU-hogging multi-pass encode will give far better quality than a low-overhead realtime compression.

2. Network lag can be compensated for much more easily than input lag. This is what people mention when they talk about "loose" or "floaty" controls in a game - while it might work for an MMO that's already buffering input and compensating, it will not play nicely with a twitch-reaction game like TF2 or L4D. Also, I don't imagine people taking nicely to the idea of "lag" in their single-player games.

3. Yes, the video output is being streamed, but it has to be rendered just like if the person was sitting at the machine. Instead of the final operation being "paste to display buffer" it's "paste to input pipe of the video compression engine" - which then needs its own overhead. They can probably throw AA and AF out the window though, as the blurring and macroblocking introduced by point #1 above will negate any benefits of those.

Again - I'd really love to be proven wrong on this. But so far I haven't seen anything concrete.

RE: Three main problems with this.
By omnicronx on 3/30/2009 3:07:19 PM , Rating: 2
I can't really disagree with your 2009 phantom comment, just the that this could be doable, as we still do not know the specifics.

Where I could see this being employed is in the form of an on demand service from say a cable company. Doing so would drastically open up the possibilities on how they would deal with the various issues you have presented.

RE: Three main problems with this.
By Targon on 4/2/2009 9:59:47 AM , Rating: 2
This would ONLY work if the games are designed for this sort of thing. That is the problem, most games are NOT designed with the network latency issues in mind. First person shooters are also just one type of game, and others just might not work well.

This sort of service might be good for those with $400 computer towers, but a Radeon 4870 will turn that $400 tower into an acceptable game machine which would not need the service. $180...hmmm, ok, I might be willing to pay $5 per month if they can provide the performance of that video card. If they can't do that, then why wouldn't I just buy a video card?

RE: Three main problems with this.
By kattanna on 3/30/2009 12:24:22 PM , Rating: 2
i've been getting good laughs at people proclaiming that finally they will be able to run crysis at full settings..

LOL yeah.. and it will be displaying at 720x480(standard def) within your browser window.. they seem to over look that fact since the VAST majority of people willnt be able to sustain a 5Mbps feed to get "HD" feeds.

By MatthiasF on 4/11/2009 1:25:39 AM , Rating: 2
1. It's possible to render directly from TMDS to a multi-resolution buffer that can be compressed and shuttled to end users in near real time ( Anyone who has used a remote access controller instead of software based remote access will attest to hardware-based video compression.

But with any differential signal, the size of the buffer and speed of the connection between determine the resolution that can be pushed through it.

2. I'm not sure how you came to three frames of delay. Since a ping is round-trip, each way would be (on average) 20ms in your example. That would allow for 50fps (1000 ms in a second, divided by 20 ms latency). That would be 10 lost frames if you're trying to push 60 fps.

Also, you're assuming the game interface is running in real-time. If it's buffered with a time offset, you can negate latency by sending larger proceeding chunks to fill in small gaps. Both sides can adjust what they send to the other depending on transmission differential, minimizing the user even noticing changes in network latency.

3. Imagine your computer can play a game at 1680x150@100 FPS. This is a pixel frame rate of 176.4 million pixels per second. Now imagine the scenario above, 1280x720@50 FPS, which is 46 million pixels per second. Roughly, that means your computer can handle nearly 4 720p renderings using the same processing power. Your own lil LAN party.

Add on efficiencies gained by using the lower resolution, textures shared in the same video memory on the server, content already loaded into RAM, all content residing on fast massive RAID systems, etc. etc., and you can see how the cloud computing concept can measure up.

Saw this
By FITCamaro on 3/30/09, Rating: 0
RE: Saw this
By Alpha4 on 3/30/2009 10:07:15 AM , Rating: 2
You might be thinking of Gametap, but that is completely different.

This service streams the final rendering, one frame at a time, through the internet. It doesn't stream game content, so the size of the original media is irrelevant.

RE: Saw this
By therealnickdanger on 3/30/2009 11:58:40 AM , Rating: 2
Yeah you're thinking of Gametap which is totally different. Here's how this service works:

1. The game is run and rendered on a server at a remote location.
2. The box sends your controller input to the server.
3. The box receives a video/audio feed of the action from the server to your TV.

It's actually very awesome - you don't need to worry about graphics cards or consoles or anything, just a monthly fee (like Netflix). However, latency and visual/aural quality will take a hit compared to playing a game on your PC or console. We'll know how bad/good it is once it is released.

RE: Saw this
By FITCamaro on 3/30/2009 1:02:33 PM , Rating: 4
Yeah I realize what it does (just worded it badly). And what I'm saying is that I don't see how they can possibly do this with no lag. I mean look at the process this follows:

1) you press a button in a game
2) the box/your PC sends that input to the server
3) that server routes it to a system (be it PC/360/PS3 whatever)
4) the console processes it and you have a visual output
5) that output has to be compressed
6) it gets sent back to you
7) that output has to be uncompressed
8) you finally see the output

Now with your own system, all that stuff happens in a few milliseconds at most. There's no way they can do all that in the same amount of time over the web and maintain the quality of gameplay. You're going to have input lag. You'll press the thumbstick to the left to move left, and a second later you'll actually do it.

RE: Saw this
By therealnickdanger on 3/30/2009 2:11:55 PM , Rating: 2
I don't see how they can possibly do this with no lag

Exactly. That's why it will NEVER work, unfortunately. Even at its best, let's assume you achieved a constant 25ms
"ping" with the server. That means 50ms overall. But lets create a realistic scenario:

You're running down a hallway and you spot an enemy. Well, by the time you see him, it's already been 25ms. Then you shoot at him, that's another 25ms. Then you get visual confirmation that you're hitting him or kill him - another 25ms. I mean, we haven't even factored in display latency or compression/decompression latency.

You could be looking at a quarter to half a second of delay for a typical user. I'd love a system like this if it could truly work "as advertised" but I don't think it will happen. :(

We'll see!

RE: Saw this
By therealnickdanger on 3/30/2009 2:14:17 PM , Rating: 2
I just imagined playing Ninja Gaiden on a system like this. You would die on Easy-mode almost 10 seconds into the game. LOL

RE: Saw this
By Alpha4 on 3/30/2009 6:54:21 PM , Rating: 2
I believe "ping" refers to the amount of time before a packet is sent and returned, so it includes round trip time. That being said your scenario still applies and the latency would be ghastly.

RE: Saw this
By therealnickdanger on 3/31/2009 9:49:40 AM , Rating: 2

RE: Saw this
By monomer on 3/31/2009 2:49:03 PM , Rating: 2
When this service was first announced, I had read somewhere that OnLive wasn't going to be providing the entire service, but would be licensing it out to other providers. I wish I could find the quote now.

One way I could see it work is that if the rendering was being done at say the ISP's server, and this service was an add-on charge to your broadband bill. I get pretty low pings to my ISP(<10ms), so the entire round-trip wouldn't be as bad as having to to go to some remote cloud server. It still wouldn't be the same as rendering at home, but this could mitigate a fair proportion of the lag.

I think we are all missing the point...
By VooDooAddict on 3/30/2009 10:23:46 AM , Rating: 5
I think we are all missing the point. I'd bet the true business plan here isn't to actually make $$ off the service. It's to develop some tech and patents so that 10-15 years from now when(/if) the internet is capable of handling this they can make $$ of the licensing.

I don't think the US internet infastructure is up to the task of getting what is essentially 1280x720 streaming video playing with zero buffer. Even with one of the 20-30mbit Comcast connections, Hulu and Netflix still buffer a second or two before playing. Noting that you have to wait around for ... but certainly not quick enough for a twitch response game.

By SilentSin on 3/30/2009 12:10:21 PM , Rating: 2
Just a question, but is this how those boxes you find at some hotels work? I've been to quite a few where you can find a PS1 controller or N64 and you pay $500 an hour to play it while you drink a $40 airplane bottle of Jack and eat $10 peanuts.

Sounds like a patent should already exist for this type of thing. That seems like it's about the best sort of setup to install this thing anyway, stick it in hotels or cruise ships. Put it anywhere on a WAN and this idea will faceplant as others have stated already.

By Uncle on 4/4/2009 9:31:40 PM , Rating: 2
I can agree, their is such a thing as patenting an idea. The very fact they editorialized on the net puts a date on the idea, second is sending a double registered letter to a lawyer and leaving it sealed until the day you need to verify that you came up with the idea first in court.

Another erosion
By TomCorelis on 3/30/2009 8:06:09 PM , Rating: 5
It's so nice to see everyone so happily cast off ownership of the things they pay for.

There are so many problems with a cloud computing model for end consumers. I've written about some of them...

Oh and the lag on OnLive is going to be killer. As was mentioned on Penny Arcade, anyone who's seriously worked IT knows we don't have the tech for cloud gaming yet... and, I hope, won't have it ever.

controlling the revenue stream
By mattclary on 3/30/2009 9:58:47 AM , Rating: 2
This is a way to get people to rent rather than own their games. This will be good for software companies, and probably suck for the customer.

By micha90210 on 3/30/2009 10:36:13 AM , Rating: 2
One Caveat that OnLive would do well. With a military UAV/UGV game, you could have a very capable pilot trainer sim. Having only the controls locally and the game(or UAV ) halfway around the world would match real life conditions. It would take one hell of a advanced game controller.

Halfway around the world is 20k kilometers. Light travels at 300k kilometers per second, which means the signal will take 66.6ms to reach the server and another 66.6ms to come back = 133.3ms lag.

It just doesn't make sense...
By riku0116 on 3/30/2009 7:02:57 PM , Rating: 2
Even from an economic point of view, who would pay 20-30 dollars per month (I'm assuming that's the very least it would cost) for a service that streams you 60fps of standard-definition input lag when a gaming rig capable of running most games locally at over 60fps on the highest resolutions and settings could be had for less than 500 bucks these days? (think e5200+hd4830)

In the long term, it just doesn't make sense.

By HostileEffect on 3/31/2009 11:49:58 AM , Rating: 2
I can see a service like this working for internet browsers and improving the graphical quality of time waster games. Isn't there a group trying to steam a fully interactive city over the internet, its run on a super computer and the frames are sent to your browser.

By alexbarbie on 3/31/09, Rating: -1
"Folks that want porn can buy an Android phone." -- Steve Jobs

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki