The Day-to-Day Reasons for OCAP

Publish date:
Updated on

The weary consensus of the people cooking up new digital-cable applications at program networks is, not surprisingly, that it’s a nightmare — from a hands-on, code-writing perspective.

Cable providers agree: Implementing a “red button” with more sizzle than the one under the thumbs of Rupert Murdoch’s European customers is just plain painful.

The answer, both camps agree, is something that removes the need to constantly futz with the thick mesh of differences within the fielded base of digital boxes. Differences mean recompiling and recompiling, over and over, every time something changes. As one cable technologist puts it: “Every day of the week, I have to get a code drop from somebody.”

Things get more acute as operators — most of which currently store between 1,500 and 3,000 hours — start talking about bumping their on-demand storage libraries to 10,000 hours. From a navigational perspective alone, how does a reasonable person navigate a library that big? Scrolling down a 10,000-title text list doesn’t seem practical — or much fun, for that matter.

And that’s just one application.


An operator, for example, may use digital-video headend equipment made by both Motorola Inc. and Scientific Atlanta Inc. (Not in the same system, generally, but in the big picture of what’s out there.) Maybe that same operator uses three different types of electronic program guides, two different VOD vendors and four different generations of digital set-tops.

Maybe the four generations of digital set-tops each house a successively better processing chip. That means any software changes need to be recompiled individually — for each chip.

Perhaps the four generations of digital set-tops each house a successively better processing chip, which links to other supporting chips, like graphics and networking, and to the embedded software within them.

Altogether, that’s what technologists refer to as “firmware.” It means that any application that’s to run across all four generations of set-tops must be recompiled individually — for each version of firmware.

Then there’s the making-it-work part. Doing it right — so that new digital-cable applications work across gigantic bunches of differing boxes — calls for internal software engineers to run quality-assurance laboratories. It needs methods to keep sanity around software revisions, which come in daily, and from everyone involved.

Talk about a matrix of pain: It’s a nutty amount of work, best done by logical, steady people. And even then, it can push a person into a catatonic stare.


The story isn’t much happier for the few programmers who write code to make TV shows more useful or entertaining for the digitally enabled. They have to hand-code the “differences mesh” of all digital video headends, all guides, and all set-top generations — or at least all that are targets for augmented shows.

In software language, these coding differences fall under the larger mantle of “porting.” To “port” software is to make it to run on different types of machines.

Example: Say you’re a programmer, in the computer-science sense of the word. Say you work for a cable network. Your quest is to develop clickable things that hopefully beckon digital cable customers to engage.


For the sake of illustration, let’s say the clickable thing lets you toggle yourself to the on-demand library within your particular network, while someone is watching a show. (This application isn’t quite happening yet, but it seems like a plausible effort.)

First, your graphics guru figures out how to make the toggle look enticing on the screen — without overstepping the tight limits of what’s possible in the installed base of digital set-tops. Then, you divide the writing job into manageable chunks and start coding. Maybe you write the application in Java, or Perl, or PHP or C++.

If a particular MSO wants to customize the “look and feel” of the way customers maneuver themselves to the on-demand links — that’s a custom port, too.

The ultimate answer, MSO technologists say, is OCAP. OCAP, or the “OpenCable Applications Platform,” is a subset of Cable Television Laboratories Inc.’s OpenCable effort. Its mission, in part, is to eliminate the need to rejigger applications each time something changes.

There are companies out there working on answers to the problem of having to write, and port, too many times for practicality. For MSOs, there’s the traditional “middleware” camp — Liberate and OpenTV and their (shrinking) ilk. For MSOs and content developers, there’s GoldPocket, which roots its work in the “ITV Production Standards Initiative” (more at, while adhering to OCAP.

ITV developers at the programming networks wish for OCAP, too. And they wish for ways to find and talk with each other — about how to find answers, solve problems, think things through. They’re a community so small (about 50 people, at best) as to consider themselves more R&D than rock 'n’ roll.

That will likely change. With every week Murdoch gets his vaunted “red button” closer to U.S. soil, cable gets more serious about its back-atchya. And it’s a back-atchya that’ll beg for smart software people.

The good news is, change is in the wind for the industry’s perennial underdog: Interactive TV. Granted, the “ITV” descriptor may never regain enough strength to shake off the taint of its many stumbles. But, its recent fruits (any of the on-demand categories, for example) are gaining favor.


An editing error in the March 8 edition of this column mischaracterized the $30 to $40 in additional cost of an E-MTA over a commodity-priced cable modem, as $30 to $40 in incremental revenue. Whether or not $30 to $40 in incremental revenue occurs depends on service-provider pricing for VoIP services.

Stumped by gibberish? Log on