How we created the world's best low-latency video streaming system(x264dev.multimedia.cx)
x264dev.multimedia.cx
How we created the world's best low-latency video streaming system
http://x264dev.multimedia.cx/?p=249
6 comments
Nope, not OnLive. They have their own system which I could talk about rather at length if anyone wanted, but in short is really not very good (but is probably passable). They split the frame into 16 rectangular slices and encode them in separate streams, each of which runs at a constant bitrate. Updates to each block are staggered 1ms apart, for a total frame latency of about 16ms.
More problematic is their awful business model, which, given that it's thought up by the guy behind WebTV, is probably not very surprising.
More problematic is their awful business model, which, given that it's thought up by the guy behind WebTV, is probably not very surprising.
From the article they seem to be based on cable style technologies.
There's a company called playcast media who's active in trying to get video games to legacy cable set-top-boxes over video. My guess would be them or something like them.
Article here http://www.itvt.com/interview/6329/itv-doctor-deploying-cons...
Also I'm very bullish on this but there are likely more issues with bandwidth around this then just the video streaming. Upstream over Aloha (which is what most Motorola based systems use for a backchannel) is nasty. Not to mention having to dedicate a stream per-user. Though that can be mitigated with moves to switched digital video.
There's a company called playcast media who's active in trying to get video games to legacy cable set-top-boxes over video. My guess would be them or something like them.
Article here http://www.itvt.com/interview/6329/itv-doctor-deploying-cons...
Also I'm very bullish on this but there are likely more issues with bandwidth around this then just the video streaming. Upstream over Aloha (which is what most Motorola based systems use for a backchannel) is nasty. Not to mention having to dedicate a stream per-user. Though that can be mitigated with moves to switched digital video.
You should get wowza to adopt this technology, the keyframe-less solution is a big step forward.
What are the implications for automatic bandwidth adaptation?
To do all this without touching the decoder, so staying within the standard is really impressive, it's funny how such constraints bring out the creativity.
What are the implications for automatic bandwidth adaptation?
To do all this without touching the decoder, so staying within the standard is really impressive, it's funny how such constraints bring out the creativity.
Doesn't Wowza mostly do offline content, e.g. pre-recorded video? Even in the case of live streaming, the keyframeless option is really only useful if you're trying to go for very low latency, which as I mentioned in the blog post isn't very useful for ordinary broadcast purposes.
The primary target of all this is interactive video: gaming, videoconferencing, and maybe something like Livestream or Justin.tv where a person interacts with viewers who are chatting with them. Ordinary broadcast probably won't benefit.
I should note that the keyframeless solution is not unique to our system: this was done a few times in MPEG-2 broadcast encoders back in the day, as well as in some mezzanine stuff. I haven't seen anyone do it in H.264 though yet; it is made slightly more tricky due to the way that intra prediction in H.264 works.
What are the implications for automatic bandwidth adaptation?
We don't support that yet--but that will probably come soon, as it's the natural next step forward. (Currently the encoder's ratecontrol settings can't be changed without re-initting it.)
The primary target of all this is interactive video: gaming, videoconferencing, and maybe something like Livestream or Justin.tv where a person interacts with viewers who are chatting with them. Ordinary broadcast probably won't benefit.
I should note that the keyframeless solution is not unique to our system: this was done a few times in MPEG-2 broadcast encoders back in the day, as well as in some mezzanine stuff. I haven't seen anyone do it in H.264 though yet; it is made slightly more tricky due to the way that intra prediction in H.264 works.
What are the implications for automatic bandwidth adaptation?
We don't support that yet--but that will probably come soon, as it's the natural next step forward. (Currently the encoder's ratecontrol settings can't be changed without re-initting it.)
They do live streams.
I use them for ww.com.
Most of the time wowza is used for videoconferencing and video chat.
I use them for ww.com.
Most of the time wowza is used for videoconferencing and video chat.
IMO it would be a great step forward in digital tv broadcast too. The current latency when changing channels compared to what one is used to get with analogic tv is a very annoying to me.
Periodic Intra Refresh wouldn't actually decrease channel-change latency--or if it did, it would only eliminate the VBV buffer latency, not the keyframe latency.
Remember, with intra refresh, you still have to wait for the column to cross the screen before the image is visible, so it's not instant. Of course, you could set it up so the user can see the image before it's fully loaded, but people might not like that either.
Remember, with intra refresh, you still have to wait for the column to cross the screen before the image is visible, so it's not instant. Of course, you could set it up so the user can see the image before it's fully loaded, but people might not like that either.
I've done a fair bit of live streaming on justin.tv and uStream; I can't wait to see this new capability available - maybe in Flash Media Encoder?
What would it take to write a Windows driver that pretended to be a monitor but actually multiplexed to an actual monitor and a x264 stream? What kind of bounty would be required to get such a thing written?
Will it play in Flash, like http://www.gaikai.com/ ? That would be awesome...
I'd be willing to bet that Gaikai is the unnamed startup that sponsored/requested this work. (DarkShikari already said it isn't OnLive, and those are the only two companies I know of that are preparing to launch on-demand gaming services that use streaming video).
It's the ultimate answer to game piracy and bots.
As far as I know, Gaikai's not looking to replace consoles or whatnot like OnLive is: the primary purpose is advertising.
Current game demos are a marketer's worst nightmare: to get a player to try them, they have to download gigabytes of installer, install it, and after hours of messing around, they can finally go try the game. Gaikai's goal is to provide a better way for companies to promote their products--not to try to get people to shelve their Xbox.
Which is probably smart, because this kind of video streaming is hardly an efficient way to do gaming in the general case.
Current game demos are a marketer's worst nightmare: to get a player to try them, they have to download gigabytes of installer, install it, and after hours of messing around, they can finally go try the game. Gaikai's goal is to provide a better way for companies to promote their products--not to try to get people to shelve their Xbox.
Which is probably smart, because this kind of video streaming is hardly an efficient way to do gaming in the general case.
It works in Flash with streaming, but Flash won't seek in offline files created with intra refresh (as in, if you try to seek, it will reset to the start of the file, it seems). I haven't tried lately though, maybe they fixed it.
hmm.. boxee could use something like this.
...
Videoconferencing? Pah! I’m playing Call of Duty 4 over a live video stream!
October 2009 seems a little late for it, but could the startup be OnLive? http://www.onlive.com/