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.

"There's no chance that the iPhone is going to get any significant market share. No chance." -- Microsoft CEO Steve Ballmer

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