The best solution ofc would be for google to release a better codec than ogg theora for free, with no patent risk, and with video quality at least comparable to h264's.
I think the problem is that there are patents for many of the methods that you'd necessarily use in a modern video codec.
Imagine trying to build a non-patent-encumbered car, when someone held patents on things like tyres, steering wheels, cams...
Open free code that may be illegal to use, depending on what country you're in, without paying MPEG LA.
Sure, you can probably get away with it for a while for personal use, even for a small-fry web site. As soon as you're big enough to get noticed, they'll come after you with an invoice.
But in any case, it sounds like a misnomer to call it "HTML5 Video", which sort of implies a standard.
As far as I understand, the HTML5 standard does not specify ANY standards. They tried, but there were people with vested interests on the committee, and it proved impossible to come to an agreement.
So, HTML5 says you can use any codecs and any container format within a <VIDEO> tag. It's up to the developer to know what browsers support.
Everyone already has H.264 software. Nobody has Ogg software. I bet if you checked outside of this thread you'd find 0.1% of people have it an about 90% can alreay play H264.
Everyone with (current) Firefox or Chrome already has an Ogg Theora viewer. I'll wager that's more than 0.1%.
Everyone with Safari, Chrome or Flash has an H.264 viewer. I'll wager that's more than 90%.
Thirdly ogg just sounds stupid. I wouldn't implement it for the name alone.
Perhaps they should rename I.375 for your benefit?
Why would you use H.264 instead of Ogg Theora to create your videos? What we're talking about here is how you would play videos created by someone like Youtube. The standard doesn't mandate H.264. It just fails to mandate Ogg.
If you only put Theora videos on your site, they won't be viewable in Safari (using default Quicktime components), iPhone or Android.
There is no single combination of containers and codecs that works in all HTML5 browsers.
To make your video watchable across all of these devices and platforms, you’re going to have to encode your video more than once.
As long as there are mainstream platforms that don't support Theora, either you have to encode to H.264 yourself (and pay) or have someone else (e.g. YouTube) encode and host it for you.
They'd have to go back and reencode the entire YouTube library if they wanted to offer it in Theora.
It honestly wouldn't surprise me if they were quietly doing this as a background task, just in case.
It would cost them storage, and processing time - they may have offpeak cycles free. It would put them in a position where they could switch to Theora more easily, should they decide to.
Or they could throw it all away. Depends how the ecosystem develops.
Another solution would be one where they serve you Theora if they have it, and fall back on something else if they don't. Not ideal, but possible to deliver sooner.
I think there are pressure sensors in the neck, which correspond to guitar notes. The touchpad probably has columns corresponding to where the strings would be. So hit the E-string part of the touchpad while holding the first fret of the E-string part of the neck, it will play an F.
This doesn't allow you to bend notes with the fretting hand. Most guitarists will find this to be major omission.
I don't want to come over all Luddite - but surely part of playing guitar is the sensation of the strings against the fingers. You know where they are, because you can feel them. You know whether and how hard you've plucked/strummed, because you can feel them.
I think playing this thing would be a bit like typing on an on-screen keyboard - a second class experience.
For games with a beginning, middle and end - I'm grateful if they're short. 8 hours or so is good. So dollars/hour is not a good metric for me. I'd rather quality than quantity.
Replay value is always welcome, of course - but it depends on the type of game. I'm all for something I can buy, *really* enjoy for 8 hours, then trade in.
For me $10/hour of actual fun, is better than $1/hour of tedious grinding. Of course some people enjoy grinding... weirdos.
I too would expect this jerkiness, and it's surprising therefore that the review doesn't mention it.
Perlman goes on about "psycho-perceptual" techniques, and I wonder whether that's enough to deal with the situation.
For example, a really smart decoder could detect that the scene in general is panning, or zooming (e.g. a racing game, going in a straight line), or rotating, or some combination of these. Indeed the encoder could include hints in the stream. The game engine could even feed extra information to the encoder info to assist in this.
Using that knowledge, the decoder can do something, when it encounters a missing frame. That is: "In the last 3 frames, I was more or less zooming. I have not received the current frame. Therefore I'll enlarge the previous frame by the same proportion and hope the user doesn't notice."
That's entirely speculation on my part. I do know for sure (unless Perlman lied) that any frames received late are not displayed, and that the protocol does not re-send dropped packets. You'd expect frequent and jarring glitches if the strategy for dealing with missing frames was simply to freeze on the current frame.
You can get very capable graphics cards for under $200 these days. How is that more expensive than this service will be?
We don't know how much OnLive will cost. I would hope it compares well with $200. Or at least, the $200 would be spread over time - and as irrational as that is, it works for many people.
Perlman has talked about a subscription fee. I feel this is a mistake. I think they shouldn't put people off with any sense of buying into a commitment. Charge per game, or per hour. You might end up spending $200. But you wouldn't commit to $200 at the start.
But $200 for a graphics card isn't the whole story. Before you buy one, you have to grasp a load of technobabble. Then you have to fit it. Then you have to install drivers. If you're as unlucky as I usually am, you'll have stability problems with those drivers and more headaches.
These aren't major obstacles for a determined gamer. But again, this service isn't aimed at that kind of person. This lets people get the pretty pictures without knowing what DirectX is.
I'm not sure the graphical complexity of the game will have much bearing on bandwidth usage. I imagine that scenes from Quake III encoded to some video codec, would be about the same size as scenes from Crysis on Ultra encoded with the same codec, would be about the same size as scenes captured on an HD camcorder encoded with the same codec.
Crysis is *the* demo for this service. I've seen analysis that says they appear to be using a graphics level a notch down from 'Ultra' - but I suspect the motivation for that is to use less GPU resource, not to ease bandwidth usage or to take load off the encoder/decoder.
You *will* need the bandwidth. If you can't sustain 450kbps, you're either not paying for the 5MB line OnLive will require, or you're not getting your money's worth and should be complaining.
OnLive is banking on typical consumer broadband speeds improving. No doubt plenty of other enterprises will be doing the same. Presumably as these services come online, consumer demand will cause a feedback loop that makes this happen.
It's not that long ago that streaming audio over the internet was unthinkable. Now we think nothing of steaming SD video (e.g. YouTube). 720p video streams OK for many people. Low latency bufferless 720p has been shown to be achievable, and if market forces work properly, will become more common over time.
However there are two types of latency OnLive is dealing with.
Lots more than two - of varying severity. And they all get summed.
- controller encoding button presses
- controller to client transmission
- client decodes controller protocol
- encode and transmit control signals to server
- decode controls and input to game
- processing performed by the game itself
- video encoding
- transmit video to client
- client decodes video
- client transmits video to TV
Perlman claims that OnLive examined every step, because every ms counts. Obviously some steps are 100% beyond their control (the last one, for example). In one presentation he said that they couldn't support Wii controllers because the protocol introduced too much lag. The Wii doesn't care about that lag, because it doesn't have the Internet factor to accumulate on top of it.
the only real thing they can do is put the data centres closer to the end-user to improve performance
They're doing that. But Perlman claims that they're also:
- Developing smarter routing algorithms
- Tuning at the IP packet level, to increase speed on domestic routers etc. (I guess this is largely about getting the MTU right, dynamically)
OnLive knows all this. They set themselves a target of 80ms round-trip latency.
To achieve this, they set certain geographical limits. This journalist broke those limits. The software warning him about high latency. He observed high latency.
And yet this review - from a sceptic - says it pretty much works. While it's in beta. From a location that would have been excluded from the beta if he'd gone through proper channels.
People that play graphically intensive games online [...] And most of these people will have higher-than-average spec computers anyway
It's not intended for the people you're talking about. Those people already have a means to play high-end games; and they're probably stuck in their ways too.
OnLive is for people who currently don't play those games, because of the cost/effort. People who are curious to try Crysis, but not curious enough to buy a gaming graphics card. The aim is to remove the barriers that say 'Casual gamers must tolerate low end graphics'.
Even when it's a full product, you won't be allowed to sign up if you're not in a geographically suitable place.
It seems that the eventual plan is that it will dynamically assign your session to the closest datacentre. But for the timebeing, each Beta tester's ID is assigned a datacentre at registration time, and that's the one that ID will use every time.
It explains in the TFA that he borrowed the login credentials from a beta tester in another part of the country. Hence he wasn't using a nearby server, as he would have been if he was a real beta tester, or in future, a paying customer.
It's pretty amazing it worked as well as it did, considering all that.
Slashdot Mirror
The best solution ofc would be for google to release a better codec than ogg theora for free, with no patent risk, and with video quality at least comparable to h264's.
I think the problem is that there are patents for many of the methods that you'd necessarily use in a modern video codec.
Imagine trying to build a non-patent-encumbered car, when someone held patents on things like tyres, steering wheels, cams...
Open free code that may be illegal to use, depending on what country you're in, without paying MPEG LA.
Sure, you can probably get away with it for a while for personal use, even for a small-fry web site. As soon as you're big enough to get noticed, they'll come after you with an invoice.
I can actually hear the 'woosh' sounds from here, as your point flies over the head of a million /. readers.
But in any case, it sounds like a misnomer to call it "HTML5 Video", which sort of implies a standard.
As far as I understand, the HTML5 standard does not specify ANY standards. They tried, but there were people with vested interests on the committee, and it proved impossible to come to an agreement.
So, HTML5 says you can use any codecs and any container format within a <VIDEO> tag. It's up to the developer to know what browsers support.
Sucky, but there it is.
The concerns would more likely be:
- storage
- conversion costs (processor time)
However, these get cheaper all the time. Hosting both formats is the only option right now, if you want to take the HTML5 high road.
Everyone already has H.264 software. Nobody has Ogg software. I bet if you checked outside of this thread you'd find 0.1% of people have it an about 90% can alreay play H264.
Everyone with (current) Firefox or Chrome already has an Ogg Theora viewer. I'll wager that's more than 0.1%.
Everyone with Safari, Chrome or Flash has an H.264 viewer. I'll wager that's more than 90%.
Thirdly ogg just sounds stupid. I wouldn't implement it for the name alone.
Perhaps they should rename I.375 for your benefit?
Why would you use H.264 instead of Ogg Theora to create your videos? What we're talking about here is how you would play videos created by someone like Youtube. The standard doesn't mandate H.264. It just fails to mandate Ogg.
If you only put Theora videos on your site, they won't be viewable in Safari (using default Quicktime components), iPhone or Android.
Professor Markup says:
There is no single combination of containers and codecs that works in all HTML5 browsers.
To make your video watchable across all of these devices and platforms, you’re going to have to encode your video more than once.
As long as there are mainstream platforms that don't support Theora, either you have to encode to H.264 yourself (and pay) or have someone else (e.g. YouTube) encode and host it for you.
They'd have to go back and reencode the entire YouTube library if they wanted to offer it in Theora.
It honestly wouldn't surprise me if they were quietly doing this as a background task, just in case.
It would cost them storage, and processing time - they may have offpeak cycles free. It would put them in a position where they could switch to Theora more easily, should they decide to.
Or they could throw it all away. Depends how the ecosystem develops.
Another solution would be one where they serve you Theora if they have it, and fall back on something else if they don't. Not ideal, but possible to deliver sooner.
I think there are pressure sensors in the neck, which correspond to guitar notes. The touchpad probably has columns corresponding to where the strings would be. So hit the E-string part of the touchpad while holding the first fret of the E-string part of the neck, it will play an F.
This doesn't allow you to bend notes with the fretting hand. Most guitarists will find this to be major omission.
I don't want to come over all Luddite - but surely part of playing guitar is the sensation of the strings against the fingers. You know where they are, because you can feel them. You know whether and how hard you've plucked/strummed, because you can feel them.
I think playing this thing would be a bit like typing on an on-screen keyboard - a second class experience.
For games with a beginning, middle and end - I'm grateful if they're short. 8 hours or so is good. So dollars/hour is not a good metric for me. I'd rather quality than quantity.
Replay value is always welcome, of course - but it depends on the type of game. I'm all for something I can buy, *really* enjoy for 8 hours, then trade in.
For me $10/hour of actual fun, is better than $1/hour of tedious grinding. Of course some people enjoy grinding... weirdos.
I too would expect this jerkiness, and it's surprising therefore that the review doesn't mention it.
Perlman goes on about "psycho-perceptual" techniques, and I wonder whether that's enough to deal with the situation.
For example, a really smart decoder could detect that the scene in general is panning, or zooming (e.g. a racing game, going in a straight line), or rotating, or some combination of these. Indeed the encoder could include hints in the stream. The game engine could even feed extra information to the encoder info to assist in this.
Using that knowledge, the decoder can do something, when it encounters a missing frame. That is: "In the last 3 frames, I was more or less zooming. I have not received the current frame. Therefore I'll enlarge the previous frame by the same proportion and hope the user doesn't notice."
That's entirely speculation on my part. I do know for sure (unless Perlman lied) that any frames received late are not displayed, and that the protocol does not re-send dropped packets. You'd expect frequent and jarring glitches if the strategy for dealing with missing frames was simply to freeze on the current frame.
I assure you I do not have any vested interest whatsoever.
I think this is a well thought out post in general. However:
1.5Mbits/s for the feed per user for SD experience with OnLive.
TFA measured ~750kbps for 720p.
Maybe your 1.5Mbps was from OnLive's announcement of the peak bandwidth required?
You told us there would be a 480ms round trip. That would make it unusable.
This guy found it was pretty much OK, despite being further than the servers than recommended.
You can get very capable graphics cards for under $200 these days. How is that more expensive than this service will be?
We don't know how much OnLive will cost. I would hope it compares well with $200. Or at least, the $200 would be spread over time - and as irrational as that is, it works for many people.
Perlman has talked about a subscription fee. I feel this is a mistake. I think they shouldn't put people off with any sense of buying into a commitment. Charge per game, or per hour. You might end up spending $200. But you wouldn't commit to $200 at the start.
But $200 for a graphics card isn't the whole story. Before you buy one, you have to grasp a load of technobabble. Then you have to fit it. Then you have to install drivers. If you're as unlucky as I usually am, you'll have stability problems with those drivers and more headaches.
These aren't major obstacles for a determined gamer. But again, this service isn't aimed at that kind of person. This lets people get the pretty pictures without knowing what DirectX is.
Less than 200 miles from Chicago. You'll be fine.
In fact you're already on their coverage maps. I'd be astonished if they didn't expand from the three datacentres used for the Beta.
I'm not sure the graphical complexity of the game will have much bearing on bandwidth usage. I imagine that scenes from Quake III encoded to some video codec, would be about the same size as scenes from Crysis on Ultra encoded with the same codec, would be about the same size as scenes captured on an HD camcorder encoded with the same codec.
Crysis is *the* demo for this service. I've seen analysis that says they appear to be using a graphics level a notch down from 'Ultra' - but I suspect the motivation for that is to use less GPU resource, not to ease bandwidth usage or to take load off the encoder/decoder.
You *will* need the bandwidth. If you can't sustain 450kbps, you're either not paying for the 5MB line OnLive will require, or you're not getting your money's worth and should be complaining.
OnLive is banking on typical consumer broadband speeds improving. No doubt plenty of other enterprises will be doing the same. Presumably as these services come online, consumer demand will cause a feedback loop that makes this happen.
It's not that long ago that streaming audio over the internet was unthinkable. Now we think nothing of steaming SD video (e.g. YouTube). 720p video streams OK for many people. Low latency bufferless 720p has been shown to be achievable, and if market forces work properly, will become more common over time.
Have you noticed how people tend to cluster into populous areas?
My wild guess is they'll put the servers where the people are, rather than expect people to move.
However there are two types of latency OnLive is dealing with.
Lots more than two - of varying severity. And they all get summed.
- controller encoding button presses
- controller to client transmission
- client decodes controller protocol
- encode and transmit control signals to server
- decode controls and input to game
- processing performed by the game itself
- video encoding
- transmit video to client
- client decodes video
- client transmits video to TV
Perlman claims that OnLive examined every step, because every ms counts. Obviously some steps are 100% beyond their control (the last one, for example). In one presentation he said that they couldn't support Wii controllers because the protocol introduced too much lag. The Wii doesn't care about that lag, because it doesn't have the Internet factor to accumulate on top of it.
the only real thing they can do is put the data centres closer to the end-user to improve performance
They're doing that. But Perlman claims that they're also:
- Developing smarter routing algorithms
- Tuning at the IP packet level, to increase speed on domestic routers etc. (I guess this is largely about getting the MTU right, dynamically)
OnLive knows all this. They set themselves a target of 80ms round-trip latency.
To achieve this, they set certain geographical limits. This journalist broke those limits. The software warning him about high latency. He observed high latency.
Note that some games are perceived as OK despite up to 200ms round-trip latency. GTA IV on the Xbox was measured to have 133-200ms latency. Nobody cared because it's not a twitch game.
And yet this review - from a sceptic - says it pretty much works. While it's in beta. From a location that would have been excluded from the beta if he'd gone through proper channels.
People that play graphically intensive games online [...] And most of these people will have higher-than-average spec computers anyway
It's not intended for the people you're talking about. Those people already have a means to play high-end games; and they're probably stuck in their ways too.
OnLive is for people who currently don't play those games, because of the cost/effort. People who are curious to try Crysis, but not curious enough to buy a gaming graphics card. The aim is to remove the barriers that say 'Casual gamers must tolerate low end graphics'.
Even when it's a full product, you won't be allowed to sign up if you're not in a geographically suitable place.
It seems that the eventual plan is that it will dynamically assign your session to the closest datacentre. But for the timebeing, each Beta tester's ID is assigned a datacentre at registration time, and that's the one that ID will use every time.
It explains in the TFA that he borrowed the login credentials from a beta tester in another part of the country. Hence he wasn't using a nearby server, as he would have been if he was a real beta tester, or in future, a paying customer.
It's pretty amazing it worked as well as it did, considering all that.