Content Referencing In OCAP

where
<service> identifies an OCAP service
<component> identifies an OCAP component (an elementary stream, in DVB-speak) and
<event> identifies an event using its 14-bit event ID (given as a hexadecimal string)
<path> gives a path to a file in a broadcast carousel, following the same rules as for other URLs.

Things aren't quite as simple as I've made them appear here, so we'll look at some of these elements in more detail.

OCAP services

A DVB service is identified using the triplet <original network ID>.<transport stream ID>.<service ID>. ATSC-based systems such as OCAP don't support this representation, due to differences in the way that service information is transmitted and what it contains. Instead, a number of different text representations can be used for OCAP services. The simplest of these is a non-zero 16-bit hex value (usually non-zero) which corresponds to the source_id field carried in the Virtual Channel Table of ATSC service information. This uniquely identifies that service across the entire system.

There are also a more human-readable way to identify a service. This uses a textual name that corresponds to the source_name field defined in the ANSI/SCTE 65 standard and which is carried in the PSIP information. The exact encoding of this string is complex, since it's a Unicode string, and so the terminally curious can look in the standards document for the complete details. To use this, the locatur uses the format n=<source_name>

In some cases, a service may not have PSIP associated with it. In this case, we can specify the service by identifying the frequency of the transport stream that contains it (and optionally the modulation format), as well as the program number. In this case, we use the format f=<frequency>.<program_number> to identify the service. optionally, we can append the string .m=<modulation_format> to identify the modulation format that is used for that transprt stream.

None of these approaches works very well for services that are transmitted out-of-band, however, and so the notation oobfdc.<program_number> is used to identify services that are transmitted over the out-of-band forward data channel of the CableCARD interface.

The examples below illustrate these different ways of representing a service:

Service components

If you thought that services were complex, just wait until you have to deal with service components. In DVB, a component of a service is defined by a component tag. As for services, OCAP instead uses several different ways of identifying a service. Component tags are one of these ways, and they can be specified in an OCAP locator using the syntax @<component_tag>. As in DVB services, the component tag is a hexadecimal number.

The second way to specify a service component is by using the component name. This is similar ot a component tag, but uses a textual name to identify the component. The syntax $<component_name> is used to specify these in an OCAP locator.

Alternatively, we can specify a particular type of stream - for instance a stream containing closed caption information. These are probably the default way of identifying a service component in OCAP locators, and are specified simply by the hexadecimal number that represents the stream type as given in the ANSI/SCTE 57 specification.

If the service contains several streams of the same type (such as audio or subtitles) then there are two ways of identifying a specific stream. A locator can contain a three-letter language code, as defined in ISO 639-2. If this is used, then the locator refers to the first stream of the specified type that matches that language. This is no use in all cases, however. What if you have two audio tracks in the same language for instance (e.g. audio tracks for a movie with and without commentary from the director), or what about video tracks which have no language setting? In this case, the locator can contain a hex string that represents an index into the PMT giving the stream in question (starting at index 0, and counting only those streams of the given stream type). Examples of how these are specified are given in the table below.

As if this was not enough, we can also identify a service component by its PID, using the syntax +<PID>, where the PID is given as a hexadecimal value.

In many cases, we want to identify more than one service component in the same locator. This is only possible if we use the same representation for all service components - if we want to identify one service component using its PID, we must also identify other service components using their PIDs. To specify multiple service components, we simply separate each specifier by an ampersand (&) , for instance +<PID>&<PID>&<PID>.

The table below shows some example URLs that identify different service components:

More information about the syntax of the ocap:// locator and how to use it are given in section 16.2.1.1 of the OCAP specification.

Locators for files in an object carousel

This content type is pretty straightforward, and should be familiar to most developers. It's simply a reference to a file in a DSM-CC object carousel. In OCAP and MHP, this is often used when dealing with JMF to refer to a piece of MPEG-1 audio that is loaded from a file. To refer to the file, we use a standard file:// URL - this makes things slightly simpler conceptually, but it does mean that the file must reside on a DSM-CC object carousel that the receiver is already connected to.

As with any file:// URL, we need to use the full path name. In OCAP, this gets interesting because we don't know where the receiver will mount a given object carousel in its filesystem. In order to successfully (and interoperably) find the correct URL for a file in a DSM-CC object carousel, it's necessary to get this from the file itself:

// Create a DSM-CC object that refers to the file in the
// carousel. Note that this is a relative path name
// (relative to the application's root directory,
// usually).  In this case, it's an MPEG audio file.
DSMCCObject myDsmccObject;
myDsmccObject = new DSMCCObject(
  "my/file/path/filename.mpg");

// We can call getURL() on that object to get a file://
// URL that points to it
URL url = myDsmccObject.getURL()

// Now we can create the Locator
try {
  LocatorFactory locatorFactory =
    LocatorFactory.getInstance();
  Locator myLocator;
  myLocator =
    locatorFactory.createLocator(url.toString());
}
catch (MalformedLocatorException e)
{
  // Catch the exception in whatever way we see fit.
  // Since we should always get a valid URL from
  // getURL(), this exception should not get thrown in
  // this situation.
}

The locator that we get back from this will use a file:// URL of the correct type to refer to that file.

Locators for video 'drips'

This is a new content format that's pretty much unique to the digital TV world. The main aim of this format is to provide a memory-efficient way for displaying several similar images. Basically, it is a very short piece of MPEG-2 - the first thing in the file is an MPEG-2 I frame that can be decoded and presented to the user. This is followed by one or more P frames, which are then decoded based on the preceding I frame. This allows the decoder to update a static image in a very memory-efficient way.

In this format, the data is passed to the Java Media Framework via an array of bytes, so the content is already loaded from a file or other data source. Because of this, the format doesn't really have a locator that identifies the place the data is loaded from. A URL is still needed, though, to create locators and create the appropriate objects to decode this content format. For this reason, the entire URL, for every piece of video 'drip' content is

dripfeed://

Believe it or not, this is a valid URL, and this tells the locator what the content format is, but without needing to refer to a specific piece of data. We'll see more about how this works in the next section.

Locator classes

One of the biggest problems with locators in OCAP and MHP is the sheer variety of classes that implement them.  We have:

• javax.media.MediaLocator
• org.davic.media.MediaLocator
• javax.tv.locator.Locator
• org.davic.net.Locator
• org.ocap.net.OcapLocator

Each of these is used to refer to a piece of media content, but they are all used in subtly different ways. For instance, a javax.media.MediaLocator is used by the Java Media Framework to refer to a media clip that will be presented, and so this may refer to either an OCAP service (or service component), an audio clip or a video drip.

org.davic.net.Locator and its subclasses (including org.ocap.net.OcapLocator) are designed to refer to transport streams or services. javax.tv.locator.Locator is a more general locator defined by JavaTV that can refer to any piece of digital TV content (either a service, a transport stream or a file in a broadcast filesystem).

Given these different hierarchies of locators, there is a very real danger that using them in applications will be both complex and error-prone.  To help avoid this, the MHP standard mandates that some of these otherwise-unrelated classes will be related and these rules also apply in OCAP. MHP specifies that the org.davic.net.Locator class will implement the javax.tv.locator.Locator interface and that any instances of javax.tv.locator.Locator in an MHP or OCAP environment will actually be instances of org.davic.net.Locator, which removes a great deal of complexity from the use of locators.  JavaTV and DAVIC locators can be used interchangeably, leaving only JMF MediaLocator objects out of the picture.  

MediaLocators are taken care of via the org.davic.media.MediaLocator class.  While this is not related to org.davic.net.Locator via inheritance, it does include a constructor that takes an org.davic.net.Locator as an argument.  This allows applications to create MediaLocator objects directly from other locators, and thus integrates all of the different locator classes.  It is not possible to convert from a MediaLocator to an org.davic.net.Locator object (or to construct one directly from the other), this can be accomplished by using the external form of the MediaLocator to create an org.davic.net.Locator.

The diagram below shows the relationship between the various Locator classes:

Class hierarchy of the major locator classes.

Creating locators

Some of these locator types (javax.media.MediaLocator, org.davic.net.Locator and their subclasses) can be created directly from a URL. The org.davic.net.Locator class also has a number of other constructors that allow the various components of the locator to be specified directly. The exact nature of these components, and the URL formats for these locators are introduced in the next section.

Instances of javax.tv.locator.Locator, on the other hand, can only be created by using the javax.tv.locator.LocatorFactory class. This factory class provides the createLocator() method, which takes a URL of the same format as the previous locator classes.  Since org.davic.net.Locator implements the javax.tv.locator.Locator interface in an OCAP system, this means that OCAP applications can create a JavaTV locator in the same way that they can create a DAVIC locator, and vice versa.