Design und Prototyp-Implementierung einer MPEG-21 Digital Item … · 2004-02-18 · Das MPEG-21...

Michael Ransburg

Design und Prototyp-Implementierung

einer MPEG-21 Digital Item

Adaptation Engine

DIPLOMARBEIT

zur Erlangung des akademischen Grades

Diplomingenieur

Angewandte Informatik

Universität Klagenfurt

Fakultät für Wirtschaftswissenschaften und Informatik

Begutachter: Univ.-Prof. DI Dr. Hermann Hellwagner

Institut: Informationstechnologie

27. Oktober 2003

Ehrenwörtliche Erklärung [ii]

Ehrenwörtliche Erklärung

Ich erkläre ehrenwörtlich, dass ich die vorliegende Schrift verfasst und die mit ihr

unmittelbar verbundenen Arbeiten selbst durchgeführt habe. Die in der Schrift

verwendete Literatur sowie das Ausmaß der mir im gesamten Arbeitsvorgang

gewährten Unterstützung sind ausnahmslos angegeben. Die Schrift ist noch keiner

anderen Prüfungsbehörde vorgelegt worden.

(Michael Ransburg)

(Klagenfurt, am 27. Oktober 2003)

Danksagung [iii]

Danksagung

Mein persönlicher Dank gilt in erster Linie meinen Eltern, die mir dieses Studium

ermöglicht und mich auch während des Studiums unterstützt haben. Des Weiteren

möchte ich mich bei Herrn Professor Hellwagner bedanken, der mir ermöglicht hat,

mich in meiner Diplomarbeit mit diesem interessanten Thema zu befassen. Vielen

Dank auch an Christian für die Betreuung dieser Diplomarbeit und für den regen

Gedankenaustausch während der Diplomarbeit. Abschließend möchte ich mich noch

bei meinen Studienkollegen und Freunden bedanken, mit denen ich viele schöne

Momente während des Studiums verbracht habe.

Abstract [iv]

Abstract

From the beginning the internet has been used as a way to exchange information.

While mainly textual documents were exchanged at first, this changed very quickly

with the growth of the internet. Nowadays, one can get all types of information from

the internet, including pictures, music and even whole movies.

But not only the variety of information changed with the growth of the internet.

Nowadays all kinds of devices are connected to the internet. While many of them are

personal computers (PCs), it is nothing spectacular anymore to see personal digital

assistants (PDAs) or even mobile phones which are connected to the internet.

With the large variety of both information and terminal types new problems are

encountered as well. One cannot expect anymore, that information can be displayed

on all terminals without problems. While a PC won’t have many problems to display

a video in DVD quality, a mobile phone will struggle to display this kind of

information. It will have to adapt the video, before it can be shown on its small

display and with its weak processor. Ideally this adaptation should happen

automatically and transparent to the user, which is exactly what the Moving Picture

Experts Group (MPEG) is currently trying to achieve with their MPEG-21 standard.

This diploma thesis gives an overview of the MPEG-21 multimedia framework and

explains its key areas. After that, the adaptation of resources and their descriptions

(which are the main parts of a digital item) is closely looked at. After exploring the

theoretical foundation of adaptation within the multimedia framework, a prototype

for a digital item adaptation engine (DIA Engine) is designed and implemented. The

last chapter evaluates the prototype using different adaptation experiments. The

thesis concludes with a discussion of areas which still need to be worked on and

takes a look at how the multimedia framework as a whole could work.

Zusammenfassung [v]

Zusammenfassung

Das Internet wurde schon seit jeher zum Austausch von Informationen verwendet.

Zu Beginn wurden mit Hilfe von Newsgroups vorrangig Informationen in textueller

Form verbreitet. Mit dem schnellen Wachstum des Internet und der damit

verbundenen Erhöhung der verfügbaren Bandbreite fanden nicht mehr ausschließlich

textuelle Informationen Verbreitung im Internet. Bilder, Musik und in letzter Zeit

sogar ganze Filme sind heutzutage im Internet abrufbar.

Gleichzeitig wächst die Vielfalt der an das Internet angeschlossenen Endgeräte.

Obwohl es sich bei der Mehrheit der Endgeräte immer noch um Personal Computer

(PCs) handelt, werden auch immer öfter Alternativen, wie beispielsweise Personal

Digital Assistents (PDAs) oder Handys, verwendet.

Mit der Vielfalt der verwendeten Endgeräte und der übertragenen Informationen

ergeben sich neue Probleme. Da sich die verschiedenen Endgeräte von ihren

Systemeigenschaften her sehr unterscheiden, kann man nicht mehr davon ausgehen,

dass jede Information auf jedem Endgerät ohne weiteres darstellbar ist. Das Endgerät

muss die Informationen erst in ein passendes Format bringen, bevor es sie darstellen

kann. Dieser Vorgang wird als Adaptierung bezeichnet. Ideal wäre es, wenn ein User

unabhängig vom verwendeten Endgerät und dem Netzwerk auf Multimedia-Dateien

zugreifen könnte. Genau dies ist das Ziel des MPEG-21 Multimedia-Frameworks, an

dessen Standardisierung die Moving Picture Experts Group (MPEG) derzeit arbeitet.

Die Diplomarbeit gibt einen Überblick über das MPEG-21 Multimedia-Framework

und beschreibt dessen Kernbereiche. Anschließend wird auf die Adaptierung von

Ressourcen und deren Beschreibungen (die Hauptbestandteile eines Digital Items)

im Multimedia-Framework eingegangen. Basierend auf den erarbeiteten

theoretischen Grundlagen wird ein Prototyp einer Digital Item Adaptation Engine

(DIA Engine) entworfen und implementiert. Abschließend wird die DIA Engine

anhand von Adaptierungsexperimenten evaluiert und eine mögliche Infrastruktur des

Multimedia-Frameworks diskutiert.

Inhaltsverzeichnis [vi]

Inhaltsverzeichnis

EHRENWÖRTLICHE ERKLÄRUNG ............................................................................................ II

DANKSAGUNG.................................................................................................................................III

ABSTRACT........................................................................................................................................ IV

ZUSAMMENFASSUNG .....................................................................................................................V

INHALTSVERZEICHNIS................................................................................................................ VI

1 EINLEITUNG............................................................................................................................. 1

1.1 ÜBERBLICK.......................................................................................................................... 1 1.2 WAS IST MPEG-21? ............................................................................................................ 2 1.3 GRUNDFUNKTIONALITÄTEN................................................................................................. 2

1.3.1 Erstellen von Digital Items............................................................................................. 3 1.3.2 Verändern von Digital Items .......................................................................................... 3 1.3.3 Anbieten von Digital Items............................................................................................. 3 1.3.4 Suche nach Digital Items................................................................................................ 3 1.3.5 Bezug von Digital Items ................................................................................................. 4 1.3.6 Automatische Anpassung von Digital Items................................................................... 4

2 DIE ARCHITEKTUR VON MPEG-21.................................................................................... 5

2.1 ENTITÄTEN .......................................................................................................................... 5 2.1.1 Digital Item .................................................................................................................... 6 2.1.2 User ................................................................................................................................ 6

2.2 KERNBEREICHE.................................................................................................................... 7 2.2.1 Digital Item Declaration ................................................................................................ 7 2.2.2 Digital Item Identification and Description ................................................................. 16 2.2.3 Content Handling and Usage....................................................................................... 18 2.2.4 Intellectual Property Management and Protection...................................................... 18 2.2.5 Terminals and Networks............................................................................................... 19 2.2.6 Content Representation ................................................................................................ 20 2.2.7 Event Reporting............................................................................................................ 21

3 DIGITAL ITEM ADAPTATION ........................................................................................... 22

3.1 ÜBERBLICK........................................................................................................................ 22 3.1.1 Transformierung der Beschreibung ............................................................................. 24

Inhaltsverzeichnis [vii]

3.1.2 Adaptierung der Ressource .......................................................................................... 24 3.1.3 Digital Item Adaptation Tools...................................................................................... 25 3.1.4 Der Adaptierungsprozess ............................................................................................. 26

3.2 USAGE ENVIRONMENT DESCRIPTION TOOLS ..................................................................... 27 3.2.1 User Characteristics .................................................................................................... 27 3.2.2 Terminal Capabilities................................................................................................... 38 3.2.3 Network Characteristics............................................................................................... 43 3.2.4 Natural Environment Characteristics .......................................................................... 44

3.3 DIGITAL ITEM RESOURCE ADAPTATION TOOLS ................................................................. 48 3.3.1 Beschreibung der Ressource ........................................................................................ 48 3.3.2 Bitstream Syntax Description Link............................................................................... 58 3.3.3 Terminal and Network Quality of Service .................................................................... 59 3.3.4 Metadata Adaptability.................................................................................................. 62

3.4 DIGITAL ITEM DECLARATION ADAPTATION TOOLS ........................................................... 66 3.4.1 Session Mobility Tools ................................................................................................. 67 3.4.2 DIA Configuration Tools.............................................................................................. 70

4 DESIGN EINER DIA ENGINE .............................................................................................. 71

4.1 ÜBERBLICK........................................................................................................................ 71 4.2 ANFORDERUNGEN.............................................................................................................. 71

4.2.1 Grundsätzliche Funktionalität...................................................................................... 72 4.2.2 Modularität .................................................................................................................. 73 4.2.3 Anwendungsumfeld ...................................................................................................... 73

4.3 ENTWURFSALTERNATIVEN................................................................................................. 74 4.4 ENTWURF........................................................................................................................... 75

4.4.1 Parsen und Validieren des CDI ................................................................................... 75 4.4.2 Parsen und Validieren des XDI.................................................................................... 76 4.4.3 Generieren des XSLT Style-Sheets ............................................................................... 77 4.4.4 Transformieren der gBSD ............................................................................................ 78 4.4.5 Adaptieren der Resource.............................................................................................. 78 4.4.6 Generieren des adaptierten CDI .................................................................................. 79 4.4.7 Zusammenfassung des Adaptierungsprozesses ............................................................ 80

4.5 EVALUIERUNG DES DESIGNS.............................................................................................. 82

5 IMPLEMENTIERUNG ........................................................................................................... 83

5.1 PROJEKTVERLAUF.............................................................................................................. 83 5.2 INTERFACE-KLASSEN......................................................................................................... 88

5.2.1 CDIProcessor............................................................................................................... 90

Inhaltsverzeichnis [viii]

5.2.2 XDIProcessor ............................................................................................................... 90 5.2.3 XSLTProcessor............................................................................................................. 91 5.2.4 gBSDtoBin.................................................................................................................... 91 5.2.5 CDIGenerator .............................................................................................................. 92

5.3 EINE ERSTE IMPLEMENTIERUNG DER INTERFACE-KLASSEN ............................................... 92 5.3.1 CDIProcessorImp ........................................................................................................ 92 5.3.2 XDIProcessorImp......................................................................................................... 94 5.3.3 XSLTProcessorImp ...................................................................................................... 94 5.3.4 gBSDtoBinImp.............................................................................................................. 94 5.3.5 CDIGeneratorImp ........................................................................................................ 95 5.3.6 DIAEngineWrapper...................................................................................................... 95 5.3.7 DIAEngineParameters ................................................................................................. 96

5.4 ENTWICKLUNGSSTAND ...................................................................................................... 96

6 EVALUIERUNG DES PROTOTYPEN................................................................................. 98

6.1 ADAPTIERUNG DER AUFLÖSUNG........................................................................................ 98 6.2 ADAPTIERUNG DER FARBTIEFE ........................................................................................ 103 6.3 ADAPTIERUNG EINES VIDEOS........................................................................................... 108 6.4 WEITERE EXPERIMENTE................................................................................................... 111 6.5 DISKUSSION ..................................................................................................................... 112

7 SCHLUSSFOLGERUNGEN................................................................................................. 117

8 LITERATURVERZEICHNIS............................................................................................... 119

9 ABBILDUNGS-VERZEICHNIS........................................................................................... 125

10 ANHANG ................................................................................................................................ 129

10.1 INTERFACES ..................................................................................................................... 129 10.1.1 CDIProcessor ........................................................................................................ 129 10.1.2 XDIProcessor ........................................................................................................ 130 10.1.3 XSLTProcessor ...................................................................................................... 130 10.1.4 gBSDtoBin ............................................................................................................. 131 10.1.5 CDIGenerator ....................................................................................................... 132

Einleitung

1

1 Einleitung

Dieser Abschnitt gibt zuerst einen Überblick über die Diplomarbeit und schildert

kurz die Ergebnisse. Danach werden kurz das Umfeld von MPEG-21 betrachtet und

die Grundfunktionalitäten des MPEG-21 Multimedia-Frameworks erklärt.

1.1 Überblick

Im Abschnitt 1 wird in das Thema eingeführt. Es wird beschrieben, was MPEG und

MPEG-21 sind und wo die Grundfunktionalitäten des MPEG-21 Multimedia-

Frameworks liegen. Anschließend wird die Architektur des MPEG-21 Multimedia-

Frameworks beschrieben. Die Grundentitäten des Frameworks (Digital Item, User

und Ressource) werden erläutert und die Kernbereiche werden betrachtet. Auf die

Digital Item Declaration wird besonders genau eingegangen, da sie den Aufbau von

Digital Items bestimmt und somit essentiell für das Verständnis der folgenden

Abschnitte ist. Nach diesen einführenden Abschnitten wird in Abschnitt 3 auf die

Adaptierung im Multimedia-Framework eingegangen, die der Kernbereich der

Diplomarbeit und auch die Basis für die Entwicklung der Digital Item Adaptation

Engine (DIA Engine) ist. Es wird zuerst ein Überblick über den Adaptierungsprozess

gegeben, und im Anschluss werden die Adaptierungstools, die bei der Adaptierung

helfen sollen, genau betrachtet.

Aufgrund der im Standard vorgegebenen Anforderungen und eigener Design-

Entscheidungen wurde ein Prototyp einer DIA Engine entwickelt. Er ermöglicht die

Einleitung

2

Adaptierung von Digital Items, mit Hilfe einer generischen XML-Beschreibung der

im Digital Item enthaltenen Ressource und Zusatzinformationen über den User, das

Endgerät und das Netzwerk. In Abschnitt 3 wird auf das Design der DIA Engine

eingegangen. Anschließend wird die Implementierung genau betrachtet und die DIA

Engine wird anhand von Adaptierungsexperimenten evaluiert (Abschnitt 6).

Abschließend werden die offenen Punkte des Prototypen und mögliche

Infrastrukturen des Multimedia-Frameworks diskutiert.

Der Prototyp der DIA Engine kann am Server, am Client oder auf einem

Multimedia-Router eingesetzt werden. Er ermöglicht eine rasche Adaptierung von

Digital Items aufgrund der Rahmenbedingungen des Users, des Endgerätes und des

Netzwerkes. Mit Hilfe der DIA Engine können Digital Items an den User, das

Endgerät und das Netzwerk angepasst werden.

1.2 Was ist MPEG-21?

MPEG-21 [9] ist der fünfte Standard der Moving Pictures Experts Group (MPEG)

[1]. Während es sich bei MPEG-1 [2], MPEG-2 [3] und MPEG-4 [4] um reine

Codec-Standardisierungen handelt, ging man mit MPEG-7 [7] in eine andere

Richtung. MPEG-7 spezifiziert keinen Codec, sondern ist ein Beschreibungsstandard

für Multimedia-Daten. Mit MPEG-21 will man nun ein „Multimedia-Framework“

schaffen, welches das Tauschen von Digital Items benutzerfreundlich und legal

macht [9]. Ein Digital Item ist die grundlegende Entität zur Verteilung von

Informationen im Multimedia-Framework. Es ist eine Zusammenfassung von

Ressourcen (z.B. ein Video) und Meta-Informationen (eine Beschreibung der

Ressource). Die Begriffe Digital Item, User und Ressource werden in Abschnitt 2.1

noch näher beschrieben.

1.3 Grundfunktionalitäten

Das MPEG-21 Multimedia-Framework bietet dem User sechs Grundfunktionalitäten

[10]. Man kann Digital Items erstellen, verändern, anbieten, konsumieren und

Einleitung

3

suchen. Außerdem unterstützt das Multimedia-Framework die automatische An-

passung der Digital Items an Einschränkungen des Users, des Endgerätes und des

Netzwerks.

1.3.1 Erstellen von Digital Items

Es soll möglich sein, aus einer beliebigen Ressource ein Digital Item zu erstellen.

Hierzu werden zur Ressource beschreibende Meta-Informationen hinzugefügt. Diese

Meta-Informationen werden unter anderem benutzt, um eine effiziente Suche nach

Digital Items zu ermöglichen. Außerdem soll gewährleistet werden, bestehende

Digital Items (oder dessen Elemente) durch Verlinkung in ein Digital Item ein-

zubinden. Somit kann auch ein verteiltes Digital Item erstellt werden.

1.3.2 Verändern von Digital Items

Es soll möglich sein, Elemente aus Digital Items zu löschen und zu ihnen

hinzuzufügen. Außerdem soll ein Digital Item mit einem anderen Digital Item (oder

Elementen von diesem) verlinkt werden können.

1.3.3 Anbieten von Digital Items

Jedes Digital Item kann mit Rechten versehen werden. Diese legen fest, von wem

und auf welche Art Digital Items benutzt werden dürfen. Es gibt verschiedene Arten

der Nutzungsbefugnis. Es macht beispielsweise einen großen Unterschied, ob man

ein Lied nur anhören darf, ob man eine Kopie davon machen darf oder ob man es

sogar weitergeben bzw. weiterverkaufen darf. Die Nutzungsbedingungen werden

anhand der Rechte festgelegt.

1.3.4 Suche nach Digital Items

Es ist möglich, anhand der Meta-Informationen nach einem bestimmten Digital Item

zu suchen. Nach welchen Informationen man suchen kann, hängt von der Art des

Digital Items und von der Verfügbarkeit der Meta-Informationen ab.

Einleitung

4

1.3.5 Bezug von Digital Items

Je nach Art der gewünschten Nutzung kann es kostenpflichtig oder kostenlos sein,

eine bestimmte Nutzungserlaubnis für ein Digital Item zu erhalten. Ein User kann

sich beispielsweise auf der Internet-Seite eines Service-Providers eine bestimmte

Nutzungserlaubnis für ein Digital Item kaufen, um es anschließend gemäß der

erworbenen Nutzungsrechte zu benutzen.

1.3.6 Automatische Anpassung von Digital Items

Digital Items sollen je nach Endgerät bzw. Netzwerk automatisch angepasst werden

können. Vor Nutzungsbeginn des Digital Items kann der User bereits auswählen,

welche Qualität er wünscht, beispielsweise die Bitrate bei einem Musikstück. Es

kann jedoch vorkommen, dass sich z.B. Netzwerkbedingungen und/oder die Ver-

fügbarkeit von Ressourcen am Endgerät während des Abspielens ändern. In so einem

Fall kann dann automatisch eine dynamische Anpassung erfolgen. Wird bei der

Wiedergabe eines Videos beispielsweise bemerkt, dass die Datenrate zu hoch für das

Endgerät wird, kann begonnen werden, Frames des Videos auszulassen. Dies kann

der Fall sein, wenn während der Wiedergabe noch weitere Programme gestartet

werden, die zusätzlich Ressourcen benötigen.

Die Architektur von MPEG-21

5

2 Die Architektur von MPEG-21

Die Architektur des Multimedia-Frameworks kann aus zwei Blickwinkeln betrachtet

werden: einerseits in Bezug auf die grundlegenden Entitäten, die im Multimedia-

Framework agieren, andererseits in Bezug auf die Funktionalität, die es anbieten soll.

Im MPEG-21 Multimedia-Framework gibt es zwei grundlegende Entitäten. Das

„Digital Item“ ist die fundamentale Entität zur Verteilung von Informationen. Die

zweite Entität ist der „User“, der daran interessiert ist, diese Digital Items zu er-

stellen, zu verändern, sie anzubieten, nach ihnen zu suchen oder sie auf sonstige Art

zu manipulieren oder konsumieren [10].

Außerdem wird das Multimedia-Framework in sieben Kernbereiche unterteilt, die

die verschiedenen Anforderungen an die Funktionalität des Multimedia-Frameworks

beschreiben.

2.1 Entitäten

Die grundlegenden Entitäten im Multimedia-Framework sind der User und das

Digital Item.


6

2.1.1 Digital Item

Ein Digital Item ist ein strukturiertes digitales Objekt. Es besteht aus einer oder

mehreren Ressource(n) und deren Beschreibung. Das Digital Item ist die

fundamentale Entität zur Verteilung von Informationen im Multimedia-Framework.

Bei Ressourcen handelt es sich normalerweise um digitale Informationen, wie

beispielsweise Text, Bilder oder Videos. Jedoch können theoretisch auch physische

Objekte als Ressource auftreten. Ein Digital Item könnte beispielsweise auch eine

Beschreibung eines Hauses enthalten, welches durch seine Adresse referenziert wird.

Die Möglichkeiten zur Beschreibung von Digital Items sind so allgemein und

flexibel wie möglich gehalten, um neue Funktionalitäten einfach hinzufügen zu

können. Der Beschreibung von Digital Items ist ein eigener Kernbereich gewidmet

(siehe Abschnitt 2.2.1).

Außerdem sollen Digital Items im Multimedia-Framework eindeutig identifizierbar

sein. Auch hierfür ist ein eigener Kernbereich vorgesehen (siehe Abschnitt 2.2.2).

2.1.2 User

Jede Entität, die mit Digital Items interagiert, ist ein User. Beispiele dafür sind

Individuen, Organisationen, Firmen oder sogar Regierungen. MPEG-21 macht hier

keinen Unterschied zwischen Usern, die Digital Items anbieten (z.B. Service

Provider) oder konsumieren (z.B. Endbenutzer). Die User werden nur für die Dauer

einer Interaktion mit einem anderen User voneinander unterschieden. Grundlegend

kann man MPEG-21 also als ein Multimedia-Framework sehen, in dem ein User mit

einem anderen interagiert und das Objekt der Interaktion ein Digital Item ist.

Den Interaktionsmöglichkeiten ist ein weiterer Kernbereich gewidmet (siehe

Abschnitt 2.2.3). Zudem wird sichergestellt, dass die Rechte eines Users an Digital

Items gewahrt bleiben (siehe Abschnitt 2.2.4), dass der User die Digital Items immer

in bestmöglicher Qualität konsumieren kann (siehe Abschnitt 2.2.5 und 2.2.6) und


7

dass er immer über wichtige Vorgänge im Multimedia-Framework informiert wird


2.2 Kernbereiche

Das MPEG-21 Multimedia-Framework wird in sieben Kernbereiche unterteilt. Auf

diese wird im Folgenden näher eingegangen.

2.2.1 Digital Item Declaration

Die Beschreibung eines Digital Items basiert auf der „Extensible Markup Language“

(XML). In XML können so genannte Schemata definiert werden, die Regeln für die

Beschreibung festlegen (Syntax und Grammatik) [42]. Für die Digital Item

Declaration (DID) gibt es genau so ein Schema [19].

Abbildung 1 zeigt den grundlegenden Aufbau eines Digital Items, die einzelnen

Elemente werden im Anschluss näher erklärt.

Digital Item Declaration Language (DIDL)

Das DIDL-Element ist das Wurzel-Element einer DID. Es beinhaltet ein Container-

Element oder ein Item-Element und kann außerdem ein Declarations-Element

beinhalten. Im xmlns-Attribut des DIDL-Elementes wird auf den DIDL Namespace

verwiesen. Abbildung 2 zeigt ein Beispiel für das DIDL-Element.

Container

Ein Container-Element kann andere Container-Elemente oder Item-Elemente ent-

halten (siehe Abbildung 2).


8

Abbildung 1: Aufbau eines Digital Items, aus [9]

<DIDL xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS">

<Container>

<Item>

...

</Item>

<Container>

</DIDL>

Abbildung 2: DID Beispiel 1

Item


9

Ein Item–Element enthält Item-Elemente oder Component-Elemente, welche durch

Descriptor-Elemente beschrieben werden. Es kann außerdem ein Condition-Element,

ein Choice-Element oder ein Annotation-Element enthalten.

Abbildung 3 zeigt ein Beispiel für die Verwendung von Item-Elementen.

Component

Ein Component–Element enthält ein Resource-Element und beliebig viele Condition-

Elemente, Descriptor-Elemente und Anchor-Elemente (siehe Abbildung 3).

Resource

Eine Ressource ist ein beliebiges Datum, welches durch eine eindeutige Adresse

referenziert wird. Die Referenzierung erfolgt durch das ref-Attribut des Resource-

Elementes. Ein Resource-Element enthält außerdem ein mimeType-Attribut, welches

den Typ der Ressource angibt. Die möglichen Typen sind in Request for Comments

(RFC) 2045 [32] definiert.

Das Beispiel in Abbildung 3 beinhaltet zwei Resource-Elemente. Die erste

Ressource ist ein JPG-Bild (mimeType-Attribut), welches unter

„ftp://www.irgendwo.at/

castle.jpg“ zu finden ist (ref-Attribut). Bei der zweiten Ressource handelt es sich um

ein BMP-Bild, welches unter „http://www.irgendwoanders.at/girl.bmp“ zu finden ist.

Descriptor

Ein Descriptor-Element beschreibt sein Vater-Element. Es kann ein Reference-

Element, ein Component-Element oder ein Statement-Element enthalten.

Abbildung 3 zeigt ein Beispiel für die Verwendung des Descriptor-Elementes. Das

Beispiel zeigt ein Declarations-Element, welches ein Descriptor-Element mit einer

eindeutigen ID („photo_description“) enthält. Dieses Descriptor-Element besteht aus

einem Statement-Element mit einer textuellen Beschreibung. Anschließend sieht man

ein Item-Element welches zwei weitere Item-Elemente umfasst. Beide Sub-Items


10

beinhalten jeweils ein Descriptor-Element, das eine Referenz (Reference-Element)

auf das Descriptor-Element mit der ID „photo_description“ aufweist und auf diese

Art die beiden Sub-Items beschreibt.

Statement

Ein Statement-Element enthält beliebige Informationen, die das Vater-Element

beschreiben.

Abbildung 3 zeigt ein Beispiel für die Verwendung von Statement-Elementen

innerhalb eines Digital Items. Über das mimeType-Attribut kann angegeben werden,

welche Art von Information das Statement beinhaltet, beispielsweise Text („text/

plain“) oder XML („text/xml“). In RFC 2045 [32] werden die möglichen Typen

definiert.

Declarations

Das Declarations-Element kann ein Item-Element, ein Descriptor-Element, ein

Component-Element, ein Annotation-Element oder ein Anchor-Element enthalten.

Diese Elemente können innerhalb des Declarations-Elementes definiert und in-

nerhalb der DID referenziert werden. Dies ist z.B. sinnvoll, wenn zwei oder mehr

Elemente dieselbe Beschreibung erhalten sollen.

Abbildung 3 zeigt ein Beispiel für die Verwendung des Declarations-Elementes.

Dieses enthält in diesem Fall ein Descriptor-Element, dem eine eindeutige ID

zugewiesen ist („photo_description“). Dieses Descriptor-Element beinhaltet ein

Statement-Element mit einem beschreibenden Text (mimeType-Attribut). Neben

diesem Declarations-Element gehört ein Item-Element mit einer Beschreibung

(Descriptor-Element) und zwei Sub-Items zu diesem DID. Jedes der zwei Sub-Items

umfasst neben der Ressource (Resource-Element) inklusive Typ (mimeType-

Attribut) und Pfadangabe (ref-Attribut) ein Descriptor-Element. Dieses Descriptor-

Element verwendet nun das oben definierte Declarations-Element als Beschreibung

für das jeweilige Item-Element, indem es dieses mit Hilfe des Reference-Elementes

referenziert. Solange ein Declarations-Element nicht auf diese Weise referenziert


11

wird, wird es bei der Wiedergabe des Digital Item nicht berücksichtigt. In diesem

Beispiel kann durch die Verwendung des Declarations-Elementes Redundanz

vermieden werden, da der Beschreibungstext der Sub-Items nur einmal vorkommen

muss.

Reference

Das Reference-Element wird verwendet, um auf ein Anchor-Element, ein

Component-Element, ein Container-Element, ein Descriptor-Element, ein Item-

Element oder Annotation-Element zu verweisen, welches innerhalb eines

Declarations-Elementes definiert wurde.

Abbildung 3 verdeutlicht die Verwendung des Reference-Elementes. Im Beispiel

wird das Reference-Element zweimal verwendet, um auf eine Beschreibung zu

verweisen (target-Attribut), welche im Declarations-Element definiert wurde.

Anchor

Ein Anchor-Element dient dazu, einen Teil einer Ressource, welcher durch das

fragment-Attribut des Resource-Elementes angegeben wird, zu beschreiben.

Abbildung 4 zeigt ein Beispiel für die Verwendung des Anchor-Elementes. Die

Komponente (Component-Element) besteht aus einer Ressource, bei der es sich um

ein Video handelt (mimeType-Attribut des Resource-Elementes). Zwei Anchor-

Elemente verweisen auf dieses Resource-Element, wobei das erste eine höhere

Priorität (precedence-Attribut) als das zweite hat. Dies bedeutet, dass ein User-

Interface zuerst den gesamten Film („Complete Movie“) und dann erst eine

bestimmte Szene aus dem Film („Luke dies.“) darstellen würde. Die Szene wird

durch das fragment-Attribut bestimmt. Es enthält einen String, der beim Abspielen

des Videos mit einem Gitterzeichen an den Pfadnamen angehängt wird, im Beispiel

würde dies also „sw3.mpg#6000“ lauten. Die Software, die dann für das Abspielen

der Ressource verantwortlich ist, muss diesen Wert interpretieren können, im

aktuellen Beispiel könnte er beispielsweise bedeuten, dass die gewünschte Szene bei

Sekunde 6000 beginnt.


12


<Declarations>

<Descriptor id="photo_description">

<Statement mimeType="text/plain">

Photos from my holidays in Spain

</Statement>

</Descriptor>

</Declarations>

<Item>

<Descriptor>


Personal Photos

</Statement>

</Descriptor>

<Item>

<Descriptor>

<Reference target="#photo_description"/>

</Descriptor>

<Component>

<Resource ref="ftp://www.irgendwo.at/castle.jpg" mimeType="image/jpg"/>

</Component>

</Item>

<Item>

<Descriptor>

<Reference target="#photo_description"/>

</Descriptor>

<Component>

<Resource ref="http://www.irgendwoanders.at/girl.bmp" mimeType="image/bmp" />

</Component>

</Item>

</Item>

</DIDL>


Choice

Das Choice-Element enthält beliebig viele Condition-Elemente und beliebig viele

Descriptor-Elemente, mindestens aber ein Selection-Element.


13

Abbildung 5 veranschaulicht die Verwendung eines Choice-Elementes. Die Attribute

des Choice-Elementes geben an, wie viele Selektionen möglich bzw. erforderlich

sind (minSelections, maxSelections). Im Beispiel muss also genau eine Auswahl

getroffen werden, da sowohl minSelections als auch maxSelections auf „1“ gesetzt

wurden.


<Item>

<Component>

<Resource mimeType="video/mpeg" ref="sw3.mpg"/>

<Anchor precedence="200">

<Descriptor>

<Statement mimeType="text/plain">Complete Movie</Statement>

</Descriptor>

</Anchor>

<Anchor precedence="100" fragment="6000">

<Descriptor>


Luke dies.

</Statement>

</Descriptor>

</Anchor>

</Component>

</Item>

</DIDL>


Selection

Das Selection-Element enthält beliebig viele Condition-Elemente und Descriptor-

Elemente. Bei Selection-Elementen handelt es sich um Auswahlmöglichkeiten. Wird

ein Selection-Element ausgewählt, so wird das select_id-Attribut auf „true“ gesetzt

und kann durch Condition-Elemente überprüft werden.

Abbildung 5 zeigt ein Beispiel für die Verwendung des Selection-Elementes. Im

Beispiel ist ein Choice-Element mit zwei Selection-Elementen enthalten, von denen

eines ausgewählt werden muss. Je nachdem, ob das erste oder das zweite Element


14

ausgewählt wird, wird entweder das track1-Prädikat oder das track2-Prädikat auf

„true“ gesetzt (select_id-Attribut). Diese Prädikate werden dann im Condition-

Element überprüft.

Condition

Ein Condition-Element beinhaltet ein Element, welches optional ist und nur

verarbeitet wird, wenn das Prädikat im require-Attribut des Condition-Elementes

„true“ ist.

Abbildung 5 verdeutlicht die Verwendung des Condition-Elementes. Je nachdem, ob

das erste Selection-Element („Track 1“) oder das zweite Selection-Element („Track

2“) ausgewählt wurde, wird entweder die Ressource „track1.mp3“ oder „track2.mp3“

abgespielt.

Annotation

Ein Annotation-Element kann aus einem Reference-Element, einem Assertion-

Element, einem Descriptor-Element oder einem Anchor-Element bestehen. Ein

Annotation-Element referenziert auf ein Element im Digital Item und beschreibt oder

verändert es mit Hilfe der enthaltenen Elemente.

Abbildung 6 zeigt ein Beispiel für die Verwendung des Annotation-Elementes. In

diesem Fall referenziert es auf das Element mit der ID „music_album“, bei dem es

sich um ein Item-Element handelt.


15


<Item>

<Choice minSelections="1" maxSelections="1" choice_id="album">

<Descriptor>


Which track would you like to play?

</Statement>

</Descriptor>

<Selection select_id="track1">

<Descriptor>

<Statement mimeType="text/plain">Track 1</Statement>

</Descriptor>

</Selection>


<Descriptor>


</Descriptor>

</Selection>

</Choice>

<Component>

<Condition require="track1"/>

<Resource ref="track1.mp3" mimeType="audio/mp3"/>

</Component>

<Component>

<Condition require="track2"/>

<Resource ref="track2.mp3" mimeType="audio/mp3"/>

</Component>

</Item>

</DIDL>


Assertion

Mit Hilfe eines Assertion-Elementes kann man festlegen, welches Selection-Element

eines Choice-Elementes ausgewählt ist.

Abbildung 6 zeigt ein Beispiel für die Verwendung des Assertion-Elementes. Das

Annotation-Element referenziert auf das Item-Element mit der ID „music_album“

(target-Attribut). Das Assertion-Element referenziert dann auf das Choice-Element

mit der ID „album“ (target-Attribut) und legt fest, dass die zweite

Auswahlmöglichkeit gewählt sein soll (true-Attribut).


16


<Item id="music_album">

<Choice minSelections="1" maxSelections="1" choice_id="album">

<Descriptor>


Which track would you like to play?

</Statement>

</Descriptor>


<Descriptor>


</Descriptor>

</Selection>


<Descriptor>


</Descriptor>

</Selection>

</Choice>

<Annotation target="music_album">

<Assertion target="album" true="track2"/>

</Annotation>

</Item>

</DIDL>


2.2.2 Digital Item Identification and Description

Die Digital Item Identification (DII) hat zum Ziel, Digital Items oder Teile davon

eindeutig zu identifizieren [22]. Dafür soll kein neues Identifizierungsschema

geschaffen, sondern bestehende verwendet werden.

Beispiele für diese Identifizierungsschemata sind:

• ISBN (International Standard Book Number) bei Büchern • ISRC (International Standard Recording Code) für (digitale) Musik • ISAN (International Standard Audiovisual Number) für Filme

Die DII legt fest, wo in der DID Platz für diese Identifier ist (siehe Abbildung 7).


17

Abbildung 7: Digital Item Identification, aus [22]

Bestimmte Elemente können laut DID (siehe Abschnitt 2.2.1) ein oder mehrere

Descriptor-Elemente enthalten. Jedes dieser Descriptor-Elemente kann ein

Statement-Element enthalten, welches ein Identifier-Element für das Vaterelement

des Descriptor-Elementes beinhaltet.

In Abbildung 7 wird somit im linken Bereich ein Component-Elemnt und im rechten

Bereich ein Item-Element durch das jeweilige Identifier-Element identifiziert.


18

2.2.3 Content Handling and Usage

MPEG-21 soll folgende Aktionen ermöglichen [34]:

• Erstellung von Inhalten • Manipulation von Inhalten • Suche nach Inhalten • Zugriff auf Inhalte • Speicherung von Inhalten • Lieferung von Inhalten • Wiederverwendung von Inhalten

Um dies zu ermöglichen, müssen die nötigen Interfaces und Protokolle zur

Verfügung gestellt werden.

Der Fokus soll dabei auf die Erleichterung der Interaktion zwischen Usern gelegt

werden. Die Aktionen sollen sowohl von Usern als auch von Agenten durchgeführt

werden können. Bei Agenten handelt es sich um Programme, die verschiedene

Tätigkeiten automatisch und autonom für den User erledigen.

Derzeit werden User von Inhalten „erschlagen”, ohne wirklich die Möglichkeit zu

haben, diese zu filtern, zu kategorisieren oder auf andere Art zu manipulieren.

Außerdem ist derzeit das einzig vernünftig indizierbare Datenformat „Text“. Das

Internet lässt sich nur sehr beschränkt effizient nach anderen Daten durchsuchen

[20]. MPEG-7 hat hier schon Abhilfe geschaffen, indem eine Sprache zur

Beschreibung von Multimedia-Daten geschaffen wurde. MPEG-21 verwendet diese

Sprache wo es sinnvoll ist und erweitert sie wo es nötig ist.

2.2.4 Intellectual Property Management and Protection

MPEG-21 soll ein Framework zur Rechteverwaltung bereitstellen [24]. Jedem User

soll es möglich sein, seine Rechte an Digital Items auszudrücken [27], [29]. MPEG-

21 soll ebenso sicherstellen, dass die Rechte der User an Digital Items geschützt

werden.


19

Eines der Hauptanliegen bezüglich Intellectual Property Management and Protection

(IPMP) in MPEG-21 ist, dass es interoperabel sein soll. Bei MPEG-4 existiert das

Problem, dass viele verschiedene Hersteller MPEG-4 Player herstellen, deren IPMP-

Funktionalitäten inkompatibel zueinander sind [8]. Deshalb ist in MPEG-21

spezifiziert, dass es Möglichkeiten geben soll, IPMP-Tools von Remote-Servern zu

laden. Auf diese Weise soll Interoperabilität sichergestellt werden.

Die Rights Expression Language [13] ist ein Teil von IPMP und definiert eine

Sprache, die es erlaubt, Usern Rechte an Digital Items oder Sub-Elementen zu

gewähren.

Das Rights Data Dictionary [14] definiert die Begriffe, die in der Rights Expression

Language verwendet werden.

2.2.5 Terminals and Networks

Eines der Ziele von MPEG-21 ist, dass der User das Digital Item immer in

bestmöglicher Qualität konsumieren kann [31]. Die Qualität wird durch die

Eigenschaften des Netzwerkes, des Endgerätes und des Users (und dessen Wünsche)

eingeschränkt. Ein User mit einem mobilen Endgerät (z.B. PDA) soll sich genauso

einen Film ansehen können, wie ein User auf einem vollwertigen Multimedia-PC.

Dafür muss das Digital Item adaptiert werden, und zwar ohne dass der User in die

Adaptierung eingreifen muss. Genauer gesagt müssen die Ressource selbst (im oben

erwähnten Beispiel der Film) und dessen Beschreibung adaptiert werden. Deshalb

wird die Adaptierung in die Adaptierung der Beschreibung und in die Adaptierung

der Resource getrennt, wie in Abbildung 8 ersichtlich.


20

Abbildung 8: Digital Item Adaptation, aus [31]

Aufgrund der Vielfalt der Digital Items (bzw. der möglichen Inhalte) werden die

Adaptation Engines nicht in den MPEG-21-Standard aufgenommen. Format-

unabhängige Verfahren zur Adaptierung von Digital Items, werden aber sehr wohl

berücksichtigt. Die Adaptierung der Digital Items erfolgt mit Hilfe der Digital Item

Adaptation Tools (DIA Tools), auf die in Abschnitt 3 ausführlich eingegangen wird.

2.2.6 Content Representation

MPEG-21 soll ermöglichen, Inhalte beliebiger Datentypen anzuzeigen. Dabei sollen

die Fähigkeiten des Endgerätes beachtet und außerdem Interaktion mit dem User

ermöglicht werden.

ResourceAdaptation

Engine

Digital Item Adaptation Tools

DescriptorAdaptation

Engine

Digital Item AdaptedDigital Item

Digital Item Adaptation

R R’

D’D


21

2.2.7 Event Reporting

Event Reporting soll dem User die Überwachung sämtlicher relevanter Vorgänge

(z.B. Transaktionen) im MPEG-21 Multimedia-Framework ermöglichen. Damit kann

der User auf Ereignisse schnell und effizient reagieren. Event Reporting legt

Metriken und Schnittstellen fest, die dazu benutzt werden.


22

3 Digital Item Adaptation

Mit der Weiterentwicklung und stetig zunehmenden Verbreitung des Internets

werden auch die Endgeräte immer vielfältiger. Während vor ein paar Jahren noch

davon ausgegangen werden konnte, dass fast immer ein Personal Computer (PC) als

Endgerät auftritt, sind die Möglichkeiten heute viel weitläufiger. Neben PCs sind

auch immer öfter Personal Digital Assistants (PDAs), Handys, Tablet-PCs oder noch

„exotischere“ Geräte an das Internet angeschlossen. In MPEG-21 sollen nicht nur

PCs als Endgeräte inkludiert werden, Ziel ist es möglichst offen gegenüber jeglicher

Art von Endgeräten zu sein. Deshalb muss die Möglichkeit bestehen, Digital Items

zu adaptieren. Auch die Umgebung, Eigenschaften und Wünsche des Users und die

Rahmenbedingungen des Netzwerks sind wichtig für eine Adaptierung. Die

Adaptierung im Multimedia-Framework versucht all diese Punkte zu beachten, um

ein Digital Item bestmöglich zu anzupassen.

3.1 Überblick

Es gibt fünf grundlegende Voraussetzungen für die Adaptierung von Multimedia-

Ressourcen [11]:


23

Beschreibung der Ressource

Die Beschreibung der Ressource enthält Meta-Daten, die für die Adaptierung

benötigt werden. Hier werden beispielsweise Informationen bereitgestellt, die helfen

sollen, die Art der Adaptierung zu bestimmen. Sie enthalten aber auch

Informationen, die für den Adapatierungsprozess an sich wichtig sind. Abschnitt

3.3.1 behandelt die in MPEG-21 für diesen Zweck verwendete

Beschreibungssprache.

Beschreibung der Einschränkungen

Bei der Adaptierung müssen die Einschränkungen bezüglich des Benutzers, dessen

Umgebung, des Terminals und des Netzwerkes beachtet werden. In Abschnitt 3.1.3.1

wird näher auf die Tools eingegangen, die dies in MPEG-21 ermöglichen.

Skalierbarkeit der Ressource

Skalierbare Ressourcen erleichtern die Adaptierung, da sie eine sehr schnelle

Anpassung der Ressource erlauben. Man kann die adaptierte Version einer

Ressource erhalten, indem man Teile aus der ursprünglichen Ressource entfernt. In

JPEG-2000 wird beispielsweise jede Farbkomponente eines Bildes getrennt kodiert.

Handelt es sich um ein YCbCr Farbschema, bei dem die erste Komponente (Y) das

Bild in Graustufen darstellt, kann man sehr einfach eine Graustufenskalierung

vornehmen, indem man beim Dekodieren alle Pakete, die nicht zur ersten

Komponente gehören, verwirft.

Ist die Ressource nicht skalierbar, so muss sie transkodiert werden [26], was

wesentlich zeitaufwändiger ist.


24

Entscheidung über die Art der Adaptierung

Ein Algorithmus entscheidet aufgrund der Beschreibung der Ressource und der

Beschreibung der Einschränkungen, welche Art der Adaptierung vorgenommen

werden soll (siehe Abschnitt 4.4.3).

Adaptation Engine

Die Adaptation Engine führt die Adaptierung durch (siehe Abschnitte 4 und 5).

3.1.1 Transformierung der Beschreibung

Die Transformierung der Beschreibung ist relativ einfach. Durch die MPEG-21-

Standards ist festgelegt, welche Beschreibungselemente in welcher Form

vorkommen dürfen. Das erleichtert die Adaptierung, da bekannt ist, wie die

Beschreibung aufgebaut ist. So kann man genau festlegen, was in welcher Art

adaptiert werden kann.

3.1.2 Adaptierung der Ressource

Die Adaptierung der Ressource gestaltet sich komplexer. Wie in den vorigen

Abschnitten erläutert, erlaubt der MPEG-21-Standard beliebige Dokumente als

Ressource. Das heißt der Standard legt nicht fest, welche Dokumente als Ressource

auftreten dürfen. Theoretisch könnten dies sogar physische Objekte, wie

beispielsweise ein Haus, sein. Man benötigt also eine generische Beschreibung der

Ressource, um somit verschiedenste Ressourcen möglichst generisch adaptieren zu

können. Hierzu kann man die „generic Bitstream Syntax Description (gBSD)“ (siehe

Abschnitt 3.3.1.3) verwenden. Ein anderer Ansatz speichert formatabhängige

Informationen für jede Ressource, was eine genauere Beschreibung ermöglicht (siehe

Abschnitt 3.3.1.2).


25

3.1.3 Digital Item Adaptation Tools

Bei den Digital Item Adaptation Tools (DIA Tools) handelt es sich um Werkzeuge,

die der DIA Engine wichtige Informationen für die Adaptierung bereitstellen und

den Adaptierungsprozess lenken. Abbildung 9 gibt einen Überblick über diese Tools.

Usage Environment Description Tools

• User Characteristics• Terminal Capabilities• Network Characteristics• Natural Environment Characteristics

Digital Item Resource Adaptation Tools

• Bitstream Syntax Description• Terminal and Network QoS• Bitstream Syntax Description Link• Metadata Adaptability

Digital Item Declaration Adaptation Tools

• Session Mobility• DIA Configuration

Usage Environment Description Tools

• User Characteristics• Terminal Capabilities• Network Characteristics• Natural Environment Characteristics

Digital Item Resource Adaptation Tools

• Bitstream Syntax Description• Terminal and Network QoS• Bitstream Syntax Description Link• Metadata Adaptability

Digital Item Declaration Adaptation Tools

• Session Mobility• DIA Configuration

Abbildung 9: Digital Item Adaptation Tools, aus [31]

3.1.3.1 Usage Environment Description Tools

Die Usage Environment Description Tools geben Aufschluss über Usereigenschaften

und -umgebung, Art des Endgerätes und Art des Netzwerkes. Hier wird der DIA

Engine beispielsweise mitgeteilt, dass der User farbenblind ist, das Endgerät eine

maximale Auflösung von 320x200 Pixels unterstützt, das Netzwerk auf eine

Bandbreite von 64kbps beschränkt ist und/oder dass es in der Umgebung des Users

sehr hell ist. All diese Informationen sind wertvoll für die DIA Engine, da sie sie

verwenden kann, um eine möglichst gute Adaptierung durchzuführen.


26

3.1.3.2 Digital Item Resource Adaptation Tools

Die Resource-Adaptation Tools sind spezielle Hilfsmittel für die Adaptierung der

Ressource. Dies ist nicht trivial, wie wir in 3.1.2 schon festgestellt haben, da die

Ressource beliebigen Typs sein kann, sie aber möglichst generisch adaptiert werden

soll.

3.1.3.3 Digital Item Declaration Adaptation Tools

Während sich die Digital Item Resource-Adaptation Tools auf die Ressource

konzentrieren, helfen die Digital Item Declaration Adaptation Tools bei der Trans-

formierung der Struktur von Digital Items (siehe Abschnitt 2.2.1).

3.1.4 Der Adaptierungsprozess

Im MPEG-21 Multimedia-Framework werden Informationen immer durch Digital

Items übermittelt. Deshalb werden die DIA Tools ebenso in ein Digital Item gepackt.

Dieses Digital Item, welches nur Meta-Informationen enthält, heißt „Context Digital

Item“ (XDI). Das „Content Digital Item“ (CDI) beinhaltet sowohl Ressourcen als

auch Meta-Informationen [43] (siehe Abschnitt 2.2.1).

Die DIA Tools können aber nicht nur im XDI enthalten sein, sondern auch im CDI

selbst. So wird die DIA-Beschreibung der Ressource zum Teil des CDI, anstatt eines

separaten XDI. Abbildung 10 zeigt eine Übersicht über den Adaptierungsprozess.


27

Declaration

Digital ItemAdaptation Engine

Rights Expression

Resource

Identifiers

ResourceAdaptation Engine

DescriptionAdaptation Engine

Descriptor

DIA Tools

Declaration

Rights Expression

Identifiers

Declaration

Rights Expression

Identifiers

DIA Tools

Usage EnvironmentResource Level Tools

Digital Item Level Tools

CDI Adapted CDI

XDI

Descriptor

Resource

Descriptor

DIA Tools

Declaration

Digital ItemAdaptation Engine

Rights Expression

Resource

Identifiers

ResourceAdaptation Engine

DescriptionAdaptation Engine

Descriptor

DIA Tools

Declaration

Rights Expression

Identifiers

Declaration

Rights Expression

Identifiers

DIA Tools

Usage EnvironmentResource Level Tools

Digital Item Level Tools

CDI Adapted CDI

XDI

Descriptor

Resource

Descriptor

DIA Tools

Abbildung 10: Digital Item Adaptation, aus [31]

3.2 Usage Environment Description Tools

Diese Tools beschreiben die Umgebung des Users und den User selbst.

3.2.1 User Characteristics

Die User Characteristics beschreiben die Präferenzen bzw. Eigenschaften des Users

in Bezug auf Inhalt, Präsentation, Zugänglichkeit und Mobilität.


28

Userinfo

Das Userinfo Tool beschreibt allgemeine Informationen über den User, wie

beispielsweise Name und Adresse. User können Personen, Gruppen von Personen

oder Organisationen sein.

Abbildung 11 zeigt ein Beispiel einer Userinfo-Beschreibung. Neben dem Vornamen

(GivenName) und Nachnamen (FamilyName) des Users wird auch angegeben, aus

welchem Land er stammt (countryCode) und wie seine E-Mail Adresse lautet

(Email).

Dies kann hilfreich sein, wenn nähere Informationen zu einem Digital Item benötigt

werden und man deshalb mit dem Verfasser des Digital Items in Kontakt treten will.

Auch bei der Suche nach Digital Items können diese Informationen verwendet

werden. So können z.B. alle Digital Items, deren Verfasser aus demselben Land

stammt wie man selbst, hervorgehoben werden.

<DIA>

<Description xsi:type="UsageEnvironmentType">

<UsageEnvironment xsi:type="UserCharacteristicsType">

<UserCharacteristics xsi:type="UserInfoType">

<UserInfo xsi:type="mpeg7:PersonType">

<mpeg7:Name>

<mpeg7:GivenName>Michael</mpeg7:GivenName>

<mpeg7:FamilyName>Ransburg</mpeg7:FamilyName>

</mpeg7:Name>

<mpeg7:Citizenship>

<mpeg7:countryCode>AT</mpeg7:countryCode>

</mpeg7:Citizenship>

<mpeg7:ElectronicAddress>

<mpeg7:Email>[email protected]</mpeg7:Email>

</mpeg7:ElectronicAddress>

</UserInfo>

</UserCharacteristics>

</UsageEnvironment>

</Description>

</DIA>

Abbildung 11: Userinfo


29

Content Preferences

Das Content Preferences Tool versucht, die Präferenzen des Users bezüglich des

Inhaltes von Digital Items zu beschreiben. Dies kann entweder direkt durch einen

UserPreferences Descriptor erfolgen oder indirekt, indem die UsageHistory des

Users betrachtet wird. Es gibt hier verschiedene Klassen von Deskriptoren, die die

Präferenzen des Users beschreiben. Die Content Preferences verwenden den MPEG-

7 UserPreferencesType zur Beschreibung. Er bietet Filterkriterien (FilteringAnd

SearchPreferences) und Browsing-Kriterien (BrowsingPreferences) an. Die

Filterkriterien erlauben Angaben bezüglich der Erstellung des Digital Items

(CreationPreferences), der Art des Digital Items (ClassificationPreferences) und der

Herkunft des Digital Items (SourcePreferences). Des Weiteren wird der MPEG-7

UsageHistoryType verwendet, um die zuletzt betrachteten Digital Items zu

verwalten.

Abbildung 12 zeigt eine Content Preferences Beschreibung. Der User gibt hier an,

dass ihn das Genre „Science Fiction“ (Genre) besonders interessiert. Außerdem

bevorzugt er Inhalte in der Sprache Englisch (Language) und die Digital Items sollen

Inhalte für Erwachsene (MinimumAge) enthalten.

Ein Service Provider kann diese Informationen verwenden, um dem User speziell auf

ihn zugeschnittene Digital Items anzubieten (falls der User dies erlauben sollte).

Außerdem wird die Suche nach neuen Digital Items für den Benutzer vereinfacht, da

Suchresultate, die seinen „Content Preferences“ entsprechen, hervorgehoben werden

können.

Abbildung 13 zeigt ein Beispiel einer UsageHistory. Hier wird aufgelistet, welche

Digital Items sich der Benutzer am 15. September 2003 zwischen 20 Uhr und

Mitternacht angesehen hat (TimePoint, Duration). Jedes Digital Item wird durch

einen ProgramIdentifier eindeutig identifiziert, um es später wieder finden zu

können.


30

<DIA>



<UserCharacteristics xsi:type="ContentPreferencesType">

<UserPreferences>

<mpeg7:FilteringAndSearchPreferences>

<mpeg7:ClassificationPreferences>

<mpeg7:Genre>

<mpeg7:Name>Science Fiction</mpeg7:Name>

</mpeg7:Genre>

<mpeg7:Language>English</mpeg7:Language>

<mpeg7:ParentalGuidance>

<mpeg7:MinimumAge>18</mpeg7:MinimumAge>

</mpeg7:ParentalGuidance>

</mpeg7:ClassificationPreferences>

</mpeg7:FilteringAndSearchPreferences>

</UserPreferences>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 12: Content Preferences – User Preferences

Aus der UsageHistory kann wird ein ähnlicher Nutzen gezogen wie aus den

UserPreferences. Über den ProgramIdentifier kann herausgefunden werden, um

welche Digital Items es sich gehandelt hat, und zusätzlich kann man die Meta-

Informationen dieser Digital Items (Genre, Sprache usw.) verwenden, um den User

bei der Suche nach neuen Digital Items zu unterstützen. Wird beispielsweise

aufgrund der Usage History erkannt, dass sich ein User mit Vorliebe Digital Items

betrachtet, welche dem Genre „Science Fiction“ angehören, so können Digital Items,

die diesem Genre entsprechen, bei zukünftigen Suchen hervorgehoben werden.

Sollte der User damit einverstanden sein, können solche Informationen auch Service

Providern zugänglich gemacht werden, die dem User dann gezielte Angebote für

Digital Items senden können.


31

<DIA>



<UserCharacteristics xsi:type="ContentPreferencesType">

<UsageHistory>

<mpeg7:UserActionHistory>

<mpeg7:ObservationPeriod>

<mpeg7:TimePoint>2003-09-15T20:00:00</mpeg7:TimePoint>

<mpeg7:Duration>04:00:00</mpeg7:Duration>

</mpeg7:ObservationPeriod>

<mpeg7:UserActionList>

<mpeg7:ActionType>

<mpeg7:Name>PlayStream</mpeg7:Name>

</mpeg7:ActionType>

<mpeg7:UserAction>

<mpeg7:ProgramIdentifier>

urn:mymedia:av:02-mnf-109

</mpeg7:ProgramIdentifier>

</mpeg7:UserAction>

<mpeg7:UserAction>


urn:mymedia:av:14-znn-623


</mpeg7:UserAction>

<mpeg7:UserAction>


urn:mymedia:av:73-mov-814


</mpeg7:UserAction>

</mpeg7:UserActionList>

</mpeg7:UserActionHistory>

</UsageHistory>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 13: Content Preferences – Usage History

Presentation Preferences

Diese Tools beschreiben die Präferenzen des Benutzers in Bezug auf die Wiedergabe

von audiovisuellen Informationen. Die AudioPresentationPreferences erlauben die

Angabe seiner Präferenzen hinsichtlich der Wiedergabe von Audio-Informationen

(Lautstärke, Balance, Frequenzbereich, usw.). Die DisplayPresentationParameters


32

beschäftigen sich mit der Darstellung von visuellen Informationen. Es kann

festgelegt werden, welche Farbtemperatur, Helligkeit, Sättigung, welchen Kontrast,

usw. der User bevorzugt. Die GraphicsPresentationPreferences erlauben dem User

festzulegen, welche Arten von Grafiken er bevorzugt (GeometryEmphasis,

TextureEmphasis oder AnimationEmphasis). Bevorzugte Arten werden von der DIA

Engine immer in bestmöglicher Qualität belassen. Die ModalityConversion

Preference verstärkt die Möglichkeiten des Users, in die Funktionsweise der DIA

Engine einzugreifen. Kann ein Endgerät beispielsweise keine Videos wiedergeben,

so kann die DIA Engine das Video in eine Bilddarstellung transformieren. Ist auch

keine Bilddarstellung möglich, so kann das Bild in Textform dargestellt werden.

Durch die ModalityConversionPreference erhält der User die Möglichkeit, die

Reihenfolge dieser Adaptierungen (Video Bild Text im oben beschriebenen

Fall) zu kontrollieren. Durch die PresentationPriorityPreference kann der User

bestimmten Ressourcen eine höhere Priorität geben, was bewirkt, dass die DIA

Engine versucht, diese mit einer möglichst hohen Qualität zu adaptieren. Zuletzt

kann der User noch über den FocusOfAttentionType seine Region of Interest (ROI)

festlegen. Für ein Fußballspiel-Video kann er beispielsweise angeben, dass ihn die

Spieler besonders interessieren und das Publikum überhaupt nicht. Für bestimmte

Ressourcen, beispielsweise MPEG-4, kann die DIA Engine diese Elemente dann in

unterschiedlicher Qualität darstellen.

Abbildung 14 zeigt ein Beispiel einer Beschreibung der Audio Preferences eines

Users. Es wird die bevorzugte Lautstärke festgelegt (VolumeControl), die zwischen 0

und 1 liegen kann. Außerdem gibt der User an, dass er Lautsprecher als bevorzugtes

Ausgabegerät verwenden möchte (AudioOutputDevice). Der Balance-Wert der

Ausgabe wird mit 3 angegeben (BalancePreference). Er kann zwischen -10 und 10

liegen, wobei -10 bedeutet, dass nur der linke Lautsprecher verwendet wird und +10,

dass nur der rechte Lautsprecher verwendet wird.

Die Audio Preferences können als Standardeinstellung zur raschen Wiedergabe

verwendet werden. In speziellen Fällen kann der Benutzer diese natürlich ändern,

wenn er beispielsweise am Abend lieber seine Kopfhörer verwenden möchte. Im


33

zuvor skizzierten Fall könnte der rechte Lautsprecher etwas weiter entfernt vom

Benutzer sein, weshalb er die Lautstärke des rechen Lautsprechers durch die Angabe

des Wertes „3“ etwas erhöhen will.

<DIA>



<UserCharacteristics xsi:type="PresentationPreferencesType">

<Audio>

<VolumeControl>0.85</VolumeControl>

<AudioOutputDevice>Loudspeaker</AudioOutputDevice>

<BalancePreference>3</BalancePreference>

</Audio>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 14: Presentation Preferences - Audio

Abbildung 15 beschreibt die visuellen Vorlieben des Benutzers. Es werden die

bevorzugte Farbtemperatur (ColorTemperaturePreference), Helligkeit

(BrightnessPreference), Sättigung (SaturationPreference) und der bevorzugte

Kontrast (ContrastPreference) festgelegt. BinNumber legt hier den Wertebereich für

den jeweiligen PreferredValue fest. In diesem Fall liegt der PreferredValue

zwischen 0 und 255. Die jeweiligen Preferences (BrightnessPreference,

SaturationPreference, ContrastPreference) beziehen sich immer auf den Mittelwert

aller Pixel im Bild.

Mit Hilfe dieser Angaben kann der User bestimmen, wie visuelle Inhalte angezeigt

werden sollen. Ein Bild, dessen durchschnittlicher Helligkeitswert beispielsweise

unter den Angaben des Benutzers liegt, kann etwas heller angezeigt oder speziell für

den User markiert werden, woraufhin dieser die Anpassungen selbst vornehmen

kann.


34

<DIA>



<UserCharacteristics xsi:type="PresentationPreferencesType">

<Display>

<BrightnessPreference>

<BinNumber>255</BinNumber>

<Value>

<PreferredValue>138</PreferredValue>

</Value>

</BrightnessPreference>

<SaturationPreference>


<Value>


</Value>

</SaturationPreference>

<ContrastPreference>


<Value>


</Value>

</ContrastPreference>

</Display>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 15: Presentation Preferences - Color

Accessibility Characteristics

Diese Tools beschreiben Beeinträchtigungen des Users in Bezug auf dessen

audiovisuelle Aufnahmefähigkeit. Unterschieden wird hier zwischen

AuditoryImpairment und VisualImpairment. AuditoryImpairment erlaubt die Angabe

der Hörschwächen eines Users. Es kann angegeben werden, wie gut der User auf

dem rechten bzw. linken Ohr hören kann. VisualImpairment ermöglicht ähnliche

Angaben zu den optischen Fähigkeiten des Users. Neben der Sehstärke des

jeweiligen Auges kann angegeben werden, ob der User blind oder farbenblind ist

oder ob er sonstige Sehschwäche aufweist.


35

Abbildung 16 zeigt eine Beschreibung für einen User, dessen Gehör beeinträchtigt

ist. Es wird angegeben, wie gut bestimmte Frequenzen vom Benutzer auf dem

jeweiligen Ohr (RightEar, LeftEar) wahrgenommen werden können. Der hier

angegebene Frequenzbereich (250 Hz bis 8000 Hz) deckt den Großteil des

menschlichen Hörvermögens ab.

Diese Angaben können den User bei der Auswahl von Digital Items unterstützen.

Digital Items, die Inhalte aufweisen, die der User nur sehr schlecht wahrnehmen

kann, können speziell markiert werden. Außerdem kann eine DIA Engine diese

Angaben verwenden, um Inhalte für den Benutzer besser hörbar zu machen. Wählt

der User z.B. eine Aufzeichnung eines Vortrages, bei dem der Sprecher mit einer

Frequenz spricht, die der Benutzer besonders schlecht wahrnehmen kann, kann die

DIA Engine den Frequenzbereich dieser Aufzeichnung entweder nach oben oder

nach unten verschieben, um die Hörbarkeit zu verbessern. Der User könnte den

Sprecher dann zwar nicht mehr in seiner ursprünglichen Tonlage vernehmen, aber

zumindest bedeutend besser verstehen.

Abbildung 17 beinhaltet die Beschreibung eines Users, dessen visuelle

Aufnahmefähigkeit beeinträchtigt ist. Es wird angegeben, dass er eine leichte

Lichtsensitivität aufweist (LightSensitivity) und dass er unter dem Hemianopia

Syndrom [28] leidet (Hemianopia). Bei Hemianopia handelt es sich um eine

Augenkrankheit, bei der man nur auf einer Seite des jeweiligen Auges etwas sehen

kann. Dies beeinträchtigt das Lesevermögen des Users. Außerdem leidet der User

unter Farbenblindheit (CompleteColorBlindness).


36

<DIA>



<UserCharacteristics xsi:type="AccessibilityCharacteristicsType">

<Audio>

<RightEar>

<Freq250Hz>1.0</Freq250Hz>


<Freq1000Hz>-0.2</Freq1000Hz>




</RightEar>

<LeftEar>







</LeftEar>

</Audio>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 16: Auditory Impairment

Mit Hilfe dieser Informationen können Inhalte optimal für den speziellen User

aufbereitet werden. Ist ein User farbenblind, kann eine Graustufenadaptierung

vorgenommen werden. Außerdem können zu helle Flächen in einem Bild

entsprechend reduzieren werden, wenn man weiß, dass der User lichtsensitiv ist.


37

<DIA>



<UserCharacteristics xsi:type="AccessibilityCharacteristicsType">

<Visual>

<LowVisionSymptoms>

<LightSensitivity>Mild</LightSensitivity>

<Hemianopia side="right"/>

</LowVisionSymptoms>

<ColorVisionDeficiency>

<DeficiencyType>CompleteColorBlindness</DeficiencyType>

</ColorVisionDeficiency>

</Visual>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 17: Visual Impairment

Mobility Characteristics

Die Mobility Characteristics erlauben Angaben über den aktuellen Aufenthaltsort des

Users, inklusive eines Zeitstempels, wann dieser zuletzt überprüft wurde

(UpdateInterval). Außerdem kann angegeben werden, in welche Richtung sich der

User bewegt (Directivity).

Abbildung 18 zeigt eine Beschreibung der Mobility Characteristics eines Users. Es

wird angegeben, wo sich der User zuletzt aufgehalten hat (LastUpdatePoint,

TimePoint).

Das Wissen über den aktuellen Aufenthaltsort des Users kann für so genannte

„Location Based Services“ [23] verwendet werden, die derzeit hauptsächlich im

Mobilkommunikationsbereich anzutreffen sind. Ist der Aufenthaltsort des Benutzers

bekannt, so kann ein Service Provider ihm Informationen über den aktuellen

Aufenthaltsort anbieten (Wetterbericht, Nachrichten, Informationen über aktuelle

Veranstaltungen, usw.). Zudem können bei der Suche nach Digital Items jene

entsprechend hervorgehoben werden, die Inhalte aufweisen, die einen Bezug zum

aktuellen Aufenthaltsort des Benutzers haben.


38

<DIA>



<UserCharacteristics xsi:type="MobilityCharacteristicsType">

<UpdateInterval>

<LastUpdatePoint latitude="34.9" longitude="87.2"/>

<LastUpdateTime>

<Time>


</Time>

</LastUpdateTime>

</UpdateInterval>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 18: Mobility Characteristics

3.2.2 Terminal Capabilities

Die Terminal Capability Tools geben Aufschluss über die technischen Möglichkeiten

des Endgerätes. Sie sind in verschiedene Klassen unterteilt.

Codec Capabilities

Die Codec Capabilites beschreiben, welche verschiedenen Formate das Terminal

dekodieren bzw. kodieren kann.

Abbildung 19 zeigt ein Beispiel für eine derartige Beschreibung. Es wird angegeben,

welche verschiedenen Codecs das Endgerät unterstützt. Zum Dekodieren (Decoding)

von Audio-Dateien (AudioCapabilities) werden MP3 und AMR [30] unterstützt. Bei

Adaptive Multi-Rate (AMR) handelt es sich um einen Codec, der primär für mobile

Endgeräte, wie beispielsweise Handys, entwickelt wurde. Weiters wird das De-

kodieren von Bildern im JPEG-Format unterstützt (ImageCapabilitiesType) und das

Dekodieren von Videos, die im MPEG-4 Visual Simple Profile @ Level 1 vorliegen

(VideoCapabilitiesType). AMR und MPEG-4 Visual Simple Profile @ Level 1 Daten

können nicht nur dekodiert, sondern auch kodiert (Encoding) werden. Dieses


39

Endgerät kann also MP3- und JPEG-Dateien wiedergeben und AMR- und MPEG-4-

Dateien sowohl wiedergeben als auch erzeugen.

Es bringt viele Vorteile zu wissen, welche Codecs ein Endgerät unterstützt. Bei einer

Suche nach Digital Items kann automatisch festgestellt werden, ob alle Inhalte eines

Digital Items am jeweiligen Endgerät abspielbar sind. Der User kann darauf

hingewiesen werden, wenn bestimmte Inhalte eines Digital Items auf seinem

Endgerät nicht wiedergegeben werden können, womit sich der User viel Zeit sparen

kann. Bedient sich der User der Dienste eines Service Providers, der ihm regelmäßig

Digital Items anbietet, so kann dieser Service Provider von vornherein jene Digital

Items ausselektieren, die für den User nicht betrachtbar sind. Ebenso kann er, soweit

er die entsprechenden Codecs hat, die Dateien, die nicht wiedergegeben werden

können, transkodieren, um das Digital Item für den User anzupassen.

Codec Parameter

Über diese Klasse werden dem Codec verschiedene Parameter mitgeteilt. Hier wird

beispielsweise bestimmt, mit welcher Bitrate ein Codec enkodieren soll.

Input/Output Capabilities

Diese beschreiben die Input/Output-Möglichkeiten eines Endgerätes. Man

unterscheidet die DisplayCapabilities, die Informationen über die Anzeige des

Endgerätes enthalten, die AudioOutputCapabilities, die die Audio-Fähigkeiten des

Endgerätes beschreiben und die UserInteractionInputSupport Informationen, die

Aufschluss über die Möglichkeiten der User-Interaktion geben.


40

<DIA>


<UsageEnvironment xsi:type="TerminalCapabilitiesType">

<TerminalCapabilities xsi:type="CodecCapabilitiesType">

<Decoding xsi:type="AudioCapabilitiesType">

<Format href="urn:mpeg:mpeg7:cs:AudioCodingFormatCS:2001:4.4">

<mpeg7:Name xml:lang="en">MP3</mpeg7:Name>

</Format>

<Format href="urn:mpeg:mpeg7:cs:AudioCodingFormatCS:2001:6">

<mpeg7:Name xml:lang="en">AMR</mpeg7:Name>

</Format>

</Decoding>

<Decoding xsi:type="ImageCapabilitiesType">

<Format href="urn:mpeg:mpeg7:cs:VisualCodingFormatCS:2001:4">

<mpeg7:Name xml:lang="en">JPEG</mpeg7:Name>

</Format>

</Decoding>

<Decoding xsi:type="VideoCapabilitiesType">

<Format

href="urn:mpeg:mpeg7:cs:VisualCodingFormatCS:2001:3.1.2">

<mpeg7:Name xml:lang="en">

MPEG-4 Visual Simple Profile @ Level 1

</mpeg7:Name>

</Format>

</Decoding>

<Encoding xsi:type="AudioCapabilitiesType">

<Format href="urn:mpeg:mpeg7:cs:AudioCodingFormatCS:2001:6">

<mpeg7:Name xml:lang="en">AMR</mpeg7:Name>

</Format>

</Encoding>

<Encoding xsi:type="VideoCapabilitiesType">

<Format

href="urn:mpeg:mpeg7:cs:VisualCodingFormatCS:2001:3.1.2">

<mpeg7:Name xml:lang="en">

MPEG-4 Visual Simple Profile @ Level 1

</mpeg7:Name>

</Format>

</Encoding>

</TerminalCapabilities>

</UsageEnvironment>

</Description>

</DIA>

Abbildung 19: Terminal Capabilites – Codec Capabilities, aus [31]

In Abbildung 20 sieht man ein Beispiel einer derartigen Beschreibung. Es werden die

Auflösung des Endgerätes (Resolution), die Pixeltiefe (bitsPerPixel) und die


41

Farbtauglichkeit (colorCapable) angegeben. Außerdem wird angegeben, über welche

Audio-Möglichkeiten das Terminal verfügt (AudioOut). Dieses kann Töne zwischen

30 (lowFrequency) und 8000 (highFrequency) Hertz in Stereo (numChannels)

wiedergeben. Das Terminal in diesem Beispiel verfügt außerdem über ein

Mikrophon (Microphone), ein Standard PC Keyboard (KeyInput) und eine Maus mit

zwei Tasten und Laufrad (Mouse).

Genaue Informationen über die Fähigkeiten eines Terminals sind sehr hilfreich um

sicherzustellen, dass dem User die Digital Items immer in bestmöglicher Qualität

geboten werden. Im oben beschriebenen Fall unterstützt das Terminal Stereo und

eine Bildschirmauflösung von 176x144 Pixel. Mit diesem Wissen kann eine DIA

Engine ein Digital Item anpassen, bevor es überhaupt zum User gesendet wird.

Ebenso können Service Provider wiederum Nutzen daraus ziehen. Sie können die

Digital Items genau an das Endgerät des jeweiligen Users anpassen und somit

garantieren, dass er es in bestmöglicher Qualität betrachten kann.

Device Property und Device Class

Die Hardware des Endgerätes wird durch diese Attribute beschrieben. Es werden

Angaben zur Stromversorgung (Power), zum verwendeten Datenträger (Storage), zu

den I/O-Fähigkeiten (DataIO) gemacht und letztendlich wird das Gerät in eine

Klasse (DeviceClass) eingeteilt, beispielsweise PC oder PDA.

Abbildung 21 zeigt ein Beispiel für die Beschreibung der Eigenschaften des

Endgerätes. Es werden Angaben über die Stromversorgung des Endgerätes gemacht.

Es verbraucht im Durchschnitt 0.2 Ampere pro Stunde (averageAmpere

Consumption) und die Batterieversorgung reicht noch für 10800 Sekunden

(batteryTimeRemaining) bzw. 15 Amperestunden (batteryCapacityRemaining). Der

Speicher des Gerätes ist beschreibbar (writeable), verfügt über eine Kapazität von

120 MB (size) und hat eine I/O Geschwindigkeit von 8/4 MBps (inputTransferRate,

outputTransferRate). Der Bus des Gerätes ist 128 Bit breit (busWidth) und

unterstützt eine Geschwindigkeit von 32 MBps (transferSpeed). Außerdem wird

angegeben, dass es sich beim Endgerät um einen PDA handelt (DeviceClass).


42

<DIA>



<TerminalCapabilities xsi:type="InputOutputCapabilitiesType">

<Display colorCapable="true" bitsPerPixel="8">

<Resolution horizontal="176" vertical="144"/>

</Display>

<AudioOut lowFrequency="30" highFrequency="8000" numChannels="2"/>

<UserInteractionInputSupport>

<Microphone>true</Microphone>

<KeyInput href="urn:mpeg:mpeg21:2003:01-DIA-KeyInputCS-NS:1">

<mpeg7:Name xml:lang="en">PCKeyboard</mpeg7:Name>

</KeyInput>

<PointingDevice>

<Mouse buttons="2" scrollwheel="true"/>

</PointingDevice>

</UserInteractionInputSupport>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 20: Terminal Capabilities – Input/Output Capabilities

Diese stark systemnahen Informationen können für eine DIA Engine sehr wichtig

sein. Mit Hilfe dieser Informationen kann man berechnen, wie lange das Gerät für

eine Adaptierung braucht bzw. ob die Adaptierung nicht sogar in Echtzeit geschehen

kann. So wird festgestellt, welche Adaptierungen auf dem jeweiligen Endgerät

sinnvoll sind, bzw. der User wird davon in Kenntnis gesetzt, wie lange eine

bestimmte Adaptierung benötigen würde.


43

<DIA>



<TerminalCapabilities xsi:type="DevicePropertyType">

<Power averageAmpereConsumption="0.2" batteryCapacityRemaining="15" batteryTimeRemaining="10800"/>

<Storage inputTransferRate="8" outputTransferRate="4" size="120" writeable="true"/>

<DataIO busWidth="128" transferSpeed="32"/>

<DeviceClass href="urn:mpeg:mpeg21:2003:01-DIA-DeviceClassCS-NS:1">

<mpeg7:Name xml:lang="en">PDA</mpeg7:Name>

</DeviceClass>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 21: Terminal Capabilities – Device Property

3.2.3 Network Characteristics

Diese Tools beschreiben die Eigenschaften und den aktuellen Zustand des

Netzwerks. Der gegenwärtige Zustand wird im NetworkCharacteristicsBaseType

beschrieben. Dort kann die maximale Kapazität (maxCapacity) und die minimal

garantierte Kapazität (minGuaranteed) des Netzwerkes angegeben werden.

Außerdem wird deklariert, ob das Netzwerk Fehlerkorrektur unterstützt

(errorDelivery), fehlerhafte Pakete vom Netzwerk entfernt (errorCorrection) und ob

es garantiert, dass die Reihenfolge der abgesendeten Pakete der der angekommenen

entspricht (inSequenceDelivery).

Abbildung 22 zeigt ein Beispiel einer Beschreibung des Netzwerkes. Die vom

Netzwerk maximal unterstützte Bandbreite beträgt 1310720 bps (maxCapacity) und

die garantierte Bandbreite beträgt 65536 bps (minGuaranteed). Das Netzwerk

garantiert, dass alle Pakete in der Reihenfolge ankommen, in der sie abgesendet

wurden (inSequenceDelivery), und es korrigiert fehlerhafte Pakete automatisch

(errorCorrection). Die Roundtrip-Zeit für Pakete beträgt 330 Millisekunden und die

aktuelle Paketverlustrate liegt bei 0.05 (das entspricht 5%).


44

Diese Informationen sind wichtig für das Senden und Empfangen von multimedialen

Daten. Ein Digital Item kann z.B. einen Verweis auf einen Videoserver enthalten, der

einen Videostrom in Echtzeit zum Endgerät sendet. Dazu werden Informationen über

das Netzwerk, um zu bestimmen, mit welcher Qualität gesendet werden kann,

benötigt.

<DIA>


<UsageEnvironment xsi:type="NetworkCharacteristicsType">

<NetworkCharacteristics xsi:type="NetworkCapabilityType" maxCapacity="1310720" minGuaranteed="65536" inSequenceDelivery="true" errorCorrection="true"/>

<NetworkCharacteristics xsi:type="NetworkConditionType">

<Delay packetTwoWay="330"/>

<Error packetLossRate="0.05"/>

</NetworkCharacteristics>

</UsageEnvironment>

</Description>

</DIA>

Abbildung 22: Network Characteristics

3.2.4 Natural Environment Characteristics

Diese Tools beschreiben die natürliche Umgebung des Terminals/Users. Es wird

angegeben, an welchem Ort sich der User gerade befindet, wobei hier der MPEG-7

PlaceType verwendet wird, der die Angabe der Adresse, der geographischen Position

in Breitengraden, Längengraden und Höhe und sogar des Planeten zulässt. Außerdem

wird die aktuelle Uhrzeit des Users mit Hilfe des MPEG-7 TimeType angegeben.

Durch AudioEnvironment-Angaben erhält man Informationen über die

Geräuschkulisse beim User. Es wird die Lautstärke der Störgeräusche angegeben und

außerdem die Verteilung der Störgeräusche auf die verschiedenen Frequenzen.

Zuletzt werden noch die Beleuchtungsverhältnisse (IlluminationCharacteristics)

beim User beschrieben.

Abbildung 23 gibt ein Beispiel einer Beschreibung des Standortes des Benutzers

wieder. Die Adresse des Users (PostalAddress) scheint gemeinsam mit der

geographischen Position in Längengraden, Breitengraden und Höhe (longitude,


45

latitude und altitude) auf. Zudem wird angegeben, dass sich der User gerade in

Österreich (Region) befindet.

<DIA>


<UsageEnvironment xsi:type="NaturalEnvironmentCharacteristicsType">

<NaturalEnvironmentCharacteristics xsi:type="LocationType">

<Location>

<mpeg7:PostalAddress>

<mpeg7:AddressLine>Heinrich-Heine-Gasse 28</mpeg7:AddressLine>

<mpeg7:PostingIdentifier>A-9020</mpeg7:PostingIdentifier>

</mpeg7:PostalAddress>

<mpeg7:Region>at-carinthia</mpeg7:Region>

<mpeg7:GeographicPosition>

<mpeg7:Point longitude="135.75" latitude="35.00" altitude="10.00"/>

</mpeg7:GeographicPosition>

<mpeg7:Region>at</mpeg7:Region>

</Location>

</NaturalEnvironmentCharacteristics>

</UsageEnvironment>

</Description>

</DIA>

Abbildung 23: Natural Environment Characteristics - Location

Abbildung 24 zeigt ein Beispiel für die Angabe der Uhrzeit (TimePoint), zu welcher

ein Digital Item zuletzt betrachtet wurde.

Zusammen mit der Location Information ist somit feststellbar, wo und wann ein

Digital Item zuletzt betrachtet wurde. Besitzt der Benutzer eine große Anzahl von

Digital Items, so kann ein automatisiertes System ihm vorschlagen, jene Digital

Items, die er schon sehr lange nicht mehr betrachtet hat, zu archivieren. In gleicher

Art und Weise können Digital Items, die vom User sehr oft betrachtet werden

(beispielsweise ein Digital Item mit einem Verweis auf die aktuellen Nachrichten),

hervorgehoben und so dem User leichter zugänglich gemacht werden.


46

<DIA>



<NaturalEnvironmentCharacteristics xsi:type="TimeType">

<Time>


</Time>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 24: Natural Environment Characteristics - Time

Abbildung 25 zeigt ein Beispiel für die Angaben der Geräuschkulisse beim Benutzer.

Es wird sowohl die Lautstärke der Störgeräusche (NoiseLevel), als auch die

Verteilung der Störgeräusche über den wahrnehmbaren Frequenzbereich angegeben.

Der Frequenzbereich in Hertz ist fix vorgegeben und reicht von 12.5 bis 20000 (33

Zwischenstufen). Dementsprechend gibt jeder Wert des NoiseFrequencySpectrum

die Stärke des Störgeräusches für die jeweilige Frequenz an. Bei 12.5 Hz gibt es

keine Störgeräusche (erster Eintrag), während es bei 20000 Hz Störgeräusche von 4

Dezibel gibt (letzter Eintrag).

Ähnlich wie bei den Accessibility Characteristics – Audio Impairment (siehe

Abschnitt 3.2.1) kann aufgrund dieser Angaben versucht werden, die Audio-Inhalte

entsprechend zu adaptieren.

Abbildung 26 zeigt ein Beispiel für die Festlegung der Lichtverhältnisse beim User.

Es wird angegeben, wie hell es derzeit in der Umgebung des Benutzers ist. Im

aktuellen Beispiel beträgt die Helligkeit 73000 Lux.


47

<DIA>



<NaturalEnvironmentCharacteristics xsi:type="AudioEnvironmentType">

<NoiseLevel>15</NoiseLevel>

<NoiseFrequencySpectrum>

0 0 5 7 9 10 10 10 15 17

17 20 25 28 28 28 27 25 23 20

18 18 17 15 12 9 6 3 3 2

2 1 4

</NoiseFrequencySpectrum>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 25: Natural Environment Characteristics – Audio Environment

Aufgrund dieser Angaben können visuelle Inhalte entsprechend angepasst werden.

Im obigen Beispiel ist der User einer Helligkeit von 73000 Lux ausgesetzt, er hält

sich also vermutlich in direkter Sonneneinstrahlung auf. Auf Wunsch des Users kann

eine DIA Engine die Helligkeit visueller Inhalte (Bilder, Videos, usw.) entsprechend

verringern, um den Kontrast zu erhöhen. In einer hellen Umgebung, bzw. bei direkter

Sonneneinstrahlung, führt dies zu einer besseren Sichtbarkeit der Inhalte.

<DIA>



<NaturalEnvironmentCharacteristics xsi:type="IlluminationCharacteristicsType">

<Illuminance>73000</Illuminance>


</UsageEnvironment>

</Description>

</DIA>

Abbildung 26: Natural Environment Characteristics - Illumination


48

3.3 Digital Item Resource Adaptation Tools

Die Digital Item Resource Adaptation Tools helfen bei der Adaptierung von

Ressourcen in Digital Items.

3.3.1 Beschreibung der Ressource

In MPEG-21 wird eine XML-Beschreibung der Ressource verwendet, um den

Adaptierungsprozess zu vereinfachen. Diese XML-Beschreibung enthält sowohl

Informationen, die die Auswahl des Adaptierungsverfahrens erleichtern sollen, als

auch eine Beschreibung der Struktur der Ressource, die bei der Adaptierung selbst

von Nutzen ist.

Einerseits wurde zu diesem Zweck die „Bitstream Syntax Description Language“

(BSDL) entworfen [35][40]. Sie basiert auf einem XML-Schema [52] und ermöglicht

es, Bitstream Syntax Schemata (BS Schemata) zu generieren, die die Struktur eines

bestimmten Kodierungsformats beschreiben (siehe Abschnitt 3.3.1.2).

Andererseits wurde ein „generic Bitstream Syntax Schema“ (gBS-Schema) [11][41]

entworfen, welches ermöglicht, die Struktur einer Ressource unabhängig von ihrem

Kodierungsformat zu beschreiben (siehe Abschnitt 3.3.1.3).

Abbildung 27 zeigt den groben Ablauf einer Transformierung bzw. Adaptierung.

Gegeben ist ein skalierbarer Bitstrom, aus dem, mit Hilfe eines BS Schemas oder

eines gBS-Schemas, eine Beschreibung generiert wird. Diese Beschreibung wird

dann gemäß den Adaptierungsparametern transformiert, und mit Hilfe dieser

transformierten Beschreibung kann man eine adaptierte Ressource generieren. Das

Resultat beinhaltet eine transformierte Beschreibung und einen adaptierten Bitstrom.


49

Abbildung 27: Transformierung und Adaptierung, aus [31]

3.3.1.1 Schema-Hierarchie

Zur Beschreibung eines Bitstroms wird ein Schema benötigt, welches die mögliche

Syntax angibt, die zur Beschreibung verwendet werden darf. Je nachdem, welcher

Ansatz verfolgt wird (BSD oder gBSD), werden verschiedene Schemata verwendet

(siehe Abbildung 28), die in [31] definiert sind:

Schema für BSDL-1 Extensions

Das BSDL-1 Schema definiert grundlegende Datentypen, die zum Generieren von

adaptierten Bitströmen verwendet werden. Sowohl der BSD-Ansatz als auch der

gBSD-Ansatz benutzen dieses Schema zur Erzeugung des adaptierten Bitstroms.


50

Schema für BSDL-2 Extensions

Das BSDL-2 Schema definiert jene Sprachelemente, die der Beschreibung von

Bitströmen dienen. Dieses Schema erlaubt eine sehr detaillierte Beschreibung von

Bitströmen, weshalb es auch ein formatspezifisches Schema benötigt. Es wird vom

BSD-Ansatz zur Generierung der Beschreibung einer Ressource verwendet.

Codec-spezifische Schemata

Für eine BSD wird ein formatspezifisches Schema benötigt. Dieses Schema

verwendet die Datentypen aus dem BSDL-1 Schema und die Sprachkonstrukte aus

dem BSDL-2 Schema. Somit kann man eine formatabhängige Beschreibung einer

Ressource (siehe Abschnitt 3.3.1.2) bzw. aus der Beschreibung wieder eine

Ressource generieren.

gBS-Schema

Für gBSDs wird kein formatspezifisches Schema benötigt. Das gBS-Schema

verwendet die Datentypen aus dem BSDL-1 Schema zur Generierung des adaptierten

Bitstroms. Mit Hilfe des gBS-Schemas wird eine generische Beschreibung einer

Ressource generiert (siehe Abschnitt 3.3.1.3).

3.3.1.2 Bitstream Syntax Description

Basierend auf den BSDL-1, BSDL-2 und den formatabhängigen Schemata können

Codec-spezifische Bitstream Syntax Descriptions (BSDs) generiert werden. Die

formatabhängigen Schemata erlauben eine hohe Detailliertheit der Beschreibung.

Allerdings weisen die formatabhängigen Schemata auch Nachteile auf, besonders bei

Endgeräten, auf welchen der Speicherplatz beschränkt ist, da ja für jedes Schema

zusätzliche Daten gespeichert werden müssen. Abhilfe bringt hier das gBS-Schema,

welches die formatabhängigen Schemata ersetzt und erlaubt, eine Beschreibung zu

generieren, die nicht formatspezifisch ist.


51

Schema for BSDL-1 Extensions

gBS Schema

Codec specific Schemas

gBS Description

BS Description

... Normative Elements

... Imports

... Instance of

Schema for BSDL-2 Extensions

Abbildung 28: Schema Hierarchie, aus [31]

Abbildung 29 zeigt ein Beispiel einer BSD welches ein Packet mit verschiedenen

Parametern enthält (Marker, LMarker und Nsop). Außerdem wird mit dem

PacketData-Element auf einen Bytebereich im Bitstrom verwiesen, der die restlichen

Daten dieses Paketes enthält (Byte 155 bis 242).

52

<?xml version="1.0" ?>

<Codestream xmlns="JP2" xmlns:jp2="JP2" xsi:schemaLocation="JP2 JP2.xsd">

<MainHeader>



</MainHeader>

<Bitstrom>

<Packet>

<SOP>

<Marker>FF91</Marker>

<LMarker>4</LMarker>

<Nsop>0</Nsop>

</SOP>

<PacketData>155 242</PacketData>

</Packet>



</Bitstrom>



Abbildung 29: Bitstream Syntax Description

3.3.1.3 Generic Bitstream Syntax Description

Das gBS-Schema definiert die Syntax zur generischen Beschreibung von Bitströmen.

Die besonderen Eigenschaften dieser Syntax sind:

• Unabhängigkeit vom Kodierungsformat • Semantische Markierungen • Hierarchische Beschreibungen

Im Header-Element einer gBSD werden allgemeine Eigenschaften festgelegt.

Abbildung 30 zeigt das Header-Element eines MPEG-4 Video-Bitstroms. Im

ClassificationAlias wird festgelegt, dass es sich um einen MPEG-4 Video-Bitstrom

handelt. Die DefaultValues legen die Adressierungseinheit (addressUnit - Byte oder

Bit) und die Adressierungsart (addressMode - absolut, consecutive oder offset) fest.

Außerdem wird angegeben, wo sich die Ressource befindet (globalAddressInfo).


53

<Header>

<ClassificationAlias alias="MV4" href="urn:mpeg:mpeg4:video:cs:syntacticalLabels"/>

<DefaultValues addressUnit="byte" addressMode="Absolute"

globalAddressInfo="content/lotr2.cmp"/>

</Header>

Abbildung 30: Header

Grundlegendes Element einer gBSD ist die gBSDUnit, die einen bestimmten Bit-

oder Bytebereich eines Bitstroms beschreibt.

Abbildung 31 zeigt eine gBSDUnit, die festlegt, dass es sich im Bitstrom ab dem

Byte 19877 mit einer Länge von 3218 Byte um einen B-Frame handelt. Mit

Informationen dieser Art könnte eine DIA Engine z.B. alle B-Frames eines Videos

aus einer Beschreibung entfernen und anschließend den Bitstrom ohne B-Frames neu

generieren, um somit die Frameanzahl zu verringern und ein Abspielen auf einem

Endgerät mit geringen Ressourcen zu ermöglichen.

<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="19877" length="3218"/>

Abbildung 31: gBSDUnit

Das Parameter-Element ähnelt dem gBSDUnit-Element und beschreibt ebenso einen

bestimmten Bit- oder Bytebereich eines Bitstroms. Anders als beim gBSDUnit-

Element wird aber der genaue Wert angegeben, der sich an der jeweiligen Stelle im

Bitstrom befindet. Bei einer Transformierung der Beschreibung erhält man somit

nicht nur die Möglichkeit, Teile der Beschreibung herauszufiltern (bei gBSDUnit-

Elementen), sondern sie sind auch veränderbar (bei Parameter-Elementen), da ja der

genaue Wert bekannt ist.

Abbildung 32 beinhaltet eine gBSDUnit, die 49 Byte groß ist (es wird angenommen,

dass im Header „Byte“ als addressUnit angegeben wurde). In dieser gBSDUnit sind

weitere gBSDUnits mit einer Gesamtgröße von 11 Byte enthalten und Parameter-


54

Elemente mit einer Gesamtgröße von 38 Byte. Der addressMode für diese gBSDUnit

ist Consecutive (fortlaufend), d.h. für die enthaltenen Elemente muss nur mehr deren

Länge (length) angegeben werden. Die jeweiligen Parameter-Elemente umfassen

jeweils ein Value-Element, welches den Wert an der jeweiligen Stelle im Bitstrom

enthält. An Byte-Positionen acht bis elf steht beispielsweise ein Wert vom Typ

unsigned integer (unsignedInt) mit dem Namen „:J2K:Xsiz“, der die Breite des

Bildes (es handelt sich hier um die Beschreibung eines JPEG-2000-Bildes) angibt

und 640 Pixel beträgt.

Zusätzlich können gBSDUnits hierarchisch verschachtelt werden, um, z.B. bei

Videos, Beschreibungen ganzer „Szenen“ zu ermöglichen. Zur Beschreibung wird

das marker-Attribut verwendet. Außerdem unterstützt die hierarchische

Verschachtelung die Skalierung von Ressourcen, da es sehr leicht fällt, bestimmte

Teile einer Ressource zu entfernen.

Abbildung 33 zeigt eine solche Verschachtelung. Hier wird festgelegt, dass es sich

ab dem Byte 12288 mit einer Länge von 47768 Bytes um eine gBSDUnit mit der

marker-Beschriftung „Violence 6“ handelt. Die Beschriftungsmöglichkeiten des

marker-Attributs sind nicht standardisiert, d.h. eine DIA Engine muss selbst

erkennen, wie sie eine solche Beschreibung verwenden kann. Diese gBSDUnit

besteht nun aus fünf weiteren gBSDUnits, die jeweils einen Frame beschreiben, d.h.

die Szene mit dem Gewaltfaktor sechs ist fünf Frames lang. Sollte eine DIA Engine

nun alle Szenen über einem bestimmten Gewaltlevel aus einem Video entfernen

wollen, muss sie nur das marker-Attribut prüfen und kann die jeweiligen Szenen

somit effizient filtern.


55

<gBSDUnit syntacticalLabel=":J2K:SIZ" start="2" length="49">

<Header>

<DefaultValues addressMode="Consecutive"/>

</Header>

<gBSDUnit length="2"/>

<Parameter name=":J2K:Lsiz" length="2">

<Value xsi:type="xsd:unsignedShort">47</Value>

</Parameter>

<Parameter name=":J2K:Rsiz" length="2">


</Parameter>

<Parameter name=":J2K:Xsiz" length="4">

<Value xsi:type="xsd:unsignedInt">640</Value>

</Parameter>

<Parameter name=":J2K:Ysiz" length="4">


</Parameter>

<Parameter name=":J2K:XOsiz" length="4">


</Parameter>

<Parameter name=":J2K:YOsiz" length="4">


</Parameter>

<Parameter name=":J2K:XTsiz" length="4">


</Parameter>

<Parameter name=":J2K:YTsiz" length="4">


</Parameter>

<Parameter name=":J2K:XTOsiz" length="4">


</Parameter>

<Parameter name=":J2K:YTOsiz" length="4">


</Parameter>

<Parameter name=":J2K:Csiz" length="2">


</Parameter>

<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C0"/>



</gBSDUnit>

Abbildung 32: Parameter


56

<gBSDUnit start="12288" length="47768" marker="Violence 6">

<gBSDUnit syntacticalLabel=":MV4:P_VOP" start="12288” length="7589"/>




<gBSDUnit syntacticalLabel=":MV4:P_VOP" start="29977" length="30079"/>

</gBSDUnit>

Abbildung 33: Hierarchische Verschachtelung von gBSDUnits

3.3.1.4 Generierung der Beschreibung

Mit Hilfe von bitstromspezifischen Informationen und Marker-Informationen (wenn

man nicht nur aufgrund der syntacticalLables, sondern auch aufgrund von

semantischen Informationen adaptieren können will) wird nun eine Beschreibung

generiert. Die bitstromspezifischen Informationen beschreiben die Struktur des

jeweiligen Bitstroms (siehe Abbildung 34).

Abbildung 34: Generierung der gBSD, aus [31]


57

3.3.1.5 Transformierung der Beschreibung

Abbildung 35 zeigt den ersten Schritt der eigentlichen Adaptierung, in dem die

Beschreibung des Bitstroms adaptiert wird. Dies geschieht mit Hilfe eines

„Extensible Stylesheet Language for Transformations Style-Sheets“ (XSLT Style-

Sheet) [47]. Bei XSLT handelt es sich um eine Sprache, die basierend auf der

„Extensible Stylesheet Language“ (XSL) [43] speziell zur Transformierung von

XML-Dokumenten entwickelt wurde.

Zur Generierung bzw. Bestimmung dieses Style-Sheets werden Informationen aus

Abschnitt 3.2 herangenommen:

• User Characteristics • Terminal Capabilities • Network Characteristics • Natural Environment Characteristics

Abbildung 35: Transformierung der Beschreibung, aus [31]

3.3.1.6 Generierung des Bitstroms

Anschließend kann, mit Hilfe der transformierten Beschreibung, der Bitstrom

entsprechend adaptiert werden (siehe Abbildung 36). Zusätzlich dazu müssen

natürlich auch die Bit/Byte-Adressen der gBSDUnits bzw. der PacketData-Elemente


58

der BSD entsprechend angepasst werden (siehe Abschnitt 3.1.3.2 und 3.3.1.3). Diese

Anpassung muss erfolgen, da sich die Adressen von Elementen des Bitstroms bei der

Adaptierung ändern können. Werden beispielsweise B-Frames eines Video-

Bitstroms herausgefiltert, ändern sich die Adressen aller nachfolgenden Elemente.

Abbildung 36: Adaptierung des Bitstroms, aus [31]

3.3.2 Bitstream Syntax Description Link

Dieses Tool bietet die Möglichkeit, BSDs (siehe Abschnitt 3.3.1) mit so genannten

Steuerungstools zu verbinden. Dies ermöglicht sehr flexible Adaptierungsarten, so

dass die Bitstream Syntax Description zum Beispiel von den AdaptationQoS oder

den Usage Environment Description Tools gesteuert werden kann.

Abbildung 37 zeigt ein Beispiel, wie ein Bitstream Syntax Description Link

aussehen kann. Das Steuerungstool ist in diesem Fall die QoS-Beschreibung

(Steering

DescriptionRef). Abbildung 38 zeigt ein Beispiel einer solchen Beschreibung. Mit

Hilfe dieser Beschreibung und dem XSLT Style-Sheet (BSDTransformationRef) wird


59

die Bitstream Syntax Description (BSDRef) transformiert. Die Parameter

(Parameter) dienen als Eingabeparameter für das Style Sheet, welches die Bitstream

Syntax Description transformiert. Die möglichen Wertebelegungen der Value-

Elemente (LEVELS und BITPLANES) stammen aus der QoS-Beschreibung. Das

Style-Sheet kann also aufgrund dieser QoS-Parameter die Adaptierung vornehmen


<DIA>

<Description xsi:type="BSDLinkType">

<SteeringDescriptionRef uri="rubik_lena_AQoS.xml"/>

<BSDRef uri="rubik_lena_gBSD.xml"/>

<BSDTransformationRef uri="rubik_lena_transform.xslt"/>

<Parameter xsi:type="IOPinRefType" name="nLevels">

<Value>LEVELS</Value>

</Parameter>

<Parameter xsi:type="IOPinRefType" name="nBitplanes">

<Value>BITPLANES</Value>

</Parameter>

</Description>

</DIA>

Abbildung 37: Bitstream Syntax Description Link, aus [31]

3.3.3 Terminal and Network Quality of Service

Diese Tools befassen sich mit der Adaptierung der Ressource aufgrund von Quality

of Service-Beschränkungen des Netzwerks und/oder des Terminals.

Abbildung 38 skizziert beispielhaft, wie eine Terminal and Network QoS-

Beschreibung aussehen kann. Im Beispiel wird angegeben, mit welchem

Adaptierungsverfahren (AdaptationOperator) eine bestimmte Bandbreite

(Constraint) erreichen werden kann. Zusätzlich wird zu jeder möglichen

Adaptierung die Peak Signal-to-noise Ratio (PSNR) angegeben, welche ausdrückt,

wie sehr sich das adaptierte Bild vom ursprünglichen unterscheidet und somit einen

Qualitätsmaßstab darstellt. Sie bewegt sich zwischen 20 und 40 und je höher der

Wert ist, desto ähnlicher sind sich die beiden Bilder. Im Beispiel aus Abbildung 38

sehen wir drei verschiedene Adaptierungsverfahren: Das Weglassen von B-Frames


60

(B_FRAMES), P-Frames (P_FRAMES) oder von Koeffizienten der Diskreten

Kosinus-Transformation [38] (COEFF_DROPPING). Bei den ersten beiden

Methoden werden einfach nur Teile des Videostroms weggelassen. Mit dem

Anwenden der Diskreten Kosinus-Transformation wird jeder Block (meist 8x8 Pixel)

in seine Frequenzen zerlegt (die DC-Koeffizienten). Die anschließende

Quantisierung komprimiert ein Bild, indem die DC-Koeffizienten auf ganze Zahlen

gerundet werden. Somit werden weniger Informationen benötigt, um diesen

Bildbereich zu beschreiben und die benötigte Datenmenge wird verringert. In der

dritten Adaptierungsmethode wird eine Anzahl dieser Koeffizienten zur Reduzierung

der Bandbreite weggelassen. Um im Beispiel aus Abbildung 38 eine Bandbreite von

1071kbps zu erreichen, gibt es drei Möglichkeiten, da es drei verschiedene Einträge

im Vector-Element des Constraint-Elementes gibt - an Position fünf, sechs und

sieben. Entweder man lässt Koeffizienten (Position fünf im Vector der

COEFF_DROPPING-Adaptierung), oder B-Frames (Position sechs im Vector der

B_FRAMES Adaptierung) und Koeffizienten weg (Position sechs im Vector der

COEFF_DROPPING Adaptierung), oder man lässt nur B-Frames weg (Position

sieben im Vector der B_FRAMES Adaptierung). Scheint an einer Position im Vector

eine Null auf, so bedeutet dies, dass keine Adaptierung der jeweiligen Art

durchgeführt wird. Wie genau die verschiedenen Werte interpretiert werden, hängt

vom XSLT Style-Sheet (BSDTransformationRef) ab (siehe Abschnitt 3.3.2). Die drei

verschiedenen Adaptierungsmöglichkeiten ergeben einen PSNR-Wert von jeweils

31.58, 30.82 und 28.62. Dies bedeutet, dass die erste Form der Adaptierung das beste

Resultat laut PSNR produziert.

Mit Hilfe dieser Informationen erkennt eine DIA Engine genau, welche

Adaptierungsarten für eine Ressource in Frage kommen, um einer bestimmten

Einschränkung (im obigen Beispiel der Bandbreite) zu entsprechen. Bei der

Adaptierung wird somit Zeit gespart, da die DIA Engine die betreffenden

Informationen nicht mehr selbst errechnen muss, was im Besonderen bei

Echtzeitanwendungen sehr wichtig ist.


61

<DIA>

<Description xsi:type="AdaptationQoSType">

<Header>

<ClassificationAlias alias="AQoS" href="urn:mpeg:mpeg21:2003:01-DIA-AdaptationQoSCS-NS"/>

</Header>

<Module xsi:type="UtilityFunctionType">

<Constraint iOPinRef="BANDWIDTH">

<Values xsi:type="IntegerVectorType">

<Vector>1510 1359 1200 1200 1071 1071 1071 941 814 814 814 1296 1000 1000 1000 842 744 909 712 600 396 359 331 293 255 217</Vector>

</Values>

</Constraint>

<AdaptationOperator iOPinRef="B_FRAMES">


<Vector>0 0 0 1 0 1 2 0 0 1 2 1 0 1 2 1 1 2 2 2 2 2 2 2 2 2</Vector>

</Values>

</AdaptationOperator>

<AdaptationOperator iOPinRef="P_FRAMES">


<Vector>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 4 4 4 4 4</Vector>

</Values>


<AdaptationOperator iOPinRef="COEFF_DROPPING">

<Values xsi:type="FloatVectorType">

<Vector>0.0 0.1 0.21 0.09 0.3 0.2 0.0 0.4 0.5 0.44 0.31 0.0 0.35 0.27 0.08 0.4 0.5 0.2 0.4 0.5 0.0 0.1 0.2 0.3 0.4 0.5</Vector>

</Values>


<Utility iOPinRef="PSNR">

<Values xsi:type="FloatVectorType">

<Vector>34.47 33.56 32.48 31.40 31.58 30.82 28.62 30.27 29.10 28.57 27.53 31.94 30.69 30.15 28.33 29.04 28.11 28.01 27.03 26.49 23.44 23.36 23.29 23.18 23.02 22.87</Vector>

</Values>

</Utility>

</Module>

<IOPin semantics=":AQoS:1.1.1" id="BANDWIDTH" input="true" output="false"/>

<IOPin semantics=":AQoS:2.1" id="PSNR" input="false" output="true"/>

<IOPin semantics=":AQoS:3.1.1" id="B_FRAMES" input="false" output="true"/>

<IOPin semantics=":AQoS:3.1.2" id="P_FRAMES" input="false" output="true"/>

<IOPin semantics=":AQoS:3.1.3" id="COEFF_DROPPING" input="false" output="true"/>

</Description>

</DIA>

Abbildung 38: Terminal und Network QoS-Beschreibung


62

3.3.4 Metadata Adaptability

Dieses Tool soll bei der Transformierung der Beschreibung der Ressource helfen. Es

liefert wichtige Zusatzinformationen über die Beschreibung, um so den

Transformierungsprozess zu erleichtern.

Abbildung 39 gibt eine Beschreibung einer Ressource wieder und Abbildung 41 die

Metadata-Adaptation-Beschreibung, die es leichter machen soll, die Beschreibung zu

transformieren.

Die Beschreibung in Abbildung 39 beschreibt verschiedene Segmente (Szenen) eines

Videos, die teilweise ineinander verschachtelt sind. Es gibt sechs verschiedene

Segmente in diesem Video (long_discussion, personABC, personAB, personA,

personB, personC und personD). In Abbildung 40 ist die Baumstruktur der

Beschreibung zu sehen. Die sechs verschiedenen Segmente sind teilweise ineinander

verschachtelt. Für jedes AudioVisualSegment wird angegeben, wann es beginnt

(MediaTimePoint) und wie lange es dauert (MediaDuration). Außerdem gibt es zu

jedem AudioVisualSegment eine entsprechende Beschreibung (PointOfView und

SupplementalInformation). PointOfView gibt an, worauf die Kamera gerade gerichtet

ist, und SupplementalInformation enthält eine kurze Beschreibung der Szene.

<Mpeg7>

<Description xsi:type="ContentEntityType">

<MultimediaContent xsi:type="AudioVisualType">

<AudioVisual>

<TemporalDecomposition>

<AudioVisualSegment id="long_discussion">

<MediaTime>

<MediaTimePoint>00:00:45</MediaTimePoint>

<MediaDuration>00:06:00</MediaDuration>

</MediaTime>

<PointOfView viewpoint="hall">

<Importance>

<Value>0.0</Value>

</Importance>

<SupplementalInformation>

<FreeTextAnnotation>

Shows a big hall with people in it.

</FreeTextAnnotation>


63

</SupplementalInformation>

</PointOfView>


<AudioVisualSegment id="personABC">

<MediaTime>



</MediaTime>

<PointOfView viewpoint="room">

<Importance>

<Value>0.75</Value>

</Importance>



Persons A, B and C discussing.



</PointOfView>


<AudioVisualSegment id="personAB">

<MediaTime>



</MediaTime>

<PointOfView viewpoint="personAB">

<Importance>

<Value>0.5</Value>

</Importance>



Person A and B talking.



</PointOfView>


<AudioVisualSegment id="personA">

<MediaTime>



</MediaTime>

<PointOfView viewpoint="personA">

<Importance>

<Value>0.25</Value>

</Importance>



Person A talking.



</PointOfView>

</AudioVisualSegment>

</TemporalDecomposition>



64

<AudioVisualSegment id="personB">

<MediaTime>



</MediaTime>

<PointOfView viewpoint="personB">

<Importance>

<Value>1.0</Value>

</Importance>



Person B talking.



</PointOfView>






<AudioVisualSegment id="personC">

<MediaTime>



</MediaTime>

<PointOfView viewpoint="personC">

<Importance>

<Value>0.5</Value>

</Importance>



Person C talking.



</PointOfView>






<AudioVisualSegment id="personD">

<MediaTime>



</MediaTime>

<PointOfView viewpoint="personD">

<Importance>

<Value>0.5</Value>

</Importance>



Person D talking.



65


</PointOfView>





</AudioVisual>

</MultimediaContent>

</Description>

</Mpeg7>

Abbildung 39: Beschreibung einer Ressource

Abbildung 40: Baumstruktur

Abbildung 41 listet nun diese Beschreibung auf. Es wird angegeben, dass die

Beschreibung 4606 Byte groß ist und insgesamt 74 Elemente enthält. Außerdem hat

das AudioVisualSegment eine maximale Verschachtelungstiefe von vier. In jedem

AudioVisualSegment Element ist ein PointOfView Element enthalten, welches

wiederum ein Importance-Element enthält, dessen verschiedene Wertebelegungen

hier angegeben werden.

Der Sinn und Zweck dieser Meta-Beschreibung liegt in der Einschränkung der

Endgeräte. So kann es vorkommen, dass ein Endgerät beispielsweise nur maximal

long_discussion 00:00:45 00:06:45

personABC 00:00:45 00:06:00

personAB 00:00:45 00:03:45

personA 00:00:45 00:02:00

personB 00:02:00 00:03:45

personC 00:03:45 00:06:00

personD 00:06:00 00:06:45


66

10KB Meta-Daten bzw. maximal 50 Elemente verwenden kann. In diesem Fall ist

die Meta-Beschreibung nützlich, da von Anfang an erkannt wird, ob eine

Transformation der Beschreibung nötig ist oder nicht. Zudem enthält sie bereits

wertvolle Hinweise für eine solche Transformation. Im vorangegangenen Beispiel

kann man beispielsweise verschiedene Schichten der Beschreibung auf Basis der

Importance-Werte weglassen.

Eine Adaptation Engine, die diese Metadata-Adaptation Informationen zu

interpretieren weiß, kann den Transformationsprozess somit erheblich

beschleunigen.

<DIA>

<Description xsi:type="MetadataAdaptationType"

instanceSchema="urn:mpeg:mpeg7:schema:2001">

<SizeOfMetadata>4606</SizeOfMetadata>

<TotalNumOfElementes>74</TotalNumOfElementes>

<Component name="AudioVisualSegment" number="7">

<MaxDepth>4</MaxDepth>

<Component name="PointOfView" number="7">

<Component name="Importance">

<Value type="listOfFloat">0.0 0.75 0.5 0.5 0.5 0.25 1.0</Value>

</Component>

</Component>

</Component>

</Description>

</DIA>

Abbildung 41: Metadatenbeschreibung

3.4 Digital Item Declaration Adaptation Tools

Im Gegensatz zu den Digital Item Resource Adaptation Tools (siehe Abschnitt 3.3)

helfen die Digital Item Declaration Adaptation Tools bei der Adaptierung der

Struktur von Digital Items.


67

3.4.1 Session Mobility Tools

Diese halten den aktuellen Zustand des Digital Items fest. Dies wird generell durch

die Selections, die der User im Digital Item gewählt hat, bestimmt. Es wird

beispielsweise angegeben, welche Stelle eines Videos, welches Musikstück eines

Albums oder welches Bild eines Fotoalbums der User gerade konsumiert.

Abbildung 43 zeigt ein Beispiel für die Beschreibung des aktuellen Zustandes eines

Digital Items (Abbildung 42).


68

<DIDL>

<Item id="CONTEXT_DEMO">

<Choice choice_id="EXAMPLE_CHOICE" maxSelections="1">

<Descriptor>

<Statement mimeType="text/plain">Terminal Capabilties</Statement>

</Descriptor>

<Selection select_id="AUDIO">

<Descriptor>

<Statement mimeType="text/plain">Audio</Statement>

</Descriptor>

</Selection>

<Selection select_id="VIDEO">

<Descriptor>

<Statement mimeType="text/plain">Video</Statement>

</Descriptor>

</Selection>

</Choice>

<Component>

<Condition require="AUDIO"/>

<Descriptor>

<Statement mimeType="text/plain">Audio Clip</Statement>

</Descriptor>

<Resource mimeType="audio/mpeg" ref="audio.mp3"/>

</Component>

<Component>

<Condition require="VIDEO"/>

<Descriptor>

<Statement mimeType="text/plain">Video Clip</Statement>

</Descriptor>

<Resource mimeType="video/mpeg" ref="movie.mpg"/>

</Component>

</Item>

</DIDL>

Abbildung 42: Beispiel eines Digital Items, aus [31]

Dieses XDI speichert den aktuellen Zustand des Digital Items für den Fall, dass der

User VIDEO selektiert hat (im Assertion-Element festgelegt). Hat der User AUDIO

gewählt, gibt es ein separates XDI. Deshalb wird im ItemInfo-Element auch auf das

Item[1]/Component[2] verwiesen, was genau der Video-Komponente entspricht

(siehe Abbildung 42). Als nächstes wird der aktuelle Zustand dieser Komponente

beschrieben. Das CurrentPlaybackStatus-Element zeigt an, dass diese Komponente

gerade abgespielt wird. Also muss zusätzlich noch die aktuelle Abspielposition

gespeichert, was durch das CurrentMediaTime-Element geschieht.

69

<DIDL>

<Item>

<Descriptor>

<Statement mimeType="text/xml">

<dii:Type>urn:mpeg:mpeg21:2003:01-DIA-NS:XDI</dii:Type>

</Statement>

</Descriptor>

<Component>

<Resource ref="urn:mpeg:mpeg21:content:smexample"

mimeType="didl/didl"/>

</Component>

<Item id="EXAMPLE_CHOICE_1001245019546">

<Annotation target="EXAMPLE_CHOICE_1001245019546">

<Assertion

target="urn:mpeg:mpeg21:content:smexample#EXAMPLE_CHOICE"

true="VIDEO"/>

</Annotation>

</Item>

<Item>

<Descriptor>

<Statement mimeType="text/xml">

<dia:DIADescriptionUnit

xsi:type="sm:SessionMobilityAppInfoType">

<sm:ItemInfo

target="urn:mpeg:mpeg21:content:smexample#xpointer(DIDL/Item[1]/Component[2])">

<myApp:CurrentPlaybackStatus>

PLAYING

</myApp:CurrentPlaybackStatus>

<myApp:CurrentMediaTime>4.35s</myApp:CurrentMediaTime>

</sm:ItemInfo>

<mpeg7:UsageHistory id="usage-history-001">



</mpeg7:UsageHistory>

</dia:DIADescriptionUnit>

</Statement>

</Descriptor>

</Item>

</Item>

</DIDL>

Abbildung 43: Beschreibung des aktuellen Zustandes eines DI, aus [31]

Mit diesen Informationen können wir den aktuellen Zustand eines Digital Items von

einem Terminal zum anderen transferieren. Somit kann der User sein Digital Item

von beliebigen Terminals in der gleichen Konfiguration konsumieren.


70

3.4.2 DIA Configuration Tools

Diese Tools beschreiben die DIA-Deskriptoren, die für die Adaptierung einer

Ressource benötigt werden und geben außerdem an, wo diese benötigt werden (beim

Server, beim Client oder bei beiden). Darüber hinaus wird festgelegt, wie die

Auswahlmöglichkeiten in Digital Items behandelt werden. Dies wird entweder dem

User überlassen oder automatisch durch einen Agenten erledigt.

Design einer DIA Engine

71

4 Design einer DIA Engine

4.1 Überblick

In diesem Abschnitt wird das Design einer DIA Engine vorgestellt. Die DIA Engine

soll eine Adaptierung eines Digital Items vornehmen, ohne dass ein Eingriff des

Users in den Adaptierungsprozess nötig ist. Mit Hilfe der in Abschnitt 3

beschriebenen Tools erhält die DIA Engine Informationen über die Wünsche des

Users, die Fähigkeiten des Endgerätes und die Parameter des Netzwerkes. Mit diesen

Angaben und der XML-Beschreibung der Ressource kann eine automatische

Adaptierung der Ressource erfolgen.

4.2 Anforderungen

Ein Content Digital Item besteht grundsätzlich aus mindestens einer Ressource und

einer Beschreibung dieser zu adaptierenden Ressource. Daraus ergeben sich die

grundsätzlichen Anforderungen an eine Digital Item Adaptation Engine.

Die Möglichkeiten, die der Standard vorsieht, um diese Adaptierung bzw.

Transformierung vorzunehmen, wurden in Abschnitt 3 bereits ausführlich erläutert.


72

Die DIA Engine sollte einfach, klar programmiert und leicht erweiterbar sein. Sie

soll als Grundlage für zukünftige Entwicklungen dienen. Die Interfaces sollen nicht

restriktiv sein, sondern nur die wichtigsten Methoden festlegen.

4.2.1 Grundsätzliche Funktionalität

Die DIA Engine muss in der Lage sein, sowohl die Beschreibung einer Ressource als

auch die Ressource selbst zu adaptieren.

Transformierung der Beschreibung

Die Transformierung der Beschreibung ist relativ einfach. Durch die MPEG-21-

Standards wird festgelegt, welche Beschreibungselemente in welcher Form

vorkommen dürfen.

Wie im Standard vorgeschlagen, wird ein XSLT Style-Sheet [47] zur Trans-

formierung der Beschreibung verwendet.

Adaptierung der Ressource

Die Adaptierung der Ressource gestaltet sich komplexer. Wie in den vorigen

Abschnitten erläutert, erlaubt der MPEG-21-Standard beliebige Dokumente als

Ressource. Das heißt es gibt eine beliebige Anzahl möglicher verschiedener

Ressourcen, die man möglichst generisch adaptieren will. Wie in Abschnitt 3.3.1

umfassend erläutert, benötigt wird eine generische Beschreibung der Ressource

benötigt, um somit beliebige verschiedene Ressourcen möglichst generisch

adaptieren zu können. Hierzu wird die generic Bitstream Syntax Description (gBSD)

verwendet, die genau zu diesem Zweck entworfen wurde [31]. Jeder Ressource muss

also eine gBSD beiliegen, um eine Adaptierung zu ermöglichen.

Die zu verwendende Syntax zur Beschreibung ist durch das gBS-Schema

vorgegeben, wie in Abschnitt 3.3.1.1 ausführlich erläutert wurde.


73

Art der Adaptierung

Ein Context Digital Item (XDI) enthält zur Adaptierung nützliche Informationen, die

in Abschnitt 3.2 detailliert besprochen wurden. Aus diesem XDI wird dann ein

XSLT Style-Sheet generiert, das zur Transformierung der Beschreibung verwendet

wird (wie in Abschnitt 3.3.1.5 ausführlich erläutert).

4.2.2 Modularität

Eine zusätzliche Anforderung bestand in der Modularität der DIA Engine. Die

einzelnen Schritte der DIA Engine sollten möglichst unabhängig voneinander sein,

damit sie auch ausgetauscht werden können. Dies wiederum sorgt für eine einfache

Erweiterbarkeit. Ein zusätzlicher Aspekt der Modularität ist, dass für die Übergabe

von Objekten zwischen den einzelnen Modulen einheitlich DOM-Nodes verwendet

werden. „Das Document Object Model“ (DOM) beschreibt eine XML-Datei mit

Hilfe einer Baumstruktur, um die Analyse und Modifikation von XML-Dateien zu

erleichtern. Alle Elemente, Attribute und Kommentare einer XML-Datei werden im

Baum als Knoten dargestellt [43].

4.2.3 Anwendungsumfeld

Der Einsatz der DIA Engine ist zumindest an drei verschiedenen Punkten denkbar,

entweder beim User, beim Service Provider oder irgendwo dazwischen im Netzwerk.

Die DIA Engine kann direkt beim Service Provider zum Einsatz kommen. Hierzu

braucht der Server Informationen über den Client, den User und das Netzwerk, die

vom User zum Server transferiert werden müssen. Die Informationen über das

Netzwerk können teilweise auch selbst durch Analysetools gewonnen werden. Durch

eine Adaptierung direkt am Server kann eine unnötige Netzwerkbelastung durch den

Transfer einer nicht angepassten Ressource vermieden werden.

Die Adaptierung kann auch innerhalb des Netzwerkes, zwischen Server und Client

erfolgen. Ein Multimedia-Router könnte Digital Items mit Hilfe der DIA Engine


74

aufgrund von aktuellen Netzwerkparametern adaptieren, während das Digital Item

zum User gesendet wird.

Alternativ dazu kann die DIA Engine am Client zur Anwendung kommen. Da dort

alle Informationen über den User und den Client schon bekannt sind, muss keine

Übertragung dieser Informationen stattfinden.

Idealerweise sollte eine Adaptierung so früh wie möglich geschehen, um unnötige

Netzwerkbelastungen zu vermeiden.

4.3 Entwurfsalternativen

Zu Beginn der Diplomarbeit gingen die Überlegungen in Richtung eines web-

basierten Prototyps, der über einen Web Browser zu bedienen ist. Der User sollte die

Möglichkeit haben, seine Präferenzen festzulegen, welche als Cookies gespeichert

wurden. Mit Hilfe von Cookies kann man kleine Datenmengen auf dem Rechner des

Users speichern, die vom Web Browser verwaltet werden. Der User konnte sowohl

das unmodifizierte Digital Item als XML-Baum betrachten, als auch das „adaptierte“

Digital Item, bei dem nur jene Ressourcen angezeigt wurden, welche seinen

Präferenzen entsprachen. Dies war keine Adaptierung im eigentlichen Sinn, vielmehr

wurden einfach nur jene Ressourcen angezeigt, die den Wünschen des Users bzw.

den Fähigkeiten des Endgerätes entsprachen. Bevor es zu einer Inkludierung „echter“

Adaptierung in diesen Ansatz kam, wurde er aber verworfen, da die Realisierung die

DIA Engine an den Client gebunden und nicht die nötige Transparenz für den User

aufgewiesen hätte. Die grundsätzliche Idee der Steuerung der DIA Engine über einen

Web Browser sollte jedoch nicht aufgegeben werden. Ein Web Interface zur

Steuerung der DIA Engine bzw. Betrachtung des Digital Items am Client ist

durchaus vorstellbar, sie soll allerdings auch problemlos ohne dieses Interface

funktionieren.

Bevor es zum konkreten Design kam, wurde ein zweiter Prototyp, dem Ansatz des

explorativen Prototyping folgend, entwickelt. Dieser hat zwar einige

Grundanforderungen erfüllt, jedoch war die Struktur des Prototypen unübersichtlich


75

und schon gar nicht modular. Es gab kein Design im eigentlichen Sinn, es wurde

vielmehr einfach „drauflos“ programmiert, was zu den genannten Problemen führte.

Nachdem man sich gründlich mit der Thematik auseinandergesetzt hatte, wurde ein

zweites (eigentlich erstes) Design erstellt, welches nach und nach verfeinert wurde

und dem in diesem Abschnitt vorgestellten Design entspricht.

4.4 Entwurf

Der grundsätzliche Ablauf in einer DIA Engine sollte wie folgt aussehen:

1) Parsen und Validieren des Content Digital Items (CDI) 2) Parsen und Validieren des Context Digital Items (XDI) 3) Generieren des XSLT Style-Sheet basierend auf dem XDI 4) Transformieren der gBSD 5) Adaptieren der Ressource 6) Generieren des adaptierten CDI

Im Nachfolgenden wird genauer auf die einzelnen Schritte eingegangen.

4.4.1 Parsen und Validieren des CDI

Abbildung 44 zeigt den ersten Schritt der DIA Engine. Das Content Digital Item

(CDI) wird analysiert und validiert (parse CDI). Bei der Analyse wird darauf

geachtet, dass das CDI der XML-Syntax entspricht. Die Validierung überprüft, ob

das CDI der durch den Standard vorgegebenen Struktur entspricht. Aus dem somit

validierten CDI werden im nächsten Schritt ein Node Pointer auf die gBSD und ein

Node Pointer auf die Ressource extrahiert (extract CDI). Dies kann mit einem XSTL

Style-Sheet erledigt werden (siehe Abschnitt 5.3.1). Generell werden zwischen den

jeweiligen Modulen immer Node Pointer transferiert, was den Austausch der

einzelnen Module erleichtern soll.


76

Abbildung 44: Extrahieren der Ressource und gBSD

4.4.2 Parsen und Validieren des XDI

Im zweiten Schritt wird, wie in Abbildung 45 ersichtlich, das Context Digital Item

(XDI) analysiert und validiert (parse XDI). Aus dem somit validierten XDI wird

dann, falls vorhanden, ein XSLT Style-Sheet extrahiert (extract XDI) und ein Node

Pointer darauf an den XSLT Prozessor weitergereicht. Für das Extrahieren des XSLT

Style-Sheets kann wiederum ein XSLT Style-Sheet verwendet werden (siehe

Abschnitt 5.3.2). Ist kein XSLT Style-Sheet vorhanden, wird ein Node Pointer auf

das validierte XDI an den XSLT Generator weitergereicht.


77

Abbildung 45: Parsen und Validieren des XDI

4.4.3 Generieren des XSLT Style-Sheets

Sollte im XDI kein XSLT Style-Sheet vorhanden sein, so wird es in diesem Schritt

(siehe Abbildung 46) generiert (Description processing). Mit Hilfe der XDI-

Informationen und der gBSD kann ein XSLT Style-Sheet erzeugt werden, das

sowohl den Anforderungen des XDIs genügt, als auch die Einschränkungen der

gBSD beachtet. Anschließend wird das generierte XSLT Style-Sheet an den XSLT

Prozessor weitergegeben.

Abbildung 46: Generieren des XSLT Style-Sheets


78

4.4.4 Transformieren der gBSD

In Abbildung 47 sieht man, wie die gBSD mit Hilfe des XSLT Style-Sheets

transformiert wird. Das XSLT Style-Sheet kommt entweder vom XDI Prozessor oder

vom XSLT Generator und die gBSD vom CDI Prozessor. Ein XSLT Prozessor

transformiert die gBSD gemäß den Angaben im XSLT Style-Sheet (siehe Abschnitt

5.3.3). Danach wird ein Node Pointer auf die transformierte gBSD an das

gBSDtoBin-Modul weitergereicht.

Abbildung 47: Transformieren der gBSD

4.4.5 Adaptieren der Resource

Auf Basis der transformierten gBSD wird nun die Ressource adaptiert (siehe

Abbildung 48). Das Modul analysiert die transformierte gBSD und verändert (bei

Parametern) Bereiche im Bitstrom oder filtert Bereiche im Bitstrom heraus und

entfernt sie (bei gBSDUnits). Außerdem muss die Beschreibung angepasst werden,

da sich ja nun die Bit/Byte-Adressen in den gBSDUnits geändert haben (siehe

Abschnitt 3.3.1.6).


79

Abbildung 48: Adaptieren der Ressource

4.4.6 Generieren des adaptierten CDI

Aus der adaptierten Ressource und der transformierten und aktualisierten gBSD kann

nun ein neues CDI generiert werden (generate CDI). Hierfür kann wiederum ein

XSLT Style-Sheet verwendet werden (siehe Abschnitt 5.3.5). Resultat dieses

Schrittes ist das adaptierte CDI, und damit ist der Adaptierungsprozess ab-

geschlossen.


80

Abbildung 49: Generieren eines neuen CDI

4.4.7 Zusammenfassung des Adaptierungsprozesses

Abbildung 50 zeigt den gesamten Adaptierungsprozess noch einmal in einer Grafik.


81

Abbildung 50: Design der DIA Engine

CDI

XDI

Adapted CDI

parse CDI extract gBSD & Resource

CDI validated

gBSD

Resource

XSLT processing

parse XDIXDI validated

XSLT style sheet extract XSLT

transformed gBSD

gBSDtoBin

adapted Resource

transformed, updated gBSD

generate CDI

API-1: CDIProcessor

API-2: XDIProcessor

API-4:gBSDtoBin

API-5:CDIGenerator

XSLTProcessor

gBSD validated XDIDescription processing

XSLT style sheet

API-3: XSLTGenerator


82

4.5 Evaluierung des Designs

Das in diesem Abschnitt vorgestellte Design ist modular, einfach und leicht

erweiterbar. Alternativ dazu hätte man ein Design entwerfen können, welches sich

auf Performance konzentriert, worauf es ja in einer DIA Engine nicht zuletzt

ankommt. Für diesen Prototyp wurde aber ein klares, modulares Design aufgrund der

zuvor erwähnten Ziele bevorzugt. Das Design wird anhand einer Prototyp-

Implementierung evaluiert. Der Prototyp selbst wird dann anhand von Adaptierungs-

experimenten (siehe Abschnitt 6) getestet.

Implementierung

83

5 Implementierung

Als Implementierungssprache wurde Java verwendet. Zur Transformierung der

XML-Dokumente [42] bot sich XSL Transformations (XSLT) [43], [47] an, eine

Sprache, die genau zum Zweck der Transformierung von XML-Dokumenten ent-

wickelt wurde.

5.1 Projektverlauf

Zu Beginn der Arbeit wurde ein web-basierter Prototyp implementiert, der die

Adaptierung von Digital Items mit Hilfe von „PHP: Hypertext Preprocessor“ (PHP)

[15] vornehmen sollte. Hierzu wurde ein eigener Parser in PHP geschrieben, der ein

Digital Item in einem Web Browser darstellt. Später wurde der eigene Parser durch

eine Referenzimplementierung der Universität von Ghent ersetzt [5]. PHP ist eine

serverseitige Skriptsprache, die besondere Unterstützung für web-basierte Projekte

bietet. Die Alternativen zu PHP waren „Perl“ [20] und „Java Server Pages“ (JSP)

[16]. Auf Perl wurde verzichtet, da diese Sprache zwar sehr mächtig ist, in ihrer

Syntax aber sehr an C anlehnt, was zu schwer verständlichem Source Code führen

kann. Perl ist deshalb eher für kleine, nicht unbedingt web-basierte, Anwendungen

zu empfehlen. Im Unix-Bereich findet Perl als Skriptsprache für die Shell große

Bedeutung. JSP verwendet Java und somit eine High-Level-Programmiersprache, die

gut für Prototyping geeignet ist. Der einzige Grund, warum hier PHP vorgezogen

Implementierung

84

wurde, lag an der größeren Verbreitung und einfacheren Installation von PHP im

Serverbereich. Während nur wenige Server JSP-Support anbieten, ist PHP sehr weit

verbreitet.

Mit dem Fortschritt des Projektes und genauerer Aufarbeitung der Grundlagen von

Digital Items und deren Adaptierung wurde jedoch klar, dass eine web-basierte

Lösung für den endgültigen Prototypen ungeeignet sein würde. Zu Beginn des

Projektes waren die Ziele noch relativ unklar und der erste Prototyp wurde unter der

Annahme programmiert, dass ein „Player“, der ein Digital Item „wiedergibt“, ein

integraler Teil des Projektes sein würde. Später kristallisierte sich jedoch heraus,

dass die Ziele die Adaptierung von Digital Items betreffen, und für diese Art von

Anwendung erwies sich der web-basierte Ansatz als ungeeignet. Eine DIA Engine

soll für den User möglichst transparent sein und muss nicht unbedingt am Endgerät,

sondern eventuell auch am Server oder auf einem Multimedia-Router installiert sein.

Beide Punkte sprachen gegen den web-basierten Ansatz.

Trotzdem konnten aus diesem ersten Prototypen zahlreiche Erfahrungen mit-

genommen werden, da man sich intensiv mit dem Aufbau und der Analyse von

Digital Items befasst hatte.

Die folgenden Abbildungen zeigen diese sehr frühe Implementierung. Man sieht ein

Browserfenster, in dem man die Präferenzen festlegen kann (Abbildung 51), die

dann anhand von Cookies auf dem Computer des Users gespeichert werden.

Außerdem zeigt es das Digital Item als XML-Baum (Abbildung 52).

Implementierung

85

Abbildung 51: User Preferences

Bei dieser frühen Version war das Digital Item noch fest in den Quelltext kodiert und

konnte nicht ausgewählt werden. Man sieht dass das Digital Item verschiedene

Ressourcen beinhaltet, unter anderen MP3-Musikdateien in verschiedenen

Qualitäten. Je nachdem, welche Präferenzen man festgelegt hat, werden nun nur

bestimmte Ressourcen angezeigt. Wenn man angibt, dass das Endgerät nur Audio-

Dateien mit einer maximalen Qualität von 32kbps abspielen kann, so werden nur

diese Dateien aus dem Digital Item angeboten, wie man in Abbildung 53 sehen kann.

In dieser frühen Version wurden die Ressourcen nur in Textform angezeigt.

Aufgrund der bereits genannten Gründe kam es nie zu einer Weiterentwicklung

dieses Prototypen.

Implementierung

86

Abbildung 52: Baumstruktur

Für die weiteren Prototypen wurde Java als Programmiersprache verwendet. Mit

Java kann man den Prototypen relativ problemlos auf unterschiedlichen Plattformen

laufen zu lassen, da eines der Grundprinzipien der Programmiersprache Java die Un-

abhängigkeit von der vorhandenen Hardware bzw. des vorhandenen Betriebssystems

ist. Außerdem bietet Java Objektorientierung und Unterstützung von Schnittstellen,

weshalb es leicht fällt, ein modulares Design in Java umzusetzen. Nicht zuletzt ist

sowohl der verwendete Parser als auch die verwendete gBSDtoBin-Software in Java

implementiert, und die Verwendung von Java hat die Kommunikation mit diesen

Modulen erleichtert.

Implementierung

87

Abbildung 53: „Adaptiertes“ Digital Item

Als nächstes wurde also ein Prototyp in Java implementiert. Die grundlegenden

Anforderungen waren bekannt. Als Entwicklungsmethode wurde exploratives

Prototyping angewendet. Zunächst wurde also die Kernfunktionalität implementiert,

die dann kontinuierlich erweitert wurde. Die mit dem ersten Prototypen gesammelte

Erfahrung erwies sich als wertvoll, und die Entwicklung ging rasch voran. Zum

Schluss hatte man einen Prototypen, der zwar funktionierte, jedoch unübersichtlich

programmiert und schon gar nicht modular war. Er erwies sich dennoch als sehr

nützlich, denn er erfüllte die Anforderungen an eine DIA Engine, man musste nur

noch Struktur schaffen, um Modularität und Erweiterbarkeit zu sichern.

Implementierung

88

Deshalb wurden im nächsten Schritt gründliche Designüberlegungen getroffen, was

letztendlich zum im Abschnitt 4 vorgestellten Design geführt hat. Dieses wurde dann

anhand von Java Interfaces implementiert. Die Java Interfaces geben die

grundlegenden Methoden vor, die ein Modul erfüllen soll, und vor allem werden

einheitliche Interfaces zwischen den Modulen geschaffen. Bei der Implementierung

dieses Designs konnte man viel von der Funktionalität des letzten Prototypen

übernehmen, was die Arbeit erleichterte. Im zuletzt erstellten Prototypen hatte man

ja schon gründlich überlegt und implementiert, wie man die Anforderungen des

MPEG-21-Standards umsetzen kann, nur wurde wenig bzw. gar kein Wert auf ein

gutes Design gelegt. Deshalb waren die eigentlichen Probleme schon gelöst, man

musste die Lösungen nur noch strukturieren. Im Folgenden wird diese

Implementierung detailliert beschrieben.

5.2 Interface-Klassen

Aufgrund des Entwurfes (siehe 4.4) wurden Interface-Klassen in Java [48]

implementiert. Abbildung 54 zeigt ein UML [49] Schema der Interfaces. Im Anhang

(Abschnitt 10.1) befindet sich der Quellcode der Interfaces.

Aus dem Design (siehe Abschnitt 4) wurden die Interface-Klassen und die jeweils

benötigten Interface-Methoden abgeleitet. Es wird angenommen, dass das XDI ein

XSLT Style-Sheet enthält, deshalb wurde die XSLTGenerator-Klasse nicht

implementiert.

Implementierung

89

Abbildung 54: Interface Klassen der DIA Engine

Implementierung

90

5.2.1 CDIProcessor

Das CDIProcessor-Interface deklariert sechs Methoden. Mit Hilfe der setCDI-

Methode bestimmt man das CDI, welches adaptiert werden soll, durch Übergabe

eines Node Pointers auf das CDI. Da ein Digital Item beliebig viele Ressourcen

enthalten darf, muss dem CDIProcessor mitgeteilt werden, welche dieser Ressourcen

adaptiert werden soll. Es wird deshalb davon ausgegangen, dass jede der enthaltenen

Ressourcen einen eindeutigen Identifier besitzt, der im Component-Element

aufscheint. Abbildung 55 präsentiert eine Komponente, die die Ressource (Resource)

und die dazugehörige gBSD (Description) enthält. Zur Identifizierung dieser

Ressource dient das id-Attribut des Component-Elementes („Resource1“). Dem

CDIProcessor muss demnach ein solcher Identifier übergeben werden, was durch die

setResourceID-Methode realisiert wird. Dem CDIProcessor ist nun sowohl das CDI

bekannt, als auch die Information, welche der enthaltenen Ressourcen adaptiert

werden soll. Im darauf folgenden Schritt (parseCDI) wird das CDI analysiert und

validiert, um sicherzustellen, dass es sich um ein korrektes Digital Item handelt

(siehe Abschnitt 4.4.1). Ist dies gewährleistet, können die Ressource und die

dazugehörige Beschreibung aus dem Digital Item extrahiert werden (extractCDI).

Exakter formuliert werden Node Pointer auf die jeweiligen Elemente extrahiert, die

dann über die getDescription-Methode (gBSD) und die getResource-Methode

(Ressource) den anderen Klassen verfügbar gemacht werden.

5.2.2 XDIProcessor

Im XDIProcessor-Interface werden vier Methoden deklariert. Zuerst wird dem

XDIProcessor das zu verwendende XDI mitgeteilt (setXDI). Im nächsten Schritt wird

dieses XDI analysiert, um sicherzustellen, dass es sich um eine gültige XML-Syntax

handelt (parseXDI). Da in der aktuellen Implementierung davon ausgegangen wird,

dass das XDI ein XSLT Style-Sheet enthält, wird im nächsten Schritt dieses XSLT

Style-Sheet aus dem XDI extrahiert (extractXDI) und anderen Klassen über die

getXSLT-Methode zugänglich gemacht.

Implementierung

91

<did:Component id="Resource1">

<did:Descriptor>

<did:Statement mimeType="text/xml">

<dia:DIA>

<dia:Description xsi:type="gBSDType">



</dia:Description>

</dia:DIA>

</did:Statement>

</did:Descriptor>

<did:Resource ref="Content/baby.jp2" mimeType="video/mpeg"/>

</did:Component>

Abbildung 55: Identifizierung der Ressource

5.2.3 XSLTProcessor

Das XSLTProcessor-Interface deklariert ebenfalls vier Methoden. Dem

XSLTProcessor wird die Beschreibung (gBSD) der Ressource (setDescription) und

das XSLT Style-Sheet, welches aus dem XDI extrahiert wurde (setXSLT),

übergeben. Danach wird die Beschreibung mit Hilfe eines XSLT-Processors (siehe

Abschnitt 5.3.3) transformiert (transform). Die transformierte Beschreibung wird den

anderen Klassen durch die getTransformedDescription-Methode zugänglich

gemacht.

5.2.4 gBSDtoBin

Das gBSDtoBin-Interface deklariert fünf Methoden. Zur Adaptierung der Ressource

müssen die Ressource und die transformierte Beschreibung übergeben werden

(setDescription, setResource). Die gBSDtoBin-Software übernimmt dann die

Adaptierung der Ressource (siehe Abschnitt 5.3.4) und die Anpassung der Adressen

in der Beschreibung (siehe Abschnitt 3.3.1.6). Der Aufruf erfolgt Hilfe der

exec_gBSDtoBin-Methode. Die angepasste Beschreibung und die adaptierte

Ressource werden den anderen Klassen über die getUpdatedDescription-Methode

und die getAdaptedResource-Methode zur Verfügung gestellt.

Implementierung

92

5.2.5 CDIGenerator

Im CDIGenerator-Interface werden vier Methoden deklariert. Es erhält die

Ressource und die angepasste Beschreibung als Input (setResource, setDescription)

und generiert (generateCDI) daraus ein neues CDI (siehe Abschnitt 5.3.5). Dieses

wird den anderen Klassen durch die getAdaptedCDI-Methode zugänglich gemacht.

5.3 Eine erste Implementierung der Interface-Klassen

Die folgende Grafik (Abbildung 56) zeigt ein UML-Diagramm [49] der

Implementierungsklassen. Im Anschluss wird genauer auf die jeweiligen Klassen

eingegangen.

5.3.1 CDIProcessorImp

Im CDI-Processor wird vorab das CDI analysiert und validiert (parseCDI-Methode).

Die Validierung findet mit einem DID-Parser statt, der von der Universität von

Ghent (Belgien) für den MPEG-21-Standard entwickelt wurde [5] und beinahe ohne

Modifikationen übernommen werden konnte. Die einzigen Änderungen betrafen die

Import-Pfade für die verwendeten Klassen, die angepasst werden mussten, da sich

die gesamte Implementierung in einem DIAEngine Package befindet. Die Analyse

überprüft, ob das CDI der XML-Syntax entspricht. Die anschließende Validierung

kontrolliert, ob es dem DIDL-Schema entspricht. Nachdem mit Hilfe der

setResourceID-Methode die zu adaptierende Ressource eindeutig identifiziert wurde

(siehe Abschnitt 4.4.1), werden mittels eines XSLT Style-Sheets die gBSD der

Ressource und die DOM-Node, die auf die Resource zeigt, aus dem CDI extrahiert

(extractCDI-Methode).

Implementierung

93

Abbildung 56: Implementierung der Interface-Klassen

Implementierung

94

5.3.2 XDIProcessorImp

Im XDI-Processor wird zuerst das XDI analysiert (parseXDI-Methode). Hier sollte

zusätzlich eine Validierung des XDI stattfinden. Der genaue Aufbau eines XDI ist

derzeit jedoch noch in Entwicklung, weshalb noch keine Validierung möglich ist.

Für diese spezielle Implementierung wird davon ausgegangen, dass das XDI bereits

ein XSLT Style-Sheet enthält, welches zur Transformierung der gBSD herangezogen

werden kann. Dieses wird im nächsten Schritt extrahiert (extractXDI-Methode).

Sobald der Aufbau eines XDI standardisiert ist, kann die extractXDI-Methode

erweitert werden, um die Usage Environment Description-Informationen (siehe

Abschnitt 3.2), die sich im XDI befinden, zu extrahieren. Diese extrahierten

Informationen können dann in einer Implementierung der XSLTGenerator-Klasse

(siehe Abschnitt 4.4.3) zusammen mit der gBSD verwendet werden, um ein XSLT

Style-Sheet zu generieren.

5.3.3 XSLTProcessorImp

Im XSLT-Processor wird die gBSD aus dem CDI mit Hilfe des XSLT Style-Sheets

aus dem XDI transformiert (transform-Methode). Dazu wird der XSLT-Prozessor

„Xalan“ [13] verwendet, der von der „Apache Software Foundation“ [12] entwickelt

wurde. Der XSLT-Prozessor liest hierbei sowohl das XML-Dokument (in diesem

Fall die Beschreibung) als auch das XSLT Style-Sheet ein. Der XSLT-Prozessor

macht sich dabei zunutze, dass jedes wohlgeformte XML-Dokument eine Baum-

struktur aufweist [14]. Er startet somit beim Wurzel-Element und durchwandert den

gesamten Baum. Bei jedem Element wird überprüft, ob es spezielle Anweisungen im

XSLT Style-Sheet gibt, die bestimmen, wie dieses Element transformiert werden

soll. Gibt es solche Direktiven nicht, wird das Element einfach kopiert. So entsteht

ein zweiter Baum, der das transformierte XML-Dokument darstellt.

5.3.4 gBSDtoBinImp

In der gBSDtoBin-Klasse wird die Ressource mit Hilfe des transformierten XSLT

Style-Sheets adaptiert und die gBSD an die neue Resource angepasst

Implementierung

95

(exec_gBSDtoBin-Methode), da sich nun die Bit/Byte-Adressen in den gBSDUnits

geändert haben (siehe Abschnitt 3.3.1.6).

Bei der Adaptierung der Ressource vergleicht die gBSDtoBin-Methode den Bitstrom

der Ressource mit der transformierten Beschreibung. Überall, wo in der Beschreib-

ung Elemente weggelassen (bei gBSDUnit-Elementen) oder verändert (bei Para-

meter-Elementen) wurden, wird dies auch im Bitstrom angepasst. Da im Bitstrom

keine „Löcher“ auftreten dürfen, verändern sich durch die Adaptierung die Byte-

Adressen der einzelnen Elemente. Dies muss auch in der Beschreibung angepasst

werden.

Die Adaptierung der Ressource und die Anpassung der gBSD übernimmt die

gBSDtoBin-Software, die in Zusammenarbeit der Universität Klagenfurt (Österreich)

und der Siemens AG München (Deutschland) entstanden ist [6]. Diese Software

wurde im Rahmen der Diplomarbeit noch um einige Funktionalitäten erweitert, die

für die Verwendung in der DIA Engine benötigt wurden. So wurde beispielsweise

die Möglichkeit geschaffen, als Adressierungseinheit auch Bit und nicht nur Byte zu

verwenden.

5.3.5 CDIGeneratorImp

Im CDI-Generator wird aus der adaptierten Ressource, der transformierten und

angepassten gBSD und dem ursprünglichen CDI ein neues CDI generiert

(generateCDI-Methode). Hierzu wird wiederum ein XSLT Style-Sheet verwendet.

5.3.6 DIAEngineWrapper

Der DIA Engine-Wrapper ist eine Wrapper-Klasse, die als Input ein CDI und ein

XDI erhält (setCDI-Methode und setXDI-Methode) und anschließend sämtliche

benötigte Methoden der DIA Engine aufruft, um das CDI zu adaptieren (adapt-

Methode).

Implementierung

96

5.3.7 DIAEngineParameters

Die DIA Engine-Parameters Klasse enthält Parameter für die DIA Engine. Derzeit

wird hier der aktuelle Debug-Level verwaltet, der bestimmt, ob die DIA Engine

Debug-Informationen ausgibt und wenn ja, wie viele (Debug-Level 0, 1 oder 2 sind

möglich, wobei 2 die meisten Informationen ausgibt).

5.4 Entwicklungsstand

Auch dieser Prototyp ist noch nicht vollständig. Das größte Verbesserungspotential

liegt im XSLTGenerator-Modul, welches überhaupt nicht implementiert wurde. Der

Prototyp geht davon aus, dass im XDI bereits ein XSLT Style-Sheet (und zwar genau

das richtige für die jeweilige Ressource) vorhanden ist, welches er zur Adaptierung

des Digital Items verwenden kann. Dies ist unrealistisch. In einer fertigen DIA

Engine muss das passende Style-Sheet entweder aus einer Menge von Style-Sheets

ausgewählt oder neu generiert werden. Die Auswahl bzw. Generierung hängt von der

Ressource und den DIA Tools ab, die Informationen über User, Endgerät und

Netzwerk bereitstellen. Es ist vorstellbar, dass eine Menge von Style-Sheets in einer

Datenbank gespeichert und kategorisiert ist. Eine mögliche Anfrage der DIA Engine

könnte dann wie in Abbildung 57 aussehen.

Select * from style_sheets where ressource_type=’jpeg-2000’ and

adaptation_method=’resolution’;

Abbildung 57: Mögliche Anfrage an eine Datenbank

Diese Anfrage würde ein parametrisierbares Style Sheet zur Skalierung von JPEG-

2000 Bildern zurückgeben. Die DIA Engine würde es mit den nötigen Parametern

aufrufen (um welchen Faktor es skaliert werden soll) und das Style Sheet würde die

XML-Beschreibung der Ressource transformieren, mit deren Hilfe die gBSDtoBin-

Software im Anschluss die Anpassung der Ressource vornimmt. Der

Implementierung

97

adaptation_method-Parameter muss mit Hilfe der DIA Tools ausgewählt werden,

abhängig von den Wünschen des Users, den Fähigkeiten des Endgerätes und den

Rahmenbedingungen des Netzwerks.

Des Weiteren beschränkt sich der Prototyp auf die Adaptierung der Ressource und

deren Beschreibung. In Abschnitt 3 werden Tools für die Festlegung einer

bestimmten Konfiguration eines Digital Items beschrieben, was die Digital Item

Declaration betrifft. Derzeit wird aber nur eine Adaptierung der Ressource selbst

oder der Beschreibung dieser Ressource unterstützt.

Es gibt also noch einige Bereiche, in denen der Prototyp verbessert bzw.

vervollständigt werden kann, aber er reicht aus, um die prinzipielle Funktionalität der

DIA Engine zu zeigen. Im Folgenden werden Beispiele der Adaptierung mit Hilfe

des Prototypen gezeigt.

Evaluierungsexperimente

98

6 Evaluierung des Prototypen

Die Evaluierungsexperimente wurden auf einem PC mit AMD Athlon XP 2600+

Prozessor (2,08 GHz) und 1 GB RAM durchgeführt. Als Betriebssystem wurde

Windows XP verwendet. Für die Kompilierung und Ausführung der Programme

wurde das Java Development Kit 1.4.1 für Windows verwendet.

6.1 Adaptierung der Auflösung

In diesem Beispiel wird die DIA Engine anhand eines Digital Items mit einer JPEG-

2000-Ressource evaluiert. Die Ressource wird anhand der Auflösung adaptiert. Es

wird betrachtet, wie lange die einzelnen Module für die jeweilige Adaptierung

benötigen und wie sich die Größe der Ressource und der Beschreibung während der

Adaptierung ändert.

JPEG-2000 ist ein Format, welches viele Möglichkeiten zur Skalierung anbietet. Bei

der Kodierung eines JPEG-2000-Bildes werden die Subbänder jeder

Farbkomponente des Bildes errechnet. Dies geschieht mit einer Wavelet-

Transformation (Discrete Wavelet Transformation). In Abbildung 58 werden die

Subbänder der Y-Komponente eines Bildes mit YCbCr Farbschema gezeigt. Dieses

Verfahren ermöglicht eine rasche Skalierung der Auflösung. Zur Skalierung werden


99

einfach die Dimensionen des Bildes im Header angepasst (siehe Abbildung 59) und

jene Pakete verworfen, die zu einem Subband gehören, welches für die aktuelle

Auflösung nicht benötigt wird.

Abbildung 58: Berechnung der Subbänder einer Komponente

...

<Parameter name=":J2K:Xsiz" length="4">


</Parameter>

<Parameter name=":J2K:Ysiz" length="4">


</Parameter>

...

Abbildung 59: XML-Beschreibung der Dimensionen eines JPEG-2000-Bildes

Wenn man die XML-Beschreibung genauer betrachtet, erkennt man, wie oft ein Bild

in seine Subbänder zerlegt wurde. Bei Betrachtung des marker-Attributs in

Abbildung 60 erkennt man, wie viele Subbänder es von diesem Bild gibt. Wie man

in Abbildung 58 erkennt, halbiert jede Berechnung der Subbänder die Auflösung des

Bildes. Lässt man also die Subbänder mit dem marker-Attribut „R5“ weg (und passt

die Auflösung im Header entsprechend an), so wird die Auflösung halbiert. Natürlich

müssen auch alle Pakete gelöscht werden, die zu den Subbändern mit dem marker-

Attribut „R5“ gehören, was einfach ist, da alle Pakete wiederum ein marker-Attribut

aufweisen, in dem unter anderem die Subband-Zugehörigkeit vermerkt ist (siehe


100

Abbildung 61). Eine genaue Beschreibung des JPEG-2000-Kodierformates findet

man in [43].

...

<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R0"/>
















</gBSDUnit>

...

Abbildung 60: Die Subbänder eines JPEG-2000-Bildes

...

<gBSDUnit syntacticalLabel=":J2K:Packet" start="3385" length="9" marker="R0 L31 C2 P0">

<Header>


</Header>


<Parameter name=":J2K:Nsop" length="2">


</Parameter>


</gBSDUnit>


...

</gBSDUnit>

...


...

</gBSDUnit>

...

Abbildung 61: Pakete mit marker-Attribut


101

Im Experiment wird das Bild aus Abbildung 62 viermal skaliert. Beim Bild handelt

es sich um ein JPEG-2000-Bild mit einer Farbtiefe von 24 Bit und einer Auflösung

von 1024x768 Pixel.

Abbildung 62: Skalierung der Auflösung

Abbildung 63 zeigt die Ergebnisse der Zeitmessung. Wie erwartet nimmt das

gBSDtoBin-Modul die meiste Zeit in Anspruch, gefolgt vom CDIProcessor. Der

hohe Anteil des CDIProcessors ergibt sich daraus, dass das Digital Item zweimal

analysiert wird: Einmal, um die Beschreibung der Ressource zu finden, und ein

weiteres mal, um die Ressource selbst zu finden. Hier kann auf jeden Fall noch

optimiert werden.


102

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

1024x768 -> 512x384 512x384 -> 256x192 256x192 -> 128x96 128x96 -> 64x48

Skalierungsschritt [Pixel]

Zeitb

edar

f [M

illis

ekun

den]

CDIGeneratorgBSDtoBinXSLTProcessorXDIProcessorCDIProcessor

Abbildung 63: Zeitmessung – Adaptierung eines Digital Items anhand der Auflösung

In Abbildung 64 wird verdeutlicht, wie sich die Größe der Ressource und der

Beschreibung durch die Adaptierungen verändern. Ein Problem, welches hier

deutlich wird, ist die Größe der Beschreibung der Ressource. Je besser eine

Ressource skalierbar ist, desto genauer kann sie auch beschrieben werden. Dies

bringt zwar den Vorteil, dass die Ressource rasch und auf viele Arten skaliert werden

kann, jedoch wächst die Beschreibung der Ressource natürlich auch entsprechend

stark. Eine mögliche Problemlösung liegt in der Komprimierung der Beschreibung

der Ressource. Da es sich bei der Beschreibung um Text handelt, könnte ein sehr

hoher Komprimierungsfaktor erreicht werden. Die Beschreibung könnte dann nicht

mehr direkt im Digital Item aufscheinen, sondern wäre separat in einer Datei (wie

beispielsweise die Ressource) lokalisiert, die durch eine Referenz in das Digital Item

inkludiert wird. Damit würde man viel Platz gewinnen, jedoch auch Zeit verlieren,

da die Beschreibung bei einer Skalierung zuerst dekomprimiert werden müsste.


103

0

100000

200000

300000

400000

500000

600000

700000

1024x768 512x384 256x192 128x96 64x48

Auflösung [Pixel]

Grö

ße [B

yte]

Ressource

Beschreibung

Abbildung 64: Größenvergleich von Beschreibung und Ressource

6.2 Adaptierung der Farbtiefe

In diesem Beispiel werden die einzelnen JPEG-2000-Bilder aus dem vorigen

Beispiel noch einmal adaptiert, indem ihre Farbtiefe von 24 Bit auf 8 Bit

(Graustufen) skaliert wird (Abbildung 65).


104

24 Bit Farbtiefe 8 Bit Farbtiefe

Abbildung 65: Skalierung der Farbtiefe

Wie bereits in Beispiel 1 erwähnt, wird ein Bild, wenn es mit JPEG-2000 kodiert

wird, zuerst in seine Farbkomponenten aufgeteilt. Liegt ein Bild im YCbCr-

Farbschema vor oder wird es beim JPEG-2000-Kodierungsprozess in dieses

Farbschema umgewandelt, so bietet sich dadurch eine sehr einfache Möglichkeit, das

Bild in Graustufen umzuwandeln. Beim YCbCr-Farbschema würde das Bild aus drei

Komponenten bestehen, einer Y-Komponente, einer Cb-Komponente und einer Cr-

Komponente, die alle getrennt voneinander verarbeitet werden. Die Y-Komponente

gibt die Helligkeitsverteilung (Luminance) im Bild an und ist somit eine

Graustufendarstellung des Bildes. Zur Umwandlung eines YCbCr-Bildes in

Graustufen müssen somit nur die Cb- und Cr-Komponenten aus dem Header gelöscht

und alle Pakete, die zu diesen Komponenten gehören, verworfen werden. Abbildung

66 zeigt die Auflistung der Komponenten in der XML-Beschreibung des Bildes.

Komponente eins mit dem marker-Attribut „C0“ entspricht der Y Komponente,

welche bei einer Graustufenkonvertierung beibehalten werden soll. Die

Komponenten mit dem marker-Attribut „C1“ und „C2“ entsprechen den Cb- und Cr-

Farbkomponenten und können verworfen werden.


105

...

<Parameter name=":J2K:Csiz" length="2">


</Parameter>




</gBSDUnit>

...

Abbildung 66: Komponenten eines JPEG-2000-Bildes

Natürlich müssen auch alle Pakete, die zu diesen Komponenten gehören, verworfen

werden. Jedes Paket hat ein marker-Attribut, in dem unter anderem angegeben ist, zu

welcher Komponente es gehört (siehe Abbildung 67). Somit fällt das Löschen der

entsprechenden Pakete leicht.

...


<Header>


</Header>


<Parameter name=":J2K:Nsop" length="2">


</Parameter>


</gBSDUnit>


...

</gBSDUnit>


...

</gBSDUnit>

...

Abbildung 67: Pakete mit marker-Attribut

Die Zeitmessung (siehe Abbildung 68) ergibt ein ähnliches Bild wie im vorherigen

Experiment. Der Vorgang ist im Durchschnitt drei Sekunden schneller als die


106

Skalierung der Auflösung. Weiters ist gut zu sehen, dass eine Optimierung des

CDIProcessor-Moduls den gesamten Prozess um einiges beschleunigen könnte – bei

geringen Auflösungen nimmt das CDIProcessor-Modul sogar die meiste Zeit in

Anspruch.

0

1000

2000

3000

4000

5000

6000

1024x768 512x384 256x192 128x96 64x48

Auflösung [Pixel]

Zeitb

edar

f [M

illis

ekun

den]

CDIGenerator

gBSDtoBin

XSLTProcessor

XDIProcessor

CDIProcessor

Abbildung 68: Zeitmessung – Adaptierung eines Digital Items anhand der Farbtiefe

Insgesamt ergibt sich ein ähnliches Bild wie im letzten Experiment. Schon zu Beginn

ist die Beschreibung nahezu genauso groß wie die Ressource. Bei kleineren

Ressourcen ist die Beschreibung zwar auch kleiner, jedoch schrumpft die Ressource

wesentlich schneller als die Beschreibung. Im letzteren Fall ergibt sich ein

Graustufenbild mit 64x48 Pixel, dessen Beschreibung mehr als zehnmal so groß ist

als die Ressource (Abbildung 69).


107

0

50000

100000

150000

200000

250000

1024x768 512x384 256x192 128x96 64x48

Auflösung [Pixel]

Grö

ße [B

yte]

RessourceBeschreibung


Abbildung 70 zeigt einen direkten Vergleich der Größe der CDIs bei einer 24-Bit-

Ressource und bei einer 8-Bit-Ressource. Die Größe des CDI ergibt sich aus der

Größe der Beschreibung der Ressource, der Ressource selbst und der Beschreibung

des CDI (die DID). Die DID (siehe Abschnitt 2.2.1) wurde in den bisherigen Ab-

bildungen nicht berücksichtigt, da sie immer gleich groß und außerdem zu klein ist,

um im Diagramm aufzuscheinen (ca. 2000 Byte in diesen Beispielen). Abbildung 70

veranschaulicht, dass durch eine Graustufenskalierung die Größe des Digital Items

um den Faktor zwei bis drei verkleinert werden kann. Zudem ist eine

Graustufenskalierung um ein Drittel schneller als eine Skalierung der Auflösung auf

die Hälfte. Muss also skaliert werden und hat man dabei die Wahl, ob man auf die

nächst kleinere Auflösung skaliert oder eine Graustufenskalierung anwendet, wäre

die Graustufenskalierung also der schnellere Weg, der auch noch um einiges mehr

Platz spart. Allerdings muss auch bedacht werden, dass der User unter Umständen

ein kleineres Farbbild einem größeren Graustufenbild vorzieht – dies ist von den

UserPreferences abhängig.


108

0

100000

200000

300000

400000

500000

600000

700000

1024x768 512x384 256x192 128x96 64x48

Auflösung [Pixel]

Grö

ße [B

yte]

CDI 24 BitCDI 8 Bit

Abbildung 70: Vergleich – Digital Item mit 8 Bit & 24 Bit Ressource

6.3 Adaptierung eines Videos

Selbstverständlich können nicht nur Bilder skaliert werden. Im folgenden Beispiel

wird die DIA Engine anhand eines Digital Items, welches ein MPEG-4-Video als

Ressource beinhaltet, evaluiert. Im Gegensatz zum vorhin beschriebenen JPEG-

2000-Bild bietet dieser Videostrom nur eine Möglichkeit zur Skalierung – das

Verwerfen von Frames. In einem MPEG-4-Videostrom können drei unterschiedliche

Arten von Frames vorkommen [4]. Die Intra Frames (I-Frames) sind Frames, die sich

unabhängig von anderen Frames dekodieren lassen - also komplette Bilder,

vergleichbar mit einem JPEG-Bild. Die Predictive Frames (P-Frames) hängen vom

vorherigen P-Frame oder I-Frame ab. In einem P-Frame wird nur der Unterschied

zum vorhergegangenen P- oder I-Frame gespeichert. Bidirectional Frames (B-

Frames) sind mit P-Frames vergleichbar, allerdings können sie nicht nur vom letzten

P- oder I-Frame abhängen, sondern auch vom nächsten P- oder I-Frame. Das


109

wichtigste an B-Frames ist jedoch, dass keine anderen Frames von ihnen abhängen.

Würde man beispielsweise einen I-Frame verwerfen, so würde das dekodierte Video

bis zum nächsten I-Frame gravierende Fehler aufweisen, da die dazwischen

liegenden P- und B-Frames ja nur die Unterschiede zum verworfenen I-Frame

beinhalten. Das Verwerfen eines P-Frames hätte einen ähnlichen Effekt, er würde

jedoch nicht so lange andauern wie bei einem I-Frame (P-Frames kommen

normalerweise wesentlich öfter vor als I-Frames). Verwirft man hingegen einen B-

Frame so hat dies keine tragischen Auswirkungen, da kein anderer Frame von ihm

abhängt. Die Qualität des Videos wird ein wenig sinken, eventuell ruckelt es kurz, es

gibt aber keine längerfristigen Auswirkungen.

In diesem Beispiel wurde das Verwerfen von B-Frames anhand eines 25.825.570

Byte großen Videos mit dem Titel „Big Show One“ analysiert. Der Videostrom

besteht aus 47 I-Frames, 2610 P-Frames und 3629 B-Frames. In diesem Beispiel

wurden sämtliche B-Frames verworfen. Im konkreten Anwendungsfall würden nicht

sofort alle B-Frames verworfen werden, sondern zunächst beispielsweise nur jeder

zweite, damit die Qualität des Videostroms nicht zu sehr leidet.

Abbildung 71 zeigt, dass das Herausfiltern aller B-Frames aus dem Videostrom ca.

12 Sekunden gedauert hat. Diese Technik wird heutzutage in vielen Streaming-

Anwendungen in Echtzeit angewendet, beispielsweise beim „Darwin Streaming

Server“ von Apple [38]. Auf diese Weise kann Bandbreite gespart werden. Bei

mobilen Endgeräten, die aus Leistungsgründen nicht alle Frames in der

erforderlichen Geschwindigkeit dekodieren können, wird diese Technik zur

Entlastung der Ressourcen des Endgerätes verwendet.


110

Abbildung 71: Zeitmessung – Adaptierung eines Digital Items mit Frame-Dropping

In Abbildung 73 ist ersichtlich, dass, anders als bei JPEG-2000, die Beschreibung

hier nur einen sehr geringen Teil des Digital Item ausmacht. Bei Videoströmen

werden die einzelnen Frames nicht beschrieben, sondern nur, wo sich ein Frame

befindet und welchem Typ er angehört (siehe Abbildung 72). Dies bringt den Vorteil

einer relativ kleinen Beschreibung, aber natürlich auch den Nachteil, dass bei der

Skalierung nicht viele Auswahlmöglichkeiten existieren. Die einzige Möglichkeit,

die man in diesem Videostrom hat, ist das Verwerfen von Frames.

<gBSDUnit start="13540" length="513703">



...



</gBSDUnit>

Abbildung 72: gBSD eines Videos


111

0

5000000

10000000

15000000

20000000

25000000

30000000

Mit B-Frames B-Frames verworfen

Grö

ße [B

yte]

RessourceBeschreibung


6.4 Weitere Experimente

Natürlich kann nicht nur aufgrund von Beschränkungen des Endgerätes oder des

Netzwerks skaliert werden. Im Rahmen der Diplomarbeit wurden auch Experimente

zur qualitativen Skalierung von Ressourcen durchgeführt. In einem Videostrom

können beispielsweise einzelne Szenen (eine Menge von Frames) in eine gBSDUnit

verschachtelt und mit einem marker versehen werden, der den Inhalt der jeweiligen

Szene beschreibt. Mit Hilfe der DIA Engine können dann bestimmte Szenen

aufgrund ihrer Beschreibung aus dem Videostrom entfernt werden.

Abbildung 74 zeigt so eine Szene mit einem Marker. Im Marker wird die Eignung

der Szene für Minderjährige auf einer Skala von null bis sechs beschrieben. Eine

DIA Engine kann nun diese Szenen auf Wunsch des Users herausfiltern - ähnlich wie


112

es auch im vorigen Beispiel mit den B-Frames geschehen ist. Gesteuert wird dies

über die ContentPreferences des UserPreferences-Tools (siehe Abschnitt 3.2.1).

<gBSDUnit start="13540" length="513703" marker="ICRAParentalRatingNudityCS-6">



...



</gBSDUnit>

Abbildung 74: Markierung von Szenen in einem Video

6.5 Diskussion

Insgesamt wurden drei verschiedene Prototypen entwickelt. Dies hätte vermieden

werden können, indem man von Beginn an die Anforderungen korrekt erhoben und

in ein Design umgesetzt hätte, wie es beim dem dritten Prototypen geschah.

Andererseits wurden durch die Programmierung der ersten beiden Prototypen

wertvolle Erfahrungen gesammelt, die bei der Implementierung des dritten

Prototypen geholfen haben. Der endgültige Prototyp ist modular, einfach und klar

programmiert, was es leicht machen sollte, dessen Aufbau in kurzer Zeit zu

überblicken. Durch seine Modularität und einheitlichen Schnittstellen ist es auch

einfach, weitere Module hinzuzufügen oder bestehende Module auszutauschen.

In Anbetracht dieses Prototypen kann man nun auch beginnen etwas weiter zu

blicken und zu diskutieren wie diese DIA Engine in der Praxis arbeiten kann, bzw.

wie ein MPEG-21 Client oder sogar das gesamte Framework aussehen könnten.

Nicht immer wird die Adaptierung von Ressourcen am Server oder auf einem

Multimedia-Router geschehen können. Oft wird sie erst am Endgerät erfolgen,

weshalb die DIA Engine auf jeden Fall in jedem MPEG-21 Client integriert sein

sollte. Gleichzeitig sollte sie aber auch eigenständig arbeiten können, denn auf dem

Server oder auf einem Multimedia-Router wird kein MPEG-21 Client inklusive

Abspielmöglichkeiten und anderer Features, sondern nur die DIA Engine benötigt.


113

Wenn die DIA Engine in allen MPEG-21 Clients enthalten sein soll, so muss sie sehr

flexibel sein. Es kann vorkommen, dass auf einem Endgerät nur wenige Ressourcen

zur Verfügung stehen, beispielsweise wird auf einem mobilen Endgerät (z.B. einem

Handy) nur sehr wenig Speicherplatz zur Verfügung stehen. Während es natürlich

möglich ist, die einzelnen Module des Prototypen einzeln zu laden (z.B. von einem

Remote-Server), auszuführen und danach bis zum nächsten Einsatz wieder zu

löschen, so ist dies nicht sehr effizient. Bei den Style-Sheets zur Transformierung

kann man aber durchaus flexibel sein. Man könnte der DIA Engine Style-Sheets für

die wichtigsten Datenformate beilegen. Sobald ein Datenformat nicht erkannt wird,

stellt die DIA Engine eine Anfrage an einen Remote-Server, um das gesuchte Style-

Sheet (falls vorhanden), zu erhalten (siehe Abschnitt 5.4, Abbildung 57). Auf diese

Weise könnte die Größe der DIA Engine so klein wie möglich gehalten werden.

Betrachten wir nun die MPEG-21 Clients. Wie in Abschnitt 1.3 festgestellt wurde,

müssen diese bestimmte Grundfunktionalitäten erfüllen, die in Module unterteilt

werden können. Ein User mit einem sehr eingeschränkten Endgerät, wie

beispielsweise dem oben erwähnten Handy, wird unter Umständen nur daran

interessiert sein, nach Digital Items zu suchen und sie zu beziehen. Die anderen

Funktionalitäten (Erstellen, Verändern und Anbieten) werden ihn weniger

interessieren bzw. aufgrund der Einschränkungen des Endgerätes gar nicht möglich

sein.

Wie sieht es nun mit den DIA Engines am Server oder auf einem Multimedia Router

aus? Wenn der Server keine DIA Engine installiert hat, so lädt der Client das Digital

Item einfach herunter. Er kann dafür herkömmliche Internet Protokolle wie

beispielsweise das Hypertext Transfer Protocol (HTTP) [35] oder das File Transfer

Protocol (FTP) [33] verwenden. Zuerst wird dabei die DID des Digital Items geladen

und dann analysiert, um die entsprechenden Ressourcen zu laden. Hier kann dem

User bereits angeboten werden, nur jene Ressourcen zu laden, die ihn interessieren.

Sollte am Server eine DIA Engine installiert sein, so könnten vor dem Herunterladen

des Digital Items Informationen über das Endgerät und den User an den Server

gesendet werden. Natürlich werden nur jene Informationen übertragen, die vom User


114

freigegeben wurden, um Missbrauch zu vermeiden. Mit Hilfe dieser Informationen

könnte die DIA Engine die Adaptierung direkt am Server vornehmen, bevor das

Digital Item zum Client gesendet wird, um Bandbreite zu sparen. Falls

Informationen über das Netzwerk verfügbar sind, können auch diese für die

Adaptierung verwendet werden. Dies wird jedoch eher auf einem Multimedia-Router

geschehen, da dort üblicherweise mehr Informationen über das Netzwerk vorhanden

sind.

Bisher wurde davon ausgegangen, dass dem Client bekannt ist, wo sich das

gewünschte Digital Item befindet. Dies ist durchaus realistisch, wenn von einem

Service Provider gesprochen wird, der seine Digital Items über eine Internet Seite

mit Suchfunktion anbietet. Was ist aber mit einem User, der nicht auf die

Möglichkeiten eines Service Providers zurückgreifen kann, seine Digital Items aber

dennoch gerne anbieten möchte? Außerdem sollen User ja die Möglichkeit haben,

generell nach Digital Items zu suchen und nicht nur nach jenen, die zufällig von

einem Service Provider angeboten werden (siehe Abschnitt 1.3). Idealerweise sollte

ein Client in der Lage sein, Digital Items freizugeben und zwar unter den

Gesichtspunkten des „Content Handling and Usage“ und insbesondere des

„Intellectual Property Management and Protection“ Kernbereiches (siehe Abschnitt

2.2.3 und 2.2.4). Allen Clients sollten es möglich sein nach solchen freigegebenen

Digital Items zu suchen. Irgendwie muss man Clients also die Möglichkeit geben,

Informationen über freigegebene Digital Items im gesamten Framework zu erhalten.

Um dies zu erreichen, können verschiedene Ansätze verfolgt werden - von

zentralisiert bis dezentralisiert.

Ein vollkommen zentralisierter Ansatz wäre, alle freigegebenen Digital Items auf

einem einzigen Server zu verwalten. Abgesehen davon, dass dies einen „Single Point

of Failure“ (SPOF) schaffen würde, würde dieser Server große Mengen an

Ressourcen benötigen. Vielen Usern würde es außerdem nicht gefallen, dass ihre

Digital Items auf einem Server verwaltet werden, der nicht unter ihrer Kontrolle

steht. Man könnte diesen Ansatz verbessern, indem man die Digital Items auf


115

mehrere Server aufteilt, eventuell sogar mit Redundanz, was den SPOF verringern

würde, nicht jedoch die anderen Probleme.

Der nächste, etwas weniger zentrale, Ansatz besteht darin, nur Meta-Informationen

auf den zentralen Server(n) zu verwalten. Beispielsweise könnte man nur die DID

auf den Servern speichern, die Ressourcen selbst aber bei den Usern belassen. Man

könnte somit natürlich nur auf die Ressourcen zugreifen, wenn der entsprechende

User online ist, man würde aber weitaus weniger Ressourcen auf den Servern

benötigen. Der SPOF könnte ebenfalls verringert werden, da bei kleineren

Speicherbedarf (es werden ja nur die DIDs am Server abgelegt) viel einfacher und

vor allem billiger Redundanz eingeführt werden kann.

Wenn dieser Ansatz weiter verfolgt wird, kann man natürlich auch nur den Titel (und

andere wichtige Informationen) über das Digital Item auf dem Servern speichern und

zusätzlich noch die IP-Adresse des Users. Dies würde noch mehr Ressourcen auf den

Servern sparen. Allerdings wären die Zusatzinformationen, die durch die

vollständige DID gewonnen werden können, schon angenehm und wenn wirklich

Ressourcenknappheit besteht, könnte die DID gut komprimiert werden, da es sich

um Text handelt.

Die minimalste Version des zentralisierten Ansatzes speichert nur die IP-Adressen

der User am Server. Wenn ein Client nach einem Digitalem Item sucht, müsste er

dann jedoch sämtliche Clients, die gerade online sind, kontaktieren und anfragen, ob

sie ein Digital Item mit den gewünschten Eigenschaften besitzen – nicht sehr

effizient. Dennoch würde diese Version eine maximale Redundanz erlauben, da die

Adressen nur sehr wenig Platz benötigen.

All diese Ansätze sind zentralisiert. Alternativ könnte man sich natürlich einen

vollkommen dezentralisierten Peer-To-Peer (P2P)-Ansatz [24] überlegen. Bei P2P

gibt es keine dedizierten Server. Jeder Client ist zugleich Server und speichert

eventuell auch Informationen, um andere Clients zu erreichen. Wenn ein Client ein

Digital Item mit bestimmten Eigenschaften sucht, könnte er einen Broadcast im

Netzwerk losschicken und einfach auf Antworten warten. Da im Internet kein


116

Broadcast im herkömmlichen Sinn möglich ist, scheint sich dieser Ansatz eher für

kleinere Netze mit Broadcast-Möglichkeit zu eignen. Dennoch ist auch eine leicht

abgewandelte Version denkbar, die über das Internet funktionieren kann. Jeder

Client speichert sämtliche Adressen aller Clients, mit denen er je Kontakt hatte.

Wenn der Client nach einem Digital Item sucht, sendet er einfach eine Anfrage an

sämtliche Clients, die sich auf seiner Liste befinden. Diese senden die Anfrage dann

wiederum an alle Clients auf deren Liste usw. Dieser Ansatz wäre dezentral, jedoch

nicht sehr effizient, da jeder Client die gleiche Anfrage unter Umständen sehr oft

erhalten würde (wenn er sich auf der Liste vieler anderer Clients befindet).

Außerdem kann es dazu kommen, dass Anfragen „im Kreis“ wandern, weshalb man

einen Parameter einführen muss, der bestimmt wie viele „Hops“ eine Anfrage

maximal durchwandern darf. Hierzu kann man den „Time To Live“-Parameter des

Internet Protocols (IP) [37] verwenden oder einen eigenen Parameter einführen. Eine

etwas effizientere Alternative wäre, dass der Client in regelmäßigen Abständen auf

zuvor beschriebene Weise alle Adressen der verbundenen Clients anfordert und dann

Anfragen immer nur direkt an die jeweiligen Clients sendet, anstatt eines Broadcasts.

Bei diesem Ansatz ergibt sich das Problem, wie ein neuer Client erstmalig eine Liste

von Clients erhält, die online sind. Dies müsste wiederum auf eine zentralisierte

Weise erfolgen. Abgesehen von diesem „Mangel“ würde der SPOF eines zentralen

Servers bei diesem Ansatz allerdings komplett wegfallen.

Schlussfolgerungen

117

7 Schlussfolgerungen

Mit dem MPEG-21-Standard versucht die Moving Picture Experts Group die

gemeinsame Nutzung von Multimedia-Ressourcen für den User so einfach wie

möglich zu gestalten. Eine wichtige Vorraussetzung dafür ist, dass der User die

Ressourcen jederzeit und in bestmöglicher Qualität betrachten kann, unabhängig

vom verwendeten Endgerät. Um dies zu erreichen, muss die entsprechende

Ressource an die Fähigkeiten des Endgerätes angepasst werden, weshalb sich ein

Kernbereich des MPEG-21-Standards mit der Adaptierung von Digital Items und den

enthaltenen Ressourcen befasst. In MPEG-21 wird die Ressource mit Hilfe von XML

beschrieben, was der DIA Engine eine gezielte Adaptierung ermöglicht, indem Teile

der Ressource aus dem Bitstrom entfernt werden. Ist eine Ressource nicht skalierbar,

so muss sie transkodiert werden und kann mit oben genannter Methode nicht

adaptiert werden. Der Vorteil dieser Methode besteht darin, dass die Adaptierung

sehr effizient und unabhängig von der Art der Ressource durchgeführt werden kann.

Im Rahmen dieser Diplomarbeit wurde eine DIA Engine implementiert, die Digital

Items und deren Ressourcen auf die oben genannte Art adaptiert. In den Abschnitten

4, 5 und 6 wurden das Design und die Implementierung der DIA Engine beschrieben

und diese in Experimenten getestet. Es wurde aufgezeigt, in welchen Bereichen der

Prototyp noch verbessert werden kann, bzw. welche Teile noch fehlen. Anhand der

Evaluierungsexperimente wurden mögliche Adaptierungen vorgestellt und

Schlussfolgerungen

118

miteinander verglichen. Weiters wurden Zeitmessung vorgenommen, die die

Performance der verschiedenen Module der DIA Engine zeigen. In einer

anschließenden Diskussion wurde eine mögliche Infrastruktur eines MPEG-21

Multimedia-Frameworks betrachtet.

Wie die abschließende Diskussion (siehe Abschnitt 6.5) gezeigt hat, ist diese DIA

Engine nur einer von mehreren Teilen eines MPEG-21 Clients, und bis zu einem

vollständigem Multimedia-Framework ist es noch ein weiter Weg. Dennoch ist die

Vorstellung eines Multimedia-Frameworks, wie es von MPEG skizziert wird, viel

versprechend. MPEG legt von Anfang an großen Wert auf einfache Handhabung und

widmet auch den Rechten der der User viel Beachtung, was bei bestehenden

Systemen oft nicht berücksichtigt wird. Eine vollständige Implementierung des

Multimedia-Frameworks würde einen wichtigen Schritt in Richtung eines

problemlos(er)en Austauschens von Multimedia-Dateien darstellen.

Die theoretische Aufarbeitung und der Prototyp sollen als Basis für zukünftige

Arbeiten in diesem Bereich dienen. Sie sollen ermöglichen, sich schnell in das

Thema der Adaptierung in MPEG-21 einzuarbeiten, um in diesem oder in

verwandten Bereichen wissenschaftliche Arbeit zu betreiben.

Literaturverzeichnis

119

8 Literaturverzeichnis

[1] Moving Pictures Experts Group (MPEG),

http://www.chiariglione.org/mpeg/, 2003

[2] Leonardo Chiariglione – Convenor, ISO/IEC JTC1/SC29/WG11, Short

MPEG-1 description, Juni 1996

[3] Leonardo Chiariglione – Convenor, ISO/IEC JTC1/SC29/WG11, Short

MPEG-2 description, Oktober 2000

[4] Rob Koenen (ed.), ISO/IEC JTC1/SC29/WG11 N4668, MPEG-4 Overview

- (V.21 – Jeju Version), März 2002

[5] Rik Van de Walle ([email protected]), Frederik De Keukelaere

([email protected]), DID Reference Software Contribution,

Java Source Code for parsing/validating MPEG-21 DIDs, Ghent University,

Belgium, 2003

[6] Christian Timmerer ([email protected]), Gabriel Panis

([email protected]), DID Reference Software Contribution,

gBSDtoBin, University of Klagenfurt, Siemens AG – München,

Österreich/Deutschland, 2002

[7] José M. Martínez, ISO/IEC JTC1/SC29/WG11 N4980, MPEG-7 Overview

(version 8), Klagenfurt, Juli 2002


120

[8] Rob Koenen, Intellectual Property Management and Protection in MPEG

Standards, W3C DRM Workshop 2001, http://www.w3.org/2000/12/drm-

ws/pp/koenen.pdf, 2001

[9] Jan Bormans, Keith Hill, ISO/IEC JTC1/SC29/WG11/N5231, MPEG-21

Overview v.5, Shanghai, Oktober 2002

[10] ISO/IEC/JTC1/SC29/WG11 N5534, Information technology —

Multimedia-Framework (MPEG-21) — Part 1: Vision, Technologies and

Strategy, 2nd Edition, Pattaya, März 2003

[11] Gabriel Panis, Andras Hutter, Jörg Heuer, Hermann Hellwagner, Harald

Kosch, Christian Timmerer, Sylvain Devillers, Myriam Amielh, Bitstream

Syntax Description: A Tool for Multimedia Resource Adaptation within

MPEG-21, EURASIP Signal Processing: Image Communication, Special

Issue on Multimedia Adaptation, http://www.ifi.uni-

klu.ac.at/Publications/pubfiles/pdffiles/2003-0172-GPAH.pdf, 2003

[12] Apache Software Foundation, http://www.apache.org, 2003

[13] Xalan, http://xml.apache.org/xalan-j/, 2003

[14] Elliotte Rusty Harold, XML Bible, Second Edition, John Wiley & Sons,

2002

[15] PHP: Hypertext Preprocessor, http://www.php.net, 2003

[16] Java Server Pages, http://java.sun.com/products/jsp/, Sun Microsystems

Inc., 2003

[17] Avni Rambhia (ed.), ISO/IEC JTC 1/SC 29/WG11 N4269, Information

technology – Coding of Audio-Visual Objects – Part 4: IPMP, Juli 2001

[18] Jan Bormans, Kate Grant (eds.), ISO/IEC JTC1/SC29/WG11 N4991,

MPEG-21 Use Case Scenarios, Juli 2002


121

[19] Vaughn Iverson, Todd Schwartz, Young-Won Song, Rik Van de Walle,

Ernesto Santos, Doim Chang, ISO/IEC JTC1/SC29/WG11 N4813,

Information Technology – Multimedia-Framework (MPEG-21) – Part 2:

Digital Item Declaration, Fairfax, Virginia, Mai 2002

[20] Perl, http://www.perl.com, 2003

[21] Sergey Brin, Lawrence Page, The Anatomy of a Large-Scale Hypertextual

Search Engine, CSD, Stanford University, 2001

[22] ISO/IEC JTC1/SC29/WG11 N4939, Information Technology – Multimedia-

Framework (MPEG-21) – Part 3: Digital Item Identification, Klagenfurt,

Juli 2002

[23] Vipul Sawhney, Location Based Services, Columbia University, Eelectrical

Engineering Department, http://www.columbia.edu/itc/ee/e6951/2002

spring/Projects/CVN/report3.pdf, 2002

[24] Andy Oram (ed.), Peer-to-Peer – Harnessing the Power of Disruptive

Technologies, O’Reilly & Associates, März 2001

[25] Avni Rambhia (ed.), ISO/IEC JTC 1/SC 29/WG11 N4269, Information

technology – Coding of Audio-Visual Objects – Part 4: IPMP, Juli 2001

[26] Huifang Sun, Anthony Vetro, Kohtaro Asai, Resource Adaptation Based on

MPEG-21 Usage Environment Descriptions, Mitsubishi Electric Research

Laboratory, Mai 2003

[27] Thomas DeMartini, Xin Wang, Barney Wragg (eds.), ISO/IEC JTC 1/SC

29/WG 11/N5599, Information technology — Multimedia-Framework —

Part 5: Rights Expression Language, Pattaya, März 2003

[28] Leff, Scott, Hodgson, Cowey, Howard, Wise, Impaired Reading in Patients

with Right Hemianopia, Annals of Neurology, Little, Brown & Co, Februar

2000


122

[29] Chris Barlas, Godfrey Rust, ISO/IEC JTC 1/SC 29/WG 11/N4943,

Information Technology — Multimedia-Framework — Part 6: Rights Data

Dictionary, Klagenfurt, Juli 2002

[30] ETSI EN 301 704, Adaptive Multi-Rate (AMR) speech transcoding,

GSM/ETSI, April 2000

[31] Anthony Vetro, Christian Timmerer (eds.), ISO/IEC JTC 1/SC 29/WG

11/N5845, Information Technology — Multimedia-Framework — Part 7:

Digital Item Adaptation, Trondheim, Juli 2003

[32] Freed, Borenstein, RFC 2045, Multipurpose Internet Mail Extenstions

(MIME) Part One: Format of Internet Message Bodies, November 1996

[33] Postel, Renolds, RFC 959, File Transfer Protocol (FTP), Oktober 1985

[34] Rik Van de Walle, Ian Burnett, Munchurl Kim, and Viswanathan (Vishy)

Swaminathan (eds.), ISO/IEC JTC 1/SC 29/WG 11/N5621, MPEG-21

Digital Item Processing Working Draft (WD) v.1, Pattaya, März 2003

[35] Fielding, Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee, RFC 2616,

Hypertext Transfer Protocol – HTTP/1.1, Juni 1999

[36] Myriam Amielh, Sylvain Devillers, Multimedia Content Adaptation with

XML, 8th International Conference on Multimedia Modeling 2001,

Amsterdam, Niederlande, 2001

[37] Postel, RFC 0791, Internet Protocol – DARPA Internet Program,

September, 1981

[38] Quicktime Streaming Server Modules, http://developer.apple.com/darwin/

projects/streaming/QTSS.pdf, Apple Computer Inc., Februar, 2002

[39] Anil K. Jain, Fundamentals of Digital Image Processing, Prentice Hall,

September 1988


123

[40] Myriam Amielh, Sylvain Devillers, Bitstream Syntax Description

Language: Application of XML-Schema to Multimedia Content Adaptation,

11th International World Wide Web Conference 2002,

http://www.unizh.ch/home/mazzo/reports/www2002conf/papers/334/, 2002

[41] Christian Timmerer, Gabriel Panis, Harald Kosch, Jörg Heuer, Hermann

Hellwagner, Andreas Hutter, Coding Format Independent Multimedia

Content Adaptation using XML, Proceedings of SPIE International

Symposium ITCom 2003 on Internet Multimedia Management Systems IV,

Vol. 5242, http://www.ifi.uni-klu.ac.at/Publications/pubfiles/pdffiles/2003-

0181-CTGP.pdf, September 2003

[42] Extensible Markup Language (XML) 1.0 (Second Edition),

http://www.w3.org/TR/REC-xml, W3C Recommendation, Oktober 2000

[43] Martin Boliek, Charilaos Christopoulos, Eric Majani (eds.), ISO/IEC JTC

1/SC 29/WG 1 N1646R, JPEG 2000 Part 1 FCD, März, 2000

[44] Document Object Model (DOM), http://www.w3.org/DOM/, June 2002

[45] Anthony Vetro, Andrew Perkins, Christian Timmerer, ISO/IEC JTC 1/SC

29/WG 11/N5613, Information Technology — Multimedia-Framework —

Part 7: Digital Item Adaptation, Pattaya, March 2003

[46] Extensible Stylesheet Language (XSL) Version 1.0,

http://www.w3.org/TR/xsl/, W3C Recommendation, Oktober 2001

[47] XSL Transformations (XSLT) Version 1.0, http://www.w3.org/TR/xslt,

W3C Recommendation, November 1999

[48] The Java Tutorial – A practical guide for programmers,

http://java.sun.com/docs/books/tutorial/, Mai 2003

[49] Unified Modeling Language (UML), http://www.omg.org/uml/, 2003


124

[50] Java 2 Platform, Standard Edition, v 1.4.2, API Specification,

http://java.sun.com/j2se/1.4.2/docs/api/, 2003

[51] World Wide Web Consortium (W3C), http://www.w3.org, 2003

[52] XML Schema, http://www.w3.org/XML/Schema, 2001

Abbildungsverzeichnis

125

9 Abbildungs-verzeichnis

Abbildung 1: Aufbau eines Digital Items, aus [9] ............................................................................. 8

Abbildung 2: DID Beispiel 1................................................................................................................ 8

Abbildung 3: DID Beispiel 2.............................................................................................................. 12




Abbildung 7: Digital Item Identification, aus [22] .......................................................................... 17

Abbildung 8: Digital Item Adaptation, aus [31].............................................................................. 20

Abbildung 9: Digital Item Adaptation Tools, aus [31].................................................................... 25

Abbildung 10: Digital Item Adaptation, aus [31]............................................................................ 27

Abbildung 11: Userinfo ..................................................................................................................... 28

Abbildung 12: Content Preferences – User Preferences................................................................. 30

Abbildung 13: Content Preferences – Usage History ..................................................................... 31


126

Abbildung 14: Presentation Preferences - Audio ........................................................................... 33

Abbildung 15: Presentation Preferences - Color............................................................................. 34

Abbildung 16: Auditory Impairment ............................................................................................... 36

Abbildung 17: Visual Impairment.................................................................................................... 37

Abbildung 18: Mobility Characteristics........................................................................................... 38

Abbildung 19: Terminal Capabilites – Codec Capabilities, aus [31]............................................. 40

Abbildung 20: Terminal Capabilities – Input/Output Capabilities .............................................. 42

Abbildung 21: Terminal Capabilities – Device Property ............................................................... 43

Abbildung 22: Network Characteristics .......................................................................................... 44

Abbildung 23: Natural Environment Characteristics - Location .................................................. 45

Abbildung 24: Natural Environment Characteristics - Time ........................................................ 46

Abbildung 25: Natural Environment Characteristics – Audio Environment .............................. 47

Abbildung 26: Natural Environment Characteristics - Illumination............................................ 47

Abbildung 27: Transformierung und Adaptierung, aus [31]......................................................... 49

Abbildung 28: Schema Hierarchie, aus [31] .................................................................................... 51

Abbildung 29: Bitstream Syntax Description.................................................................................. 52

Abbildung 30: Header ....................................................................................................................... 53

Abbildung 31: gBSDUnit................................................................................................................... 53

Abbildung 32: Parameter.................................................................................................................. 55

Abbildung 33: Hierarchische Verschachtelung von gBSDUnits.................................................... 56

Abbildung 34: Generierung der gBSD, aus [31] ............................................................................. 56

Abbildung 35: Transformierung der Beschreibung, aus [31] ........................................................ 57

Abbildung 36: Adaptierung des Bitstroms, aus [31]....................................................................... 58


127

Abbildung 37: Bitstream Syntax Description Link, aus [31] ......................................................... 59

Abbildung 38: Terminal und Network QoS-Beschreibung............................................................ 61

Abbildung 39: Beschreibung einer Ressource ................................................................................. 65

Abbildung 40: Baumstruktur ........................................................................................................... 65

Abbildung 41: Metadatenbeschreibung........................................................................................... 66

Abbildung 42: Beispiel eines Digital Items, aus [31] ....................................................................... 68

Abbildung 43: Beschreibung des aktuellen Zustandes eines DI, aus [31] ..................................... 69

Abbildung 44: Extrahieren der Ressource und gBSD .................................................................... 76

Abbildung 45: Parsen und Validieren des XDI............................................................................... 77

Abbildung 46: Generieren des XSLT Style-Sheets ......................................................................... 77

Abbildung 47: Transformieren der gBSD ....................................................................................... 78

Abbildung 48: Adaptieren der Ressource........................................................................................ 79

Abbildung 49: Generieren eines neuen CDI .................................................................................... 80

Abbildung 50: Design der DIA Engine............................................................................................. 81

Abbildung 51: User Preferences ....................................................................................................... 85

Abbildung 52: Baumstruktur ........................................................................................................... 86

Abbildung 53: „Adaptiertes“ Digital Item....................................................................................... 87

Abbildung 54: Interface Klassen der DIA Engine .......................................................................... 89

Abbildung 55: Identifizierung der Ressource.................................................................................. 91

Abbildung 56: Implementierung der Interface-Klassen................................................................. 93

Abbildung 57: Mögliche Anfrage an eine Datenbank..................................................................... 96

Abbildung 58: Berechnung der Subbänder einer Komponente .................................................... 99

Abbildung 59: XML-Beschreibung der Dimensionen eines JPEG-2000-Bildes........................... 99


128

Abbildung 60: Die Subbänder eines JPEG-2000-Bildes ............................................................... 100

Abbildung 61: Pakete mit marker-Attribut .................................................................................. 100

Abbildung 62: Skalierung der Auflösung ...................................................................................... 101

Abbildung 63: Zeitmessung – Adaptierung eines Digital Items anhand der Auflösung ........... 102

Abbildung 64: Größenvergleich von Beschreibung und Ressource ............................................ 103

Abbildung 65: Skalierung der Farbtiefe ........................................................................................ 104

Abbildung 66: Komponenten eines JPEG-2000-Bildes ................................................................ 105

Abbildung 67: Pakete mit marker-Attribut .................................................................................. 105

Abbildung 68: Zeitmessung – Adaptierung eines Digital Items anhand der Farbtiefe ............. 106


Abbildung 70: Vergleich – Digital Item mit 8 Bit & 24 Bit Ressource........................................ 108

Abbildung 71: Zeitmessung – Adaptierung eines Digital Items mit Frame-Dropping.............. 110

Abbildung 72: gBSD eines Videos .................................................................................................. 110


Abbildung 74: Markierung von Szenen in einem Video............................................................... 112

Anhang

129

10 Anhang

Hier befindet sich der Quellcode für die Interface Klassen.

10.1 Interfaces

Hier befindet sich der Quellcode für die Interface Klassen

10.1.1 CDIProcessor // This class takes a DID and extracts die DIA Description of the Resource included

// in it.

package DIAEngine.Interfaces;

import java.io.*;

import javax.xml.transform.Transformer;

import javax.xml.transform.TransformerConfigurationException;

import javax.xml.transform.TransformerException;

import javax.xml.transform.TransformerFactory;

import javax.xml.transform.stream.StreamResult;

import javax.xml.transform.stream.StreamSource;

import org.w3c.dom.*;

//serializer

import org.apache.xml.serialize.XMLSerializer;

import org.apache.xml.serialize.OutputFormat;


import javax.xml.parsers.*;

import java.io.*;

import org.xml.sax.*;

import java.net.*;

Anhang

130

// parser

import DIAEngine.DIDParser.*;

public interface CDIProcessor {

public void parseCDI();

public void setCDI(Node cdi);

public Node getResource();

public Node getResource(String ID);

public Node getDescriptor(String ID);

public void setResourceID(String resourceID);

public Node getDescription();

public void extractCDI() throws TransformerException,

TransformerConfigurationException, FileNotFoundException, IOException;

}

10.1.2 XDIProcessor // This class takes a DID and extracts die DIA Description of the Resource included

// in it.


import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;








public interface XDIProcessor {

public void parseXDI();

public void setXDI(Node xdi);

public void getXSLT();

public void extractXDI() throws TransformerException,


}

10.1.3 XSLTProcessor // This class takes a DID and extracts die DIA Description of the Resource included

// in it.


import java.io.*;

Anhang

131








//serializer





import java.io.*;


import java.net.*;

public interface XSLTProcessor {

public Node getTransformedDescription();

public void setDescription(Node description);

public void setXslt(Node xslt);

public void transform() throws TransformerException,


}

10.1.4 gBSDtoBin // This class takes a DID and extracts die DIA Description of the Resource included // in it.


import java.io.*;








//serializer





import java.io.*;

Anhang

132


import java.net.*;

// gbsd

import DIAEngine.gBSD.*;

public interface gBSDtoBin {


public void setResource(Node resource);

public Node getUpdatedDescription();

public Node getAdaptedResource() ;

public void exec_gBSDtoBin() throws TransformerException,


}

10.1.5 CDIGenerator // This class takes a DID and extracts die DIA Description of the Resource included

// in it.


import java.io.*;








//serializer





import java.io.*;


import java.net.*;

public interface CDIGenerator {

public Node getAdaptedCDI();

public void setResource(Node resource);


public void generateCDI() throws TransformerException,


}

Design und Prototyp-Implementierung einer MPEG-21 Digital Item … · 2004-02-18 · Das MPEG-21...

Documents

Transcript of Design und Prototyp-Implementierung einer MPEG-21 Digital Item … · 2004-02-18 · Das MPEG-21...