A freshly adopted digital-television standard, devised for the terrestrial broadcast of interactive material, is advancing on the periphery of cable's DTV landscape.
It's called "DASE," for "DTV Applications Software Environment." Spoken, "DASE" sounds like "days" — or "daze," as the quip goes. It hails from the Advanced Television Systems Committee, which sets broadcast standards.
DASE matters because it is similar in intent — but different in detail — from cable's specification for the software needed to run interactive applications. Cable's version is called "OCAP," for "OpenCable Applications Platform."
The people who worry about things like DASE express it this way: What if a broadcaster were to pass a DASE-based interactive application through to an OCAP-based set-top — or to a future TV with OCAP built in — and OCAP couldn't recognize it? Uh-oh.
Such incompatibility is particularly worrisome when imagined as a mandated part of any must-carry rules that may be in the works. (This hasn't happened, nor has anything occurred that portends that outcome. But worriers worry for a reason: To anticipate the worst, so that they're prepared if it happens.)
How they differ
How big are the differences between DASE and OCAP? Considerable, but not insurmountable, experts on the subject say. For starters, broadcast ITV is inherently one-way. A clickable thing slips into a show and is sent out over the air, or funneled into the cable-distribution network. At the house, DASE software inside the TV figures out what to do with it. End of story, at least in the first version of the standard.
OCAP, by comparison, is inherently two-way, because cable's distribution network is (in most cases) two-way. Manipulating an on-demand program means passing the clicks intended to pause, fast forward or rewind that show, up the network, to the server that holds the program.
Because of that, OCAP was designed to support a two-way environment, which is managed by a "monitor application" (translated in the Sept. 2 edition of Multichannel News).
There are also structural differences between the two endeavors, and that requires some background. OCAP is heavily reliant on the work of the Europeans, who organized themselves into a group called "DVB," for "Digital Video Broadcast," and who successfully promulgated a software standard called "MHP," for "Multimedia Home Platform" (translated in the Nov. 19 edition).
MHP, in turn, is largely based on Sun Microsystems Inc.'s Java software.
DASE happens to also rely on Sun's software, but it doesn't always do so in the same way as OCAP or MHP. Summary: OCAP and MHP (read: the U.S. and Europe) are largely aligned, technologically; DASE, as yet, is not.
API distinctions
Many of the structural differences between DASE and OCAP are in the applications program interfaces, or "APIs" — the software toolkits used by computer programmers to write the code that becomes the clickable, interactive thing.
There are roughly 10 APIs that differ between DASE and MHP, and thus between DASE and OCAP.
The details of the differing APIs are, predictably, intricate. In some cases, MHP includes APIs that DASE doesn't, but perhaps should.
The API named "org.davic.mpeg," for example, exists within the MHP standard, but not yet within DASE. It describes how to pull packets from an MPEG-2 video stream for use within teletext-style applications.
Some say that standards don't have to be identical from one industry to the next. Others say the cry for unity is often more like a cloak, hiding a desire for control.
Either way, alignment around important areas of functionality is usually useful to everyone involved. Everyone, in this case, is cable, broadcasters, and consumer electronics manufacturers, at a minimum.
The good news: A harmonization effort is in the works. It's called "GEM," for "Globally Executable MHP." GEM is the brainchild of the "MHP Umbrella Group," which, as you can guess, goes by "MUG."
GEM of a patch
In an almost unforgivable simplification, GEM, in intent, is sort of a software equivalent to duct tape, or WD-40 — which can variously stick or unstick just about anything.
GEM began as a way to handle the inherent differences between U.S. and European digital-video applications. Specifically, it started as a way to connect the dots that needed connecting between MHP and OCAP. Involved technologists suggest that GEM could also be put to work on DASE.
Hopefully, this will happen while DASE is still on cable's periphery and not turn into a big, ugly mess. Cable and broadcast already went with differing digital modulation techniques — VSB (vestigial sideband) for the broadcasters, QAM (quadrature amplitude modulation) for cable. It wasn't the end of the world, but it created kinks in signal flow.
For those of us on the sidelines, then, it's probably useful to hope that MUG's GEM takes the daze of out DASE.
