These numbers dont add up. If the prototype codec essentially was just a series of JPEGs, i dont see where the bandwidth number of 60-80KB/s is coming from because it doesnt make sense. Each frame JPG would then have a size of 1-1.5Kilobyte considering a Framerate of 60.
OnLive and Gaikai worked quite good for what they were, but they had much higher bandwidth requirements and still didnt feature really high res.
I am probably misremembering, the comment above prompted me to try and work out what the rate could have been, it is likely that it is much higher. I tried to find the details but had no luck. They have since moved on from that prototype codec.
We did try out the web application from the office later on. It worked ok, but you could tell that bandwidth and lag were going to be issues.
Note to anybody else reading this as well: don't take my numbers as gospel, I probably shouldn't have included them since I was not 100% certain of them. What I do know for certain is that the method was just refreshing JPEG's and you could tell the quality was low (it looked great, but at times the picture was the equivalent of a full color photoshop photo exported at a quality level of 2 or 3).
The compression definitely wasn't working across frames, just each frame.
OnLive and Gaikai worked quite good for what they were, but they had much higher bandwidth requirements and still didnt feature really high res.