Virtual gaming pc cloud how to#

So Google tried to reduce latency even further with WebRTC by adding a concept of Playout Delay. With an online game? 100 milliseconds is the difference between winning and losing. This means having 100 milliseconds or 200 milliseconds delay would be just fine. WebRTC’s main focus over the years has been online meetings. Having an online meeting with a potential customer.Playing a first shooter game (as old as I am, that means Doom or Quake for me).WebRTC is designed and built for lower latency, but in the sub-second latency, how would you sort the latency requirements of these 3 activities? It can be found in my article titled With media delivery, you can optimize for quality or latency.

On the technical side, this was made possible by Google relying on sender-side bandwidth estimation techniques using transport-cc. The built-in bandwidth estimator in WebRTC can’t handle this… but the one Google built for the Stadia servers can. 4K and cloud gaming being a new scenario, meant that bitrates that were needed weren’t 2mbps or even 4mbps but rather more in the range of 10-35mbps. Which meant the real issue, besides making sure the browser can actually decode 4K resolutions efficiently, was to conduct efficient bandwidth estimation.Īs an algorithm, bandwidth estimation is finely tuned and optimized for given scenarios. Luckily, for cloud gaming, the browser only needs to decode the video and not encode it. WebRTC is/was great for video conferencing resolutions. Google aimed for high end games, which meant higher resolutions and frame rates. Lets see what it meant to add the other three things: 4K resolution at 60 fps What they got virtually for “free” with WebRTC was its data channel – the means to send game controller signals quickly from the player to the gaming machine in the cloud. These were lowering the latency, dealing with a larger color space and aiming for 4K resolution at 60 fps. Things they haven’t really needed too much when the main thing for WebRTC at Google was Google Meet. To get cloud gaming right, Google had to do a few things with WebRTC. WebRTC, Cloud gaming and the challenges of real time What Stadia did though, was show that this is most definitely possible. Businesswise… well… it shut down a little over 3 years after its launch – so not so much.

Virtual gaming pc cloud how to#

Playing the game inside a browser (or an equivalent)Īnd likely quite a few other challenges as well (scaling this whole thing and figuring out how to obtain and keep so many GPUs for example).Remotely serving these games in real time.Running high end console games on cloud machines.Stadia wanted to solve quite a few technological challenges: This can work nicely even on iOS devices, where Apple is adamant about their part of the revenue sharing on anything that goes through the app store. I’ve added the WebRTC text on the diagram from Google – WebRTC was called upon so that the player could use a modern browser to play the game. This meant games could be as complex as they need be and get their compute power from cloud servers, while keeping the user’s device at the same spec no matter the game. The user gets a live video rendering of the game and sends back console signals. On the technical side, the intent was to run high end games on cloud machines that would render the game and then have someone play the game “remotely”. Google is far remote from gaming, game developers and gamers. But at least in hindsight, the business plan wasn’t really there.

Google Stadia started life as Project Stream inside Google. The rise and (predictable?) fall of Google Stadia

Beyond cloud gaming – virtual desktop, remote desktop and cloud rendering.

WebRTC, Cloud gaming and the challenges of real time.

The rise and (predictable?) fall of Google Stadia.