The thing is, OnLive does not work.
As for the VNC, it's pretty slow but cross-platform solution. If you only use windows then use RTP or w/e the protocol was (See ED's video)
If linux, there are plenty of solutions. One would be SSH, but I doubt Pandora has the extension for the X access. (As it only supports gles, which is dull.. We really need open drivers.)
Yah I know about OnLive not working. I just don't understand why something like VNC, which is open source and seems to perform a similar function to OnLive, is free to port and use but OnLive (or its missing cousin) is not. It seems like if you can make a VNC you should be able to make an open source OnLive. I understand why OnLive keeps their code a secret, I just don't get why VNC does not work like OnLive does. Or why it takes so much more bandwidth and processing power.
I think I can help with this issue actually... I saw a presentation on the way OnLive works from it's CEO, so this is second hand information but it basically boils down to how you transmit the data. The amount of data traveling from you video output to your monitor is more than you can reasonably push over the network uncompressed, so it needs to be compressed somehow to optimize performance over the wire. Most streaming sites, video tech, and remote desktop access software and frankly everything I'm aware of before onlive used a compression technique called Group of Pictures. This works similarly to the way early file compression worked. In file compression you can find, say, a string of 100 zeros and replace them with some shorthand like 100[0] so what once took 100 characters now takes 6. In video you wait for a series of screens to flip by, analyze the bits that remain static and don't bother sending those chunks duplicated over the wire. So an unchanging background with a single character on it in video you would only send the background portion once while the character may need to be sent many times as he changed positions etc. (Clearly this is oversimplified
)
What OnLive tries to do is approach video compression in a different way. Instead of relying on groups of pictures that have already needed rendering, analyzing them for similarities, and sending the compressed results of that analysis (part of why you have to buffer everything first) they created an process that takes advantage of the way the human eye tracks motion. In short, while we are perfectly capable of seeing still images and discerning between 1080p and 720i, if the image is moving you can render it with significantly less detail and people don't notice. So what OnLive tries to do is subdivide a single image into the bits that are still versus moving and achieve compression by degrading the quality of the bits in motion. This is supposed to allow them to show us remote executing images without needing to buffer, compare, compress, and send the images which takes up so much time that the controls no longer feel responsive. If I remember correctly they decided that any delay in response to a button push more than 80ms was perceptible and experience breaking. The challenge then was to enable sufficient compression via this new algorithm to keep the images on the screen reacting within that 80ms window. This is why they have distance from their servers issues, and network latency issues that cause the screens to go low def. It's also why there's a delay between action and seeing the results when you RDP/VNC into remote systems. Same thing if you stream video in an remote desktop session... you get stutters as it tries to Group of Images compress the screens.
Now someone COULD create software to do compression the same way onlive does it, but you'd still experience quality issues as your latency connecting to that machine increased. The main issue is that they just thought of it/implemented it (software first, on chip second) and no one has pulled the chips apart to reverse engineer the algorithm that I'm aware of. I bet if it's successful long term it's just a matter of time though.
For 99% of remote desktop access though no one needs that kind of response time :/
