Concurrent CTO speaks out on 'Start Over'
Feb 13, 2007 8:00 AM
Last month during the Consumer Electronics Show in Las Vegas, Concurrent Computer was recognized with an Advanced Media Technology and Engineering Emmy for its work on the development of "Start Over," a service that allows Time Warner digital subscribers to jump to the beginning of any show they tune to in progress.
Concurrent, which was honored along with Time Warner, BigBand Networks, Harmonic and Scientific-Atlanta, for "Outstanding Innovation and Achievement in Advanced Media Technology for the Best Use of 'On Demand' Technology Over Private (Closed) Networks," spearheaded much of the development.
While the Start Over application is being used in the cable industry by Time Warner, it is equally well-suited for IPTV service providers. IPTV Update spoke with Bob Chism, Concurrent Computer chief technology officer, about the project and where viewer interactivity is headed.
IPTV Update: Could you please describe the basic technology requirements for the Start Over feature Time Warner required?
Bob Chism: The basic requirements from a VOD server perspective is you have to be able to follow a live broadcast within a couple of seconds. When I say "follow," technically what you are doing is being able to write the storage device and then play out of it within a couple of seconds so that your network DVR capability mirrors the same type of user experience you would get with something that everyone seems to be familiar with today, the TiVo device.
IPTVU: Could you describe the primary challenges you had to overcome in designing the Start Over function?
BC: One of the primary hurdles you have to run against is the number of channels to ingest. Although Start Over right now is incremental in terms of their strategy relative to the number of channels they are trying to ingest, they could easily be in the range of 30 to 50 ingest channels that are commercially deployed in an operational environment like we have with the Time Warner, Columbia, SC, site.
But the original model called for as many as 150 channels and above and being able to hold that content on the system for a week or two. So if you do the math on that, you are easily above 40 terabytes or so — quite large.
When you talk about that type of model, you really can't do it with a RAM-based solution. You have to have a solution that is disk-based when you talk about that magnitude of storage.
Some of the challenges associated with that include the need for a very scalable solution, and at Concurrent, we were the first to separate streams and storage and ingest to their own components so that you could independently scale those. You need a very scalable solution to be able to handle that type of volume of channels and the amount of storage that is going to be required.
Another big hurdle is being able to have the software necessary in terms of not only an operating system and file system, but also the application that sits above that. It must not only be scalable but also give you the performance you would need so that you could follow a live broadcast within a couple of seconds.
A lot of the architectures that are out there will not scale appropriately and don't have the level of response necessary to follow that close. Some of the scenarios described to us by some of the MSOs is they didn't want to have situations where the follow of your live broadcast was a large increment of time. They didn't want that.
blog comments powered by Disqus
| Want to use this article? Click here for options! |  |
