TwinHan DTV SDK

This section explains the concept and architecture of Twinhan DTV SDK for windows. It describes how to use the SDK to receive, process, and render the DVB signals. Figure 3-2 is the whole frame of the Twinhan DVB-T PCI Card.

Figure 3-2 The Whole Frame

Twinhan DTV SDK provides COM objects and the interfaces that assist in demultiplexing, decoding, and other signal processing. Using Twinhan DTV SDK simplifies the signal processing procedure. Figure 3-3 illustrates the high-level architecture of the SDK. It is the procedure of rendering the source signals.

The SDK offers a DVB Source filter which should only be loaded through a graph manager which will handle all the pin connections and provide access to the different decoder interfaces. It has four output pins for “Stream 1”, “Transponder Stream”, “Analog Video”, and “VBI”. The connection format of “Stream 1” output

pin is MEDIATYPE_Stream/MEDIASUBTYPE_NULL. It works in the pull mode.

When it is working, the PES stream which only includes video and audio will flow out. In order to work properly, before connecting the output pin to the next filter, we should initialize the filter with the open interface. The connection format of another pin “Transpond Stream” is MEDIATYPE_Stream/MEDIASUBTYPE_MPEG2_

TRANSPORT, and it is working in the push mode. When it is active, the whole transport stream will flow out from it. The output pin “Analog Video” is designed for Analog Video. Its connection format is MEDIATYPE_Video/MEDIASUBTYPE_

RGBx and it use Source Stream as the output pin type. For the output pin “VBI”, the connection type is MEDIATYPE_VBI/MEDIASUBTYPE_VPVBI. It delivers a stream of VBI waveform samples.

Figure 3-3 The Graph Frame

The TS Splitter filter takes in the interleaved stream and outputs separate audio and video streams. It has 1 input pin and 2 output pins, one is for video, which supports MPEG2_Video; another is for audio, which supports MPEG1AudioPayload and AC3. If the stream includes AC3 audio, the connection format is DOLBY_AC3.

The DVB Time-Shift filter allows seeking and positioning in a previously encoded MPEG2 stream. The special functionality of the DVB Time-Shift filter

allows data seeking with real-time multiplexed streams. DVB Time-Shift filter has 1input pin and 1 output pin, it needs to be linked between the source filter and the splitter. User only controls the graph state for the time-shifting function, such as pause for enter time-shifting mode, play for playback in time-shifting mode and stop for exit.

Figure 3-4 The Filter Graph for Transponder Stream

Figure 3-4 is the Filter Graph for receiving a real-time DVB-T signal. Here we focus the DVB Source filter because all the filters in Figure 3-4 are provided by DirectShow except the Source Filter. For more information on these filters refer to DirectShow. The Source Filter will detect the card automatically and work well on this card. It supports more than one interface to allow user to:

y Change the transponder and other options, such as LNB.

y Lock the channel.

y Access to multi-card and support the media files (MPEG2 format) playback function.

y Read remote control code and turn on/off the tuner power.

Using the interface, the user can lock a channel, capture PES stream which includes video and audio streams, scan programs etc. This is achieved through some supported APIs as follows.

In order to play back programs, user must call two APIs, “LockChannel” and

“ScanCannel”, to lock and scan the channel that the user wants to play firstly, and then use the API “SetPid” to set the PID of video and audio for one program. When all are done, the stream will be ready and user can render the output pin to build the

whole graph. Besides these three APIs, there are also plenty of APIs supported to let the Source Filter more powerful.

Note that all the filters, such as demultiplexer, video and audio decoder need to be loaded in the graph prior to rendering graph. Because the formats of the video and audio may be distinct between different programs, it needs re-render the whole graph when changing channel in this frame now.

Chapter 4 MPEG-21 Rights Expression Language specification

In this chapter, we will briefly review the International Standard ISO/IEC

21000-5:2004, MPEG-21 Rights Expression Language [4] (called the MPEG REL for short). The ISO/IEC MPEG, Moving Picture Experts Group, committee started the development process for the MPEG REL in 2001 with a Call for Proposals and an evaluation process. After a few years of efforts, the Extensible Rights Markup Language (XrML) proposed by ContentGuard [5],was selected as the core architecture and base technology [6].

We will give an overview of the MPEG REL in terms of its objectives, data model, structure for extensibility and profiling, authorization model, and the relation with the other standards in MPEG-21.

4.1 Objectives [7]

The MPEG REL is an XML-based declarative language that can declare rights and conditions for authorized distribution and use of any content, resources, or services. It defines the syntax and semantics of a machine interpretable language that can be used to specify rights unambiguously.

The MPEG REL is intended to provide a flexible, interoperable mechanism to support transparent and augmented use of digital resources in publishing, distributing, and consuming digital content (including digital movies, digital music, electronic books, broadcasting, interactive games, computer software and other creations in digital form) in a way that protects digital content and honors the rights, conditions,

and fees specified for digital contents. It is also intended to support specifications of access and to control digital content usage in the cases where financial exchange is not part of the terms of use, and to support exchange of sensitive or private digital contents.

For protecting consumer privacy, the MPEG REL provides a flexible

interoperable mechanism to ensure personal data is processed in accordance with the individual rights and to meet the requirements for users to express their rights and interests in a way that addresses issues of privacy and use of personal data.

To support guaranteed end-to-end interoperability, consistency and reliability between different systems and services, the MPEG REL must offer richness and extensibility in declaring rights, conditions and obligations, ease and persistence in identifying and associating these with digital contents, and flexibility in supporting multiple usage/business models.

4.2 Data Model

The main function of the MPEG REL is to specify rights related to digital resources (such as content, services, or software applications). Using this language, anyone owning or distributing digital resources can identify

y The principals (such as users, groups, devices, and systems) who are authorized to use the resources

y The rights accorded to those principals

y The condition that must be met before the right can be exercised

Figure 4-1 An example of REL expression

For example, an E-book named “Why Cats Sleep and We don’t”, distributed by

“T Publisher”, to a consumer (Jane) that she is allowed to print 3 times. Figure 4-1 shows this simple REL example, Jane is granted the right to print the E-book “Why Cats Sleep and We don’t” 3 times under the permission of T Publisher, in its structural form.

Figure 4-2 Data model of license [6]

In the MPEG REL terminology, Jane is considered as a principal; print, a right;

E-book “Why Cats Sleep and We don’t”, a resource; 3 times, a condition; and T Publisher, an issuer of the right. This simple example above is consists of the essential elements and the relationship among those elements of the MPEG REL expression.

The expression conveys a statement of the following form: An issuer states that a principal has some right to a resource under some condition. The right-granting

portion of this statement is called a grant and the entire statement is called a license which contains both grants and issuers. In this example, the statement, Jane can print the E-book “Why Cats Sleep and We don’t” 3 times, is a grant; the statement, T publisher issues a grant that Jane can print the E-book “Why Cats Sleep and We don’t” 3 times, is a license.

The essential elements and the relationship among those elements of the MPEG REL are shown in Figure 4-2, the MPEG REL data model. The MPEG REL adopts a simple and extensible data model. In this data model, a license consists of one or more grants and issuers. And a grant contains four basic entities, including principal, right, resource, and condition. The roles of these elements of the MPEG REL data model will explained in detail in the following sections:

4.2.1 License

A license is a key top-level construct in the MPEG REL. It is a container of grants, issuers, and some other information. Conceptually, a license is a collection of grants issued by one or more issuers.

4.2.2 Grant

A grant is the element within the license that essentially conveys to a principal the right to use a resource, possibly subject to certain conditions.

4.2.3 Principal

MPEG REL provides the principal element that encapsulates the identification of a party to whom a right is granted. Each principal identifies exactly one party. In

Principal is typically identified by using information unique to that entity, which often includes an associated authentication mechanism by which the Principal can prove its identity. For example, an X.509 certificate is one of an authentication proof.

To support identification, the following technologies are provided: 1) a principal must present multiple credentials, all of which must be simultaneously valid, to be authenticated; 3) a principal is a keyHolder, who is identified as possessing a secret key such as the private key of a public / private key pair. 3) Other identification methods that may be invented by others.

The following figure shows an example: the principal Jane is represented by using the keyHolder element.

Figure 4-3 Jane is identified as the holder of a particular key 4.2.4 Right

A right is the "verb" that a principal can be granted to exercise against some resources under certain conditions. Typically, a right specifies an action (or activity) or a class of actions that a principal may perform on or use the associated resource.

A right element within a grant encapsulates information about rights and provides a set of commonly used, specific rights, such as play, print and adapt, as well as notably rights relating to other rights, such as issue, revoke and obtain.

The following figure illustrates how the print right would appear in a license. In this figure, the prefix mx: indicates that the print right is defined in the MPEG media extension schema namespace that will be introduced in section 4.3.

Figure 4-4 The print right 4.2.5 Resource

A resource is the "object" to which a principal can be granted a right. A resource can be a digital work (such as an e-book, an audio or video file, or an image), a service (such as an email service, or B2B transaction service), or even a piece of information that can be owned by a principal (such as a name or an email address). A grant can also be a resource.

MPEG REL provides a resource element that encapsulates the information necessary to identify and assign Rights to a particular Resource. In particular, it provides a variety of pattern mechanisms to allow identification of a collection of resources with some common characteristics. Extensions to these mechanisms define Resources appropriate to specific business models. The following figure illustrates that an e-Book is identified as a digitalResource with a particular URI.

Figure 4-5 An E-book is represented as a digitalResource with a URI

4.2.6 Condition

A condition specifies the terms, conditions and obligations under which rights can be exercised. A simple condition is a time interval within which a right can be exercised. A slightly complicated condition is to require the existence of a valid, prerequisite right that has been issued by some trusted entity. Using this mechanism, the eligibility to exercise one right can be dependent on the eligibility to exercise other rights.

MPEG REL defines a condition element that encapsulates the information necessary to determine whether the condition is met. Figure 4-7 presents constraint condition that identifies a right may be exercised only 3 times. The prefix sx: in this figure indicates that the elements (exerciseLimit and count) are defined in the MPEG standard extension schema namespace that will be introduced in section 4.3.

Figure 4-6 A constraint condition 4.2.7 Issuer

The issuer element identifies a license issuer who digitally signs a license and provides additional details about its issuance. By signing the license, a license issuer authorizes the grants contained in a license and it can facilitate reliable establishment of trustworthiness of the license.

A license may have any number of issuers, or the element may be omitted entirely. However, no additional semantics is associated with the joint signing; it is as

if each had signed a copy of the License independently. No collective meaning is implied by several issuer elements appearing in a license.

The following figure illustrates how this issuer information is represented in the MPEG REL expression.

Figure 4-7 Issuer

4.3 Extensibility and Profiling

MPEG recognizes that different applications require different levels of

complexity and flexibility in REL and that specific industries and user communities may need to modify the language to better meet their specific needs. To facilitate easy mapping of the REL to these industry-specific applications, MPEG has developed a process of extending and profiling of the language. [8]

The extension process, including developing new verbs and schematic elements, enables individuals to define new elements specific to their requirements to improve efficiency in a specific domain. The syntax of MPEG REL is defined using the XML Schema and Namespace Recommendations by W3C [9],[10], which enables the REL to offer a high degree of richness and flexibility in its extensibility. The following figure illustrates the MPEG REL architecture.

Figure 4-8 Extensibility structure.

These architectural parts: core, standard extension, multimedia extension, and their XML schemas are normative components of the overall MPEG REL

specification.

Core schema defines the general constructs which are essential and form the architectural basis for the language. The namespace for the MPEG REL Core is identified with the prefix “r:”. In some cases, this prefix is omitted.

Standard extension schema defines the concepts that are generally and broadly applicable to the DRM usage scenarios. It extends the condition type in the XrML core. The namespace for the MPEG REL standard extension is identified with the prefix “sx:”. Figure 4-6 is a simple example.

Multimedia extension schema extends the Core schema for concepts (e.g., rights, resources, and conditions) specifically related to the multimedia domain. As shown in Figure 4-4, the namespace for the MPEG REL multimedia extension is identified with the prefix “mx:”.

The extension process enables that the other parties can define their own (possibly domain-specific) extensions to the MPEG REL and its future extensions.

This is accomplished by using the existing, standard XML Schema and XML

Namespace mechanisms. More specifically, extensions to the MPEG REL can define:

1) principals appropriate to specific technical applications; 2) rights appropriate to using specific types of resource, such as play and print; 3) resources appropriate to specific business models and technical applications; 4) conditions appropriate to specific distribution and usage models, such as watermark, destination, and rendering application.

The profile process enables individuals to select only those language elements required to meet a specific application’s need. Many MPEG REL elements and attributes are optional, and their occurrences can be included or omitted in a profile to optimize payload of digital items and computation requirements of MPEG terminals.

For a specific purpose or different devices, this involves the creation of a subset of the language. For instance, the full power of the MPEG REL, which is required by a PC, may not be available for a mobile phone. So a down-size version of this language, a new profile, can be created for this application.

Extension and Profile can be used concurrently to optimize the applicability of the MPEG REL to one specific application.

4.4 Authorization Model

Figure 4-9 Authorization model [4]

The MPEG REL provides an authorization model, as shown in Figure 4-9, to determine if a principal has the right to perform an action on a resource according to the REL expressions in a set of licenses.

The authorization model makes use of an authorization request, an authorization story, authorization context, and an authorizer to create authorization proofs, which define the semantics of licenses for performing authorization requests. Figure 4-10 illustrates the relationship between the entities in the authorization model. An authorization request is permitted if there is one authorization story that provides an authorization proof for the request.

Figure 4-10 The relationships between the entities in the authorization model [11]

Authorization Request

An authorization request contains the information that conceptually represents the question "is it permitted for a given Principal to perform a given Right upon a given Resource during a given time interval based on a given authorization context, a given set of Licenses, and a given trust root?"

Authorization Story

An authorization story is a structure created for the purpose of finding a grant to match the requested permission. An authorization story contains:

y A primitive grant containing no variables, derived from a grant that is authorized by an authorizer and is a part of the set of licenses provided in the authorization request.

y Optionally, an authorizer is a structure containing the information about issuance of the License.

Conceptually, an authorization story contains all the information necessary to state the following fact: “A given primitive grant (i.e., a grant with no variables) may be derived from a given grant authorized by a given authorizer, which identifies a principal from a license at a time instant based on an authorization context and supported by an authorization story.”

Authorization Context

An authorization context is a set of properties that are relevant to an authorization request. A property refers to a truth statement that is used in the evaluation of a Condition. A Condition, which is evaluated based on some authorization context properties, refers to those properties in its semantics. [11]

Authorization Proof

If all the relationships shown by the broken lines are valid in Figure 4-10, an authorization story is said to be an authorization proof for an authorization request.

More specifically, the request is permitted if the following are true: 1) the primitive grant in the story is equal to the principal, right, and resource in the request and its condition is satisfied with the authorization context in the request; 2) the primitive grant must be derived from the grant; 3) the issuance of the grant in the first

authorization story is recursively authorized via an additional authorization story in

the authorizer in the first authorization story; 4) the recursive authorization eventually terminates in one of the trust roots given in the authorization request. [6] When the request is permitted, there shall be at least one authorization story that supports an authorization proof for the authorization request.

4.5 The Relation with The Other standards in MPEG-21

The MPEG-21 REL [4] can declare rights and permissions using the terms as defined in the Rights Data Dictionary (RDD) [12]. The RDD specifies a dictionary of terms and provides a methodology for extending the dictionary to include new terms.

The MPEG REL also can use the Digital Item Identification (DII) [13] to identify digital items described in the language defined by the Digital Item Declaration (DID) [14] and hence specify rights over those digital items. The MPEG REL can also be included in digital item declarations. [6]

Chapter 5 Application Exapmples of the DRM system

In this chapter, we describe our implementations of DRM systems in which we use rights expression languages (REL) to implement an effective digital rights

In this chapter, we describe our implementations of DRM systems in which we use rights expression languages (REL) to implement an effective digital rights