itvt

Earlier this year, privately held IPTV middleware provider, Minerva Networks, announced that it had enjoyed an "outstanding year" of customer growth. Over a 12-month period, the company said in a press release, it had received new service contracts from 45 US regional operators, increasing its customer base by over 80%. The release also claimed that Minerva’s platform now powered over 100 IPTV deployments, and that much of the growth had come from IPTV operators that wanted HD, PVR and H.264 support. Minerva’s VP of marketing, Matt Cuson, recently spoke to [itvt]’s Tracy Swedlow about the reasons behind the company’s growth; about the difficulties inherent in providing IPTV customers with both PVR and HDTV; about various new interactive applications Minerva has been working on–including an innovative-sounding VOD application it has co-developed with a "large media company"; about why Minerva believes its IPTV architecture is significantly more scalable than Microsoft’s; about the three biggest challenges the company believes are currently facing the IPTV industry; about why he feels the IPTV industry is still "too young to be bogged down by standards bodies"; and more.

[itvt]: Minerva Networks recently issued a press release claiming that it has experienced an "outstanding year" of customer growth. What’s behind this growth that you claim?

 

Cuson: Well, I think that market conditions overall have been shifting. A number of carriers that had IPTV deployments were looking to the future and starting to get ready for the next-generation set-top boxes, and they began to realize that their existing platforms weren’t going to support their upgrade plans.

Specifically, Alcatel’s iMagicTV project was essentially ended as part of their agreement with Microsoft; the Motorola Next Level activity was discontinued and that team’s focus was shifted; and the Siemens acquisition of Myrio defocused that organization to such an extent that the existing Myrio customers weren’t able to deploy HD or PVR–whereas our customers have been able to offer HD, and SD PVR, for a year-and-a-half already. We’re the only company at this time to offer those two important capabilities.

As people were evaluating their choices, we were viewed as the best option available. As a result, we ended up converting two dozen accounts last year. We didn’t lose any accounts, by the way, and we also added another couple dozen accounts from brand new, first-time IPTV operators. I think these new operators were looking at who had the proven platform, who offered most of the functionality that they needed, and who had customers out in the field that had been able to successfully deploy IPTV and show actual results from those deployments. I think the list of companies that can fulfill those requirements is a pretty short one, and I think Minerva happens to be at the top of that list at the moment.

[itvt]: Yet you haven’t recently announced a huge number of deployments. Could you share with us who your various new customers are?

Cuson: Unfortunately I can’t reveal their names at this point. Many of the ones that are operating broadband TV services already are a little sensitive to the fact that their existing system isn’t all they want it to be. They’re currently ramping up their Minerva implementation, and they’ll go public when all the transition plans are ironed out and they are ready for the switchover. They’re just very sensitive to unsettling and disrupting their current customers. Some of them are using a cap-and-grow strategy, and others are just doing a straight cutover–it all depends on how big they are, how their network is set up, and how they can manage it from an operations perspective.

[itvt]: What kinds of interactive services are your technologies supporting out in the field?

Cuson: We’re supporting pretty much all the things that you would expect to be in the alphabet soup of IPTV. So, full-service EPG, VOD, SVOD, PPV, PVR, parental controls and channel blocking–all the standard things.

Most of our customers right now are operating MPEG-2 networks with standard-definition, though they know that they need to be moving toward MPEG-4. A couple of them actually started out with MPEG-4, or at least invested in MPEG-4 headends last year, thinking that MPEG-4 was coming soon. They ended up being quite frustrated by the lack of set-top box availability and content availability, so they’re happy that MPEG-4 finally seems set to take off. But right now, the vast majority of our customers are still using MPEG-2.

[itvt]: How many of your customers are currently offering HD?

Cuson: Not many, since MPEG-2 HD is really only possible on fiber networks. We do have a handful with MPEG-2 HD, however. We have SureWest here in California running HD on their fiber networks; and we also have MSTAR running HD on DynamicCity’s fiber-based UTOPIA network in Utah. We also have a couple of other fiber-based customers that are looking at HD, but right now, it’s fairly limited. MPEG-2 HD is just a really hard thing to get to work well consistently. A big part of the challenge with it is the inadequacy of current set-top boxes, which simply don’t have enough horsepower: MPEG-2 HD is a lot of data, and the older boxes barely have enough power to keep up. However, I think those challenges are going to go away as a result of the availability of next-generation boxes, based on the Sigma and STMicro chips.

[itvt]: Do you have any customers delivering–or at least trialing–IPTV over MPEG-4?

Cuson: Yes. We have a number of accounts running MPEG-4 headends. However, lack of appropriate set-top boxes has put them in a bit of a bind. But now that we’re compatible with ADB’s new HD DVR’s, they can start to ramp up.

[itvt]: At the TV of Tomorrow Show, SureWest CTO, Bill DeMuth, was saying that one of the biggest challenges currently facing the IPTV space is giving people both HD and PVR, both of which consumers are really eager for right now.

Cuson: He’s absolutely correct. I think this surprises people who aren’t involved in the IPTV space. They just say, "What’s the big deal? Satellite and cable have been offering HD and PVR for years. How hard can it be?"

Well, the problem is that the nature of IPTV is very different than the nature of cable or satellite. The complexity of the set-top box goes up pretty dramatically–though granted you’re getting improved functionality and some other ancillary benefits from this. But, practically, it means that the time-to-market for HD PVR in the IPTV space is a little bit slower than people would like. Because, with IPTV set-top boxes, video is coming into the set-top box through IP, the Ethernet controller has to process every bit, and then the CPU has to move that data to where it can be processed–so video data has to be moved to the decoder, and application data to RAM or other storage. The high bandwidth keeps the CPU busy and the encryption adds a bit of overhead too. With PVR features, you also have to handle the generation of trick play, so the CPU is working even harder. And   optimizing code for such high-bandwidth computation on an embedded system is not a trivial task. With cable set-top boxes, on the other hand, video comes in as video and is piped directly to the decoder. It’s efficient for processing video, but horribly inflexible for building converged applications like you can create with an IP architecture.

Up until about last fall, the HD PVR issue–while a concern for IPTV operators–wasn’t a major one. It was something that they could more or less deal with. Kind of like sand in your shoes: it’s irritating, but you can probably deal with it for a bit. However, in the latter half of last year–especially right around Christmas–there was a sudden, unexpected explosion of interest in HD. This really became a showstopper for IPTV deployments: it was extremely difficult to get consumers to switch if you didn’t have an HD story. It’s this dynamic which I think has resulted in an increased level of interest in our offering over the past four to six months. We are working actively with all the top set-top box vendors to bring an HD PVR set-top to market. We’re very close and will likely have at least one box ready to demonstrate publicly at NXTcomm. Since we’ve been supporting PVR for over a year-and-a-half, we know what it takes to get it right. We’re using that experience to help the set-top box vendors with their HD implementation.

[itvt]: I would have thought that the IPTV industry, which definitely has the potential to show off pretty advanced interactive capabilities, would have focused more on developing differentiating interactive applications in order to compensate for its slowness in rolling out HD. Yet, as it happens, satellite at least currently seems to offer a lot more interactivity than does IPTV.

Cuson: Yes, that’s an interesting observation. But I think it comes back down to the fact that you have to walk before you can run, and you have to crawl before you walk. You see, the first phase of IPTV deployment, at least until 2006, has been dominated by a bunch of small companies–whether that be small operators, small software companies, small conditional access companies, small set-top box companies, or whatever. Most of the players in the IPTV space, at least in North America, and most of the deployments, have tended to be on the small side. So part of the problem is just that the space has not yet reached critical mass–it still needs to scale. What that means is that anybody who might be interested in developing an interesting interactive TV application is going to want to deploy it on satellite or   cable–or even on the Internet in conjunction with a broadband TV service–rather than on IPTV. So one of the challenges that IPTV operators are currently facing is that they’re simply not big enough to get the attention of application developers. And the fact that there are still not unified standards across all of the operators makes it even less likely that a developer is going to want to expend a lot of effort creating applications specifically for IPTV.

That said, one of the interesting things that’s happening with Minerva is that we actually now have a critical mass of customers and we are starting to catch the attention of application developers. Some of these developers are actually tier-two telcos; some of them are independent application developers; some of them are companies that are developing applications in the cable space, and are well-established there, and now want to expand their potential market by reaching out for new IPTV customers.

So, among other things, we’ve been working with a large media company, helping them with their experimentations around interactive applications. We’re targeting this summer for starting a field trial of one of their application ideas. We have also been doing some work with itaas around linking the TV to the mobile phone, so that people can buy and download ringtones and things like that. In addition, we’ve been talking to a number of other companies about building applications around recommendation engines, and about using avatar technology to   make interactive TV applications more interesting. We’re also actively engaged with a number of vendors to bring advanced communication services to the TV. So we have a lot of interesting projects just starting in the interactive TV space. As I said, the developers want to work with us because we finally have enough deployments out there that people are starting to pay attention–but also because, based on what third parties are telling us, we’re viewed as a company that has momentum in the marketplace; and because we now have a set-top box platform that’s robust enough to support some of these more advanced applications.

A key attraction of our platform is our open API’s. Our software architecture makes it possible for a variety of different applications to be developed and deployed quickly. A major advantage of our system is that we offer a hybrid approach to application development. What that means is that developers have a number of ways they can approach their application development. For example, some applications are better suited to a browser and javascript; other applications are better suited to something more native-like. We have four or five different methods for building customized applications. That gives the developer the freedom to use the best tool for the job. Our job as a middleware vendor is to provide choice for the developer while ensuring flexibility, manageability and scalability for the operator.

So, to summarize, I do think you’re going to start seeing more interactive applications in the IPTV space, certainly on networks served by our platform.

[itvt]: At the TV of Tomorrow Show, Bill DeMuth also said that he’d be happy to have people come into SureWest’s environment and experiment with new interactive applications there…

Cuson: Yes. There are a number of companies that have come to us because they talked to Bill: Bill told them, "Yes. We want it. Go work with Minerva." We definitely get a lot of people approaching us with interesting ideas–some of which are going to have legs and others of which are going to fall flat. The key thing for application developers to bear in mind is to be clear about what problem your application is going to solve and how you’re going to monetize it. That’s what it boils down to. From talking to people like Bill and our other customers, it’s clear that no operator is interested in playing with technology just for the sake of playing with technology. They realize that some applications are going to have bugs that need to be ironed out. But they don’t want to waste their time on an application that proves a technology, but doesn’t prove a business case.

When we work with these application developers that are approaching us, we actually spend a lot of time hammering out what the business model for their application is going to be. We have to make sure that if we’re going to test something, it’s going to be something that has some immediate applicability, not something that’s going to require extra bandwidth in the network or some kind of content license that you might not have any hope of getting. We also come across a lot of interactive TV application ideas that are predicated on the operator being a mobile services operator as well: that’s just not going to fly for a lot of our customers–they just can’t afford to do that.

 

So, when it comes to us working with application developers, it’s not just about being compelling; it’s all about time-to-market, time-to-revenue, low-risk technology, and taking advantage of what’s available right now.

[itvt]: When you work with these application developers, what’s in it for you? Could you clarify the business model behind your work with the application developers?

Cuson: Minerva is both a middleware vendor and an application developer. As a middleware vendor, we want a robust community of developers, and we’re working hard to provide a comprehensive platform that makes development easy but also makes application provisioning, deployment and management straightforward and scalable for the operator. As an application developer, we want to make our applications best in class. That means a great experience for the user, and plenty of flexibility for the operator.

In terms of a business model, we expect to sell the application enablement to the operators–so server and/or client licenses, depending on the nature of the application–and the developer will sell the app themselves. In some cases, we’re willing to take on a reseller role, but not as a general rule. I imagine there will be some cases where a revenue-sharing model could make sense too. For the most part, our revenue will come from selling the framework licenses that might also include a client-side component.

[itvt]: You mentioned earlier that you are working on an application with a "large media company." While I’m assuming that you used that phrase because you’re not at liberty to disclose the company’s name, could you tell us about the application?

Cuson: It’s an interactive application around on-demand content. It’s designed to solve a general problem that they’re facing, which is, "Gee! We have so much content. It just isn’t going to be a pleasant experience for people to have to navigate through cascading menus to find the assets that they want to watch. We want to be able to control the viewing experience for our on-demand content much like we control the viewing experience for broadcast TV. We want to be able to bring that same degree of control into the on-demand world. We know that we’ve been able to do this kind of thing on the Internet through our video portals. So what’s possible on managed networks? What are the limitations of those networks? And what will the business model be for this kind of application?" So that’s what they’re experimenting with, and we’re helping them do that.

The company is hoping to create a viewing destination that feels like a live TV channel, but is customized for each individual viewer. When a user enters their "channel," their application pushes us a play list with a series of trigger events and instructions on what to display with each event. We give them control over how the video is played back. They can scale and position video, display any graphics anywhere on the screen, and recommend links to other programs. Of course with this basic platform, it’s easy to incorporate both graphic and video-based advertising, collect user viewing statistics and preferences, and even extend it to tcommerce applications. The media company will be testing out all those applications–though not the tcommerce idea, even though they are the perfect company to try it!

[itvt]: You also mentioned earlier that you are working with itaas…

Cuson: itaas has developed a number of applications for the cable space. Before we began working with them, one of the things they’d developed was an infrastructure for interfacing to mobile phone service providers. They had approached a content owner, MTV, and had used this infrastructure to develop an application that would allow you to download to your mobile phone content associated with songs and artists playing on MTV’s regular broadcast channels. So, if there’s a song playing that has downloadable content associated with it–whether that be a ringtone, graphics, a video or whatever–viewers would be prompted that they could order it and have it downloaded to their mobile.

After they’d done all the plumbing to hook all these elements together, and had written this application for cable set-top boxes, they came to us and said they wanted to port the application to IPTV. We said, "We’ve got this great little API. Here’s what you can do," and we were able to interface with their system in a matter of weeks. It provides a great user experience, and it runs like it’s native on all of our set-top boxes. And it’s something that I think has a lot of applicability in a lot of different areas.

Now, in the very short-term, one of the market problems we face with this app is that most of the telcos that we sell to at the moment are relatively small, and so don’t have mobile phone services. So we’re trying to figure out the business model for how this would work for the smaller telcos. On the other hand, this application is clearly something that plays very nicely into the business models of the larger telcos. We’re engaged with a number of larger telcos who are evaluating their IPTV options and we hope to trial this application with at least one of them.

 

[itvt]: One of the issues that frequently comes up in discussions about IPTV is scalability. How are you ensuring that your platform is scalable?

Cuson: When Minerva first started–when we came out with our 1.0 version–we took the approach most people would think was a logical choice: build regular Web applications that run with a browser. We figured, "What the heck? It’s IP. It might as well be in a browser. How hard can it be?" So we launched our middleware and our applications around this model of Web applications delivered through a browser. However, it didn’t take us very long to figure out that it just wasn’t going to work. The browser model doesn’t scale well at all for TV applications. Performance is unacceptably slow, even in relatively small deployments. A user can have an adequate experience during the day, and then have to wait 15 seconds to load the EPG during primetime. So performance is both slow and unpredictable. The cost of the infrastructure necessary to ensure a consistent, quality TV experience is just prohibitive. In addition, as you add more subscribers to the network, they generate more network traffic and that traffic consumes bandwidth you need for the video. It doesn’t take long on DSL networks for that extra traffic to start to cause macroblocking of the video. It just isn’t a practical solution, given the very narrow acceptance-band people have regarding their TV experience.

So we went back and redid the architecture and spent some time studying what was good about the Web-applications model, what didn’t work, and how we could overcome its shortcomings without creating more problems for ourselves.

As a result, our architecture reflects our understanding of the real world of IPTV. We recognize the importance of a great user experience, and appreciate the realities of operating a video network. Our architecture is designed to retain the best features of the Web-applications environment without the shortcomings. We felt it was important to maintain the ability to easily customize our applications without having to write complex code. We wanted to keep the centralized management of personal data and preferences. We didn’t want to have to build large server farms, nor did we want to use any more network bandwidth than was absolutely necessary.

In addition, from the start, we were very sensitive to the fact that, in the early days, the set-top box had very little processing power and very little memory. You had to be extremely respectful of the fact that very limited resources were available on the set-top box, as well as on the network itself. Some of the operators we were working with were trying to deliver video services by running DSL over bad copper, and could barely eek out eight megabits to the home. You had to be respectful of every single bit on the line, and not hog bandwidth.

Moreover, the operators we were targeting were relatively small: they weren’t particularly tech-savvy, and they didn’t have big operations teams. As a result, we had no choice but to build our software so that it was easy to manage and wasn’t going to be a burden on their operations. Simple applications get very complicated very quickly if you have to keep adding servers. The operational overhead of such a complicated system design just isn’t affordable.

So one might say that, because we grew up in a very harsh environment, we learned how to be very efficient with our resources. We were smart about some of the decisions we made early on, and it’s now starting to pay off for us. For example, we use multicast extensively in the network. Multicast technology allows all the set-top boxes on the network to access data simultaneously without having to hit the server. In effect, by using multicast technology, we use the network as a giant data cache that everyone shares. So no matter how many set-top boxes you have on the network, the network bandwidth you need to support them all remains fixed. Also, since the data is in the network, not on a server, the application servers can be small and you don’t need very many of them. Our customers typically have two servers–one for the application, one for the database–and then a couple for backup. Such a configuration can support over a hundred thousand users and a 500 channel line-up.

Also, our set-top box client applications are all written in C, so we don’t need the extra memory or CPU power required to run a Java Virtual Machine or any other run-time environment. We’ve designed our applications in such a way that they are customizable without anyone   having to do any additional programming. Our set-top box client has three main components. First is the executable itself. That is what has all the logic of the application. Since it is C, it is small and very fast. The second piece is the set of graphics elements we use to create the user interface. We’ve carefully designed these elements to be compact and reusable with the application. Third is the configuration file and localized text strings. These files describe how the UI will look and what text will be displayed by the application itself. The EPG and VOD data comes from third-party sources that we multicast to all set-top boxes. At boot time, the set-top loads the application from Flash memory, then joins the multicast to pick up the graphics and configuration information. Once booted, the set-top box is ready to go, and will periodically rejoin a multicast to get the updated EPG and VOD data.

With this approach, we are able to maintain some of the better qualities of HTML applications without any of the downsides.

We also did some work that makes the process of porting from set-top box to set-top box a little bit easier and more predictable. We’ve designed an abstraction layer that separates the underlying set-top box hardware from our applications. Set-top box vendors are able to build their software as they like and any changes we make on our side, they   don’t have to worry about. Likewise, they’re free to make changes without affecting what we do. We work together with the set-top box vendors to define how best to take advantage of new hardware features, of course, and those changes are made to the abstraction layer without having to completely rewrite the code. We’ve architected our system to intelligently use set-top box storage for data as much as possible (which isn’t much on some of the older set-tops), leverage multicast technology as much as possible to cache data in the network itself, and to only put data on the server when we absolutely have to due to security or reliability requirements. The approach ensures that a user on a network will get a consistent user experience all the time, regardless of the number of users active on the network, or the number of set-top boxes hanging off of a server. One of the major benefits of our approach that isn’t obvious is the fact that our system requires much less operational overhead. We consume fewer infrastructure resources–servers, network bandwidth, etc.–and, hence, require fewer operational resources to run and maintain the systems. I would say that our system is much more scalable than Microsoft’s, for example.

[itvt]: Why is that?

Cuson: Fundamentally it boils down to the fact that we need dramatically fewer servers. Here’s an example. We had a tier-two telco in here talking to us about our system and they were also considering a lab system with Microsoft. They were actually building a special building for it. I asked the question, "How big is this Microsoft-based lab system?" And they said that it was going to be 15 servers, or something like that. I said, "Wow! That’s a big lab system. How big is your trial going to be?" They said, "Oh, with that set-up we expect to support 50 users and 15 channels." When I told them that we could support tens of thousands of subscribers and channels on a single server, their jaws hit the floor.

Microsoft approaches the problem very differently than we do. They have a PC mentality. They are used to working with Intel on building applications around faster chips and more memory. We come from the world of the telco: lean infrastructure, fixed for years. Microsoft will have to explain their system to you, but my understanding from what I’ve seen with their demonstration is that their D servers are generating customized video streams for each user and each channel. As you add users, you add more servers. As you add channels you add more servers. Grow both channels and users, and the number of servers multiplies out of control. We don’t have those interdependencies, so we can scale to hundreds of thousands very quickly, and you can do it all on a couple of servers. We avoid all that unnecessary complexity.

What you get with all this server proliferation from Microsoft is what they call "instant channel-change." From our perspective, Microsoft is trying to solve a problem that, for all practical purposes, doesn’t exist. Our system already allows you to change channels consistently in less than a second, and I think if you can get sub-one-second channel-change, most people are going to be happy with that. Fast, or instant, channel-change is a physics problem that can be addressed a number of different ways in the network; and we think that the likes of Cisco, and even Alcatel and others, are going to figure this problem out soon and some vendors have solutions already on the market.

The root of the debate around channel-change speed lies in how HD can be encoded in MPEG-4/H.264. Because of the way H.264 can encode the video stream, you can create a condition where you’ve got multiple-second channel-change times. I think Microsoft must have felt compelled to invent a technology to solve those kinds of problems. While they’ve succeeded in coming up with a way to solve these problems, it costs you a lot in terms of servers, and it also costs you a lot in terms of network bandwidth. We feel that there are other, cheaper ways of solving these problems that will be provided by the network equipment providers, and we expect to be able to take advantage of these as soon as they become available. Cisco, in fact, has already announced products in this category. So I would say the problem of fast channel-changes is one that has multiple solutions: Microsoft has one approach, and the network equipment vendors have another.

[itvt]: What other challenges do you see currently facing the IPTV space?

Cuson: I think that the IPTV space in general is now facing a challenge of last-mile bandwidth. Implementing HD, of course, is a big deal, and, up until now, the focus has been on the set-top boxes not being available. But now that they’re starting to become available, the focus is going to have to switch: the fear among operators is that existing DSL networks might not be fast enough to offer a compelling HD service.

The challenge has to do with the number of streams an operator is going to need to be able to put into the home. A year ago, people were thinking, "OK, all you need is one HD stream and one SD stream–or, at most, one HD stream and two SD streams." Now, the talk is around delivering two HD streams and two SD streams simultaneously to the home. Such a case could well mean that you’ve just blown your last mile–there’s no way that you could deliver that many streams over copper without some major upgrades.

So, obviously, this last-mile problem is something that needs to be solved; and a big part of that is going to be understanding what’s minimally acceptable to subscribers–i.e. how many HD streams do they really need to the home? Typically, the number is based on the hypothesis that the average end-user is going to have a PVR box on which they’re going to watch one show in HD while recording another show in HD in the background, and that they’re then going to have two more TV’s in the home that could be turned on at the same time. So, two live HD streams plus two live SD streams equals eight megabits plus eight megabits plus 1.5 megabits plus 1.5 megabits–which ends up being a pretty huge amount of bandwidth to support over the older DSL networks.

The next big challenge is access to content. The smaller operators are still having significant difficulties getting access to content. It’s really a two-fold problem: one part of it has to do with the licensing terms around the content and the cost of that content; the other part is the cost of the headend to get it. So if you’re going to build your own headend, it’s probably going to be an MPEG-4 headend, and therefore cost something in the region of $20,000 to $30,000 a channel.

Of course, companies like SES Americom and Avail Networks are bringing a headend-in-the-sky model to market to help lower the cost of the headend. That kind of thing could certainly help. But in the IPTV world, at least, they’re still a little bit unproven. We know that this kind of thing can be done in the cable space, but there are probably going to be some surprises and glitches that show up in the IP space. So I definitely think that access to content and receipt of content are going to be significant challenges.

The third challenge, I think, will be the cost of the set-top boxes, and of setting up the end-user in general. Once you’ve built out the network, it’s still very expensive on a cost-per-home basis to go out and rewire the home. Obviously, the cost of the set-top box itself is a big factor, but the number of hours it takes to pull CAT5 or to hook up to a coax system can end up being quite significant.

[itvt]: Do you have any suggestions as to how the three major challenges you’ve outlined can be solved?

Cuson: We offer a number of ways for the operator to manage last-mile bandwidth. We have other ideas on how we can build more intelligence into our middleware and applications to allow an unlimited number of TV’s and set-top boxes in the home, even on DSL networks. I hope you’ll forgive me if I don’t reveal our plans in detail at this time.

As for content, we’re working with a number of partners who are looking at building shared or hosted IPTV services. By leveraging their networks and operations expertise, they not only lower the cost of content acquisition, they also lower the upfront costs of building out an operations center and training the staff. We’ve made some significant enhancements to our software to make such a business model possible. We think we have a unique advantage in this area.

And as for set-top boxes, the costs will come down. We already see prices from Chinese manufacturers hitting amazingly low price points for large volumes in some international markets. We don’t expect the same to happen in the US because there seems to be more of a willingness to pay for a brand-name product. However, the international dynamics will help drive down prices in the US too. We will support at least six different set-top box vendors on our platform. Such a choice will keep competition in the set-top box segment healthy.

 

[itvt]: How big a problem do you think the lack of standards for the IPTV space is, and what do you think of the various efforts underway to remedy it?

Cuson: IPTV is too young to be bogged down by standards bodies. There are too many unknowns, too many areas where innovation is required, and too many vendors doing creative work. Standards will be built around companies that have compelling solutions. As I mentioned earlier, we tried using traditional Web applications using all sorts of standards, and they didn’t work from a practical standpoint. We use standards in our product every place we possibly can. Unfortunately, some standards just can’t handle the unique demands required for broadcast-quality TV video. In those cases, we innovate. And then we share the API’s with our partners to help our customers quickly deploy and grow their service.

[itvt]: What kinds of announcements should we expect to hear from Minerva over the coming months?

Cuson: 2007 will be another big year for us. We have a number of very large telcos in our pipeline and expect to have them ready to make public announcements soon. We also have a growing list of application development partners and we’ll be expanding that program as well. In addition, all the top set-top box vendors will soon be announcing completion of the certification process of their set-tops with our platform. We’re already done with ADB, and will follow shortly with completed certifications from Scientific-Atlanta, Motorola, Amino, and Entone.

URL: Minerva Networks

Originally Published: June 6, 2007 in [itvt] Issue 7.33

Click: http://www.itvt.com to subscribe to our free email newsletter, which contains all the news stories you see on this Web site, and additional breaking news and scoops, in-depth features, interviews, screenshots, videos, and other exclusive content you will not find anywhere else.