What is the best and most reliable way to implement cloud gaming?
- Thread starter Flux
- Start date
- Status
I wouldn't assume you can do a better job than Onlive or Gaikai.
Fundamentally you need a low latency compressed video stream, and some way to mostly reliably transmit controller packets from the player.
As a provider all you can control is the latency once things are inside your network, the rest is up to the infrastructure. Most of the network latency is between the user and the backbone.
It's my understanding that they use high end boxes, reduce rendering settings and run the games at 120fps to minimize the latency of the game itself, because that they can control.
Better compression algorithms obviously help.
It seems to me it's one of those areas where a working solution isn't exactly rocket science, but the quality of the solution depends on a lot of little details that likely you only discover when you build a solution.
Fundamentally you need a low latency compressed video stream, and some way to mostly reliably transmit controller packets from the player.
As a provider all you can control is the latency once things are inside your network, the rest is up to the infrastructure. Most of the network latency is between the user and the backbone.
It's my understanding that they use high end boxes, reduce rendering settings and run the games at 120fps to minimize the latency of the game itself, because that they can control.
Better compression algorithms obviously help.
It seems to me it's one of those areas where a working solution isn't exactly rocket science, but the quality of the solution depends on a lot of little details that likely you only discover when you build a solution.
Is there a chance you could implement the technology that the Wii U pad is employing, or do you think it is already used or too heavily patented? I read in Iwata asks that they stream blocks of 16x16 pixels immediately and display them immediately, and do not wait for frames to be complete before sending.
I can't see how that's going to work in a high-latency, low-reliability scenario that is the internet (in comparison to the link between WiiU and pad). I'd guess you get a garbled mess more often than not.
As a whole, I agree with ERP.
I'm really impressed that Onlive and Gaikai work as good as they do.
Uncompressed data rates
You'd need
for 1080P@60Hz1080x1920x3x60 bytes/second 373MB/s or ~ 3Gbit connection
for 720P@30Hz 720x1280x3x30 bytes/second 83MB/s or 0.7Gbit connection
Both are totally impractical
If they are sending blocks as they are generated I'd imagine WiiU uses some sort of motion JPEG variant where the entropy encoder uses a fixed dictionary, but I'm guessing. It also doesn't need to get anywhere near the compression ratio of something being transmitted over an internet connection.
Compression/decompression certainly adds to the delay, but it's probably not a big part of the total latency. I know that one of either Gaikai or Onlive started with their own compressor, but both ended up using modified versions of existing technology because it did a better job.
The big issue is the way the internet works, it's really not designed to play games on, low latency wasn't a big design goal. The backbone itself has scaled enormously, and it's very fast, but the connections from house to the backbone are still heinous.
Try pinging a website, then traceroute it, note that almost all of the delay is between you and your ISP.
You'd need
for 1080P@60Hz1080x1920x3x60 bytes/second 373MB/s or ~ 3Gbit connection
for 720P@30Hz 720x1280x3x30 bytes/second 83MB/s or 0.7Gbit connection
Both are totally impractical
If they are sending blocks as they are generated I'd imagine WiiU uses some sort of motion JPEG variant where the entropy encoder uses a fixed dictionary, but I'm guessing. It also doesn't need to get anywhere near the compression ratio of something being transmitted over an internet connection.
Compression/decompression certainly adds to the delay, but it's probably not a big part of the total latency. I know that one of either Gaikai or Onlive started with their own compressor, but both ended up using modified versions of existing technology because it did a better job.
The big issue is the way the internet works, it's really not designed to play games on, low latency wasn't a big design goal. The backbone itself has scaled enormously, and it's very fast, but the connections from house to the backbone are still heinous.
Try pinging a website, then traceroute it, note that almost all of the delay is between you and your ISP.
raw(with rle) 1260x1080i x 24Hz(with a 24bbp image) = 49MBps
http://web.forret.com/tools/video_f...t=1080&fps=24&interlace=on&space=raw&depth=24
@erp I said "someone cleverer than me" 
@alpha rle is lossless although why did he pick 1260 a resolution that no one else has mentioned as a comparison ?
also on the link he posted I cant find raw(with rle)
ps: the link also gives data per hour yay @1920 I could have 2 hours gaming per year with my Internet cap
@alpha rle is lossless although why did he pick 1260 a resolution that no one else has mentioned as a comparison ?
also on the link he posted I cant find raw(with rle)
ps: the link also gives data per hour yay @1920 I could have 2 hours gaming per year with my Internet cap
I wasn't suggesting that rle was lossy compression, only that 1280 would have lower quality than 1920 (and that 24fps isn't very good). 1080P@60fps using RLE would require 186MB/s. Still way too high. Even 49MB/s is too high.
Blazkowicz
Legend
Streaming blocks is the way most protocols work : VNC, RDP, maybe something else, whatever Onlive is using for sure.
Commercially or freely available are VirtualGL and microsoft RemoteFX.
I'd say the ideal "cloud gaming" would be placed in your own home
, or in communal housing, appartment complex.Something like Steam or app stores already deals with program and assets data. Let's base your home server on RemoteFX, then you can play from other devices, at least desktop and laptops. You need Windows Server 2012 ($882), maybe a Quadro K5000? ($2249), a remote-access Client Access License per gamer (over $100), and a hardware encoder card is preferable ($unknown, please contact us)
A real "cloud" would have you manage a real server farm, with web front-ends, load balancing, administration of user accounts etc. This gets boring and maybe gamers would defame you and sue you if you lost their savegames
.You also have to operate a Windows cloud, unless Steam on Linux works and takes off and has a good enough subset of games.
If you wanted something easy technically you would just drop users in a Windows desktop, or a Linux desktop.
In fact it would be nice already, and a lower hanging fruit, if you could just stream a XFCE desktop to your users. At home they would only need a thin client, ISP set top box, a "connected TV" or a piece of crap computer (pentium III 500, cheap tablet etc.), or a good one.
@erp I said "someone cleverer than me"
@alpha rle is lossless although why did he pick 1260 a resolution that no one else has mentioned as a comparison ?
also on the link he posted I cant find raw(with rle)
ps: the link also gives data per hour yay @1920 I could have 2 hours gaming per year with my Internet cap
The lan connection doesn't go through a isp. Its a local high bandwidth lan connection.
Streaming blocks is the way most protocols work : VNC, RDP, maybe something else, whatever Onlive is using for sure.
I have to look into that. The lower the latency and input lag the better
Commercially or freely available are VirtualGL and microsoft RemoteFX.
I'd say the ideal "cloud gaming" would be placed in your own home
Or in my case 10-12 miles away on a local server.
Something like Steam or app stores already deals with program and assets data. Let's base your home server on RemoteFX, then you can play from other devices, at least desktop and laptops. You need Windows Server 2012 ($882), maybe a Quadro K5000? ($2249), a remote-access Client Access License per gamer (over $100), and a hardware encoder card is preferable ($unknown, please contact us)
Cost is not an issue. Usability is. As long as there isn't high fps lag or random frame rate hiccups,hacks and crashes its ok. Saves can be logged to separate network that is managed by a separate contractor. The "gaming network" can be managed by a contractor that specializes in that.
A real "cloud" would have you manage a real server farm, with web front-ends, load balancing, administration of user accounts etc. This gets boring and maybe gamers would defame you and sue you if you lost their savegames
You also have to operate a Windows cloud, unless Steam on Linux works and takes off and has a good enough subset of games.
Not really a problem because the gaming network is well managed by professional staff and I am shielded civilly by a EULA that the user agrees to that waives thier right to sue me,my company, or any of my contractors from civil sues stemming from service interruptions and lost saved games and other irregular unfortunate inconveniences
If you wanted something easy technically you would just drop users in a Windows desktop, or a Linux desktop.
Why? A high end Windows based PC or Unix-like/Linux Box costs a lot of money even in 2012-2013. Maybe a thin client settop box or HD relay hub
In fact it would be nice already, and a lower hanging fruit, if you could just stream a XFCE desktop to your users. At home they would only need a thin client, ISP set top box, a "connected TV" or a piece of crap computer (pentium III 500, cheap tablet etc.), or a good one.
I agree somewhat. I was thinking of a touchpanel-gamepad(similar to what WiiU has implemented on its controller but does not have a video stream displayed on the controller's LCD)and a ARM based HD hub/set-top box. Cheaper than a PC and more interactive than a boring stale gamepad/controller or mouse and keyboard approach.Touch based gaming is easier to get into by Janet/Joseph Normal than a 15 button controller or a 104 key keyboard
As you can see I have thought this through.
Last edited by a moderator:
So you've gone with spending billions on infrastructure. Excellent choice.
- Status