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.
Die Architektur von MPEG-21
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
Die Architektur von MPEG-21
7
dass er immer über wichtige Vorgänge im Multimedia-Framework informiert wird
(siehe Abschnitt 2.2.7).
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).
Die Architektur von MPEG-21
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
Die Architektur von MPEG-21
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
Die Architektur von MPEG-21
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
Die Architektur von MPEG-21
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.
Die Architektur von MPEG-21
12
<DIDL xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<Declarations>
<Descriptor id="photo_description">
<Statement mimeType="text/plain">
Photos from my holidays in Spain
</Statement>
</Descriptor>
</Declarations>
<Item>
<Descriptor>
<Statement mimeType="text/plain">
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>
Abbildung 3: DID Beispiel 2
Choice
Das Choice-Element enthält beliebig viele Condition-Elemente und beliebig viele
Descriptor-Elemente, mindestens aber ein Selection-Element.
Die Architektur von MPEG-21
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.
<DIDL xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<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>
<Statement mimeType="text/plain">
Luke dies.
</Statement>
</Descriptor>
</Anchor>
</Component>
</Item>
</DIDL>
Abbildung 4: DID Beispiel 3
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
Die Architektur von MPEG-21
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.
Die Architektur von MPEG-21
15
<DIDL xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<Item>
<Choice minSelections="1" maxSelections="1" choice_id="album">
<Descriptor>
<Statement mimeType="text/plain">
Which track would you like to play?
</Statement>
</Descriptor>
<Selection select_id="track1">
<Descriptor>
<Statement mimeType="text/plain">Track 1</Statement>
</Descriptor>
</Selection>
<Selection select_id="track2">
<Descriptor>
<Statement mimeType="text/plain">Track 2</Statement>
</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>
Abbildung 5: DID Beispiel 4
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).
Die Architektur von MPEG-21
16
<DIDL xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<Item id="music_album">
<Choice minSelections="1" maxSelections="1" choice_id="album">
<Descriptor>
<Statement mimeType="text/plain">
Which track would you like to play?
</Statement>
</Descriptor>
<Selection select_id="track1">
<Descriptor>
<Statement mimeType="text/plain">Track 1</Statement>
</Descriptor>
</Selection>
<Selection select_id="track2">
<Descriptor>
<Statement mimeType="text/plain">Track 2</Statement>
</Descriptor>
</Selection>
</Choice>
<Annotation target="music_album">
<Assertion target="album" true="track2"/>
</Annotation>
</Item>
</DIDL>
Abbildung 6: DID Beispiel 5
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).
Die Architektur von MPEG-21
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.
Die Architektur von MPEG-21
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.
Die Architektur von MPEG-21
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.
Die Architektur von MPEG-21
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
Die Architektur von MPEG-21
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.
Digital Item Adaptation
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]:
Digital Item Adaptation
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.
Digital Item Adaptation
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).
Digital Item Adaptation
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.
Digital Item Adaptation
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.
Digital Item Adaptation
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.
Digital Item Adaptation
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
Digital Item Adaptation
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.
Digital Item Adaptation
30
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<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>
</UserCharacteristics>
</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.
Digital Item Adaptation
31
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<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>
<mpeg7:ProgramIdentifier>
urn:mymedia:av:14-znn-623
</mpeg7:ProgramIdentifier>
</mpeg7:UserAction>
<mpeg7:UserAction>
<mpeg7:ProgramIdentifier>
urn:mymedia:av:73-mov-814
</mpeg7:ProgramIdentifier>
</mpeg7:UserAction>
</mpeg7:UserActionList>
</mpeg7:UserActionHistory>
</UsageHistory>
</UserCharacteristics>
</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
Digital Item Adaptation
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
Digital Item Adaptation
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>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<UserCharacteristics xsi:type="PresentationPreferencesType">
<Audio>
<VolumeControl>0.85</VolumeControl>
<AudioOutputDevice>Loudspeaker</AudioOutputDevice>
<BalancePreference>3</BalancePreference>
</Audio>
</UserCharacteristics>
</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.
Digital Item Adaptation
34
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<UserCharacteristics xsi:type="PresentationPreferencesType">
<Display>
<BrightnessPreference>
<BinNumber>255</BinNumber>
<Value>
<PreferredValue>138</PreferredValue>
</Value>
</BrightnessPreference>
<SaturationPreference>
<BinNumber>255</BinNumber>
<Value>
<PreferredValue>94</PreferredValue>
</Value>
</SaturationPreference>
<ContrastPreference>
<BinNumber>255</BinNumber>
<Value>
<PreferredValue>80</PreferredValue>
</Value>
</ContrastPreference>
</Display>
</UserCharacteristics>
</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.
Digital Item Adaptation
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).
Digital Item Adaptation
36
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<UserCharacteristics xsi:type="AccessibilityCharacteristicsType">
<Audio>
<RightEar>
<Freq250Hz>1.0</Freq250Hz>
<Freq500Hz>4.5</Freq500Hz>
<Freq1000Hz>-0.2</Freq1000Hz>
<Freq2000Hz>-2.0</Freq2000Hz>
<Freq4000Hz>1.5</Freq4000Hz>
<Freq8000Hz>5.5</Freq8000Hz>
</RightEar>
<LeftEar>
<Freq250Hz>8.0</Freq250Hz>
<Freq500Hz>-1.5</Freq500Hz>
<Freq1000Hz>8.0</Freq1000Hz>
<Freq2000Hz>8.0</Freq2000Hz>
<Freq4000Hz>8.0</Freq4000Hz>
<Freq8000Hz>9.0</Freq8000Hz>
</LeftEar>
</Audio>
</UserCharacteristics>
</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.
Digital Item Adaptation
37
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<UserCharacteristics xsi:type="AccessibilityCharacteristicsType">
<Visual>
<LowVisionSymptoms>
<LightSensitivity>Mild</LightSensitivity>
<Hemianopia side="right"/>
</LowVisionSymptoms>
<ColorVisionDeficiency>
<DeficiencyType>CompleteColorBlindness</DeficiencyType>
</ColorVisionDeficiency>
</Visual>
</UserCharacteristics>
</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.
Digital Item Adaptation
38
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="UserCharacteristicsType">
<UserCharacteristics xsi:type="MobilityCharacteristicsType">
<UpdateInterval>
<LastUpdatePoint latitude="34.9" longitude="87.2"/>
<LastUpdateTime>
<Time>
<mpeg7:TimePoint>2003-09-15T20:15:00</mpeg7:TimePoint>
</Time>
</LastUpdateTime>
</UpdateInterval>
</UserCharacteristics>
</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
Digital Item Adaptation
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.
Digital Item Adaptation
40
<DIA>
<Description xsi:type="UsageEnvironmentType">
<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
Digital Item Adaptation
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).
Digital Item Adaptation
42
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="TerminalCapabilitiesType">
<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>
</TerminalCapabilities>
</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.
Digital Item Adaptation
43
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="TerminalCapabilitiesType">
<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>
</TerminalCapabilities>
</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%).
Digital Item Adaptation
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>
<Description xsi:type="UsageEnvironmentType">
<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,
Digital Item Adaptation
45
latitude und altitude) auf. Zudem wird angegeben, dass sich der User gerade in
Österreich (Region) befindet.
<DIA>
<Description xsi:type="UsageEnvironmentType">
<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.
Digital Item Adaptation
46
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="NaturalEnvironmentCharacteristicsType">
<NaturalEnvironmentCharacteristics xsi:type="TimeType">
<Time>
<mpeg7:TimePoint>2003-09-15T20:15:00</mpeg7:TimePoint>
</Time>
</NaturalEnvironmentCharacteristics>
</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.
Digital Item Adaptation
47
<DIA>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="NaturalEnvironmentCharacteristicsType">
<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>
</NaturalEnvironmentCharacteristics>
</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>
<Description xsi:type="UsageEnvironmentType">
<UsageEnvironment xsi:type="NaturalEnvironmentCharacteristicsType">
<NaturalEnvironmentCharacteristics xsi:type="IlluminationCharacteristicsType">
<Illuminance>73000</Illuminance>
</NaturalEnvironmentCharacteristics>
</UsageEnvironment>
</Description>
</DIA>
Abbildung 26: Natural Environment Characteristics - Illumination
Digital Item Adaptation
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.
Digital Item Adaptation
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.
Digital Item Adaptation
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.
Digital Item Adaptation
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).
Digital Item Adaptation
52
<?xml version="1.0" ?>
<Codestream xmlns="JP2" xmlns:jp2="JP2" xsi:schemaLocation="JP2 JP2.xsd">
<MainHeader>
<!-- and so on... -->
</MainHeader>
<Bitstrom>
<Packet>
<SOP>
<Marker>FF91</Marker>
<LMarker>4</LMarker>
<Nsop>0</Nsop>
</SOP>
<PacketData>155 242</PacketData>
</Packet>
<!-- and so on ... -->
</Bitstrom>
<!-- and so on ... -->
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).
Digital Item Adaptation
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-
Digital Item Adaptation
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.
Digital Item Adaptation
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">
<Value xsi:type="xsd:unsignedShort">0</Value>
</Parameter>
<Parameter name=":J2K:Xsiz" length="4">
<Value xsi:type="xsd:unsignedInt">640</Value>
</Parameter>
<Parameter name=":J2K:Ysiz" length="4">
<Value xsi:type="xsd:unsignedInt">480</Value>
</Parameter>
<Parameter name=":J2K:XOsiz" length="4">
<Value xsi:type="xsd:unsignedInt">0</Value>
</Parameter>
<Parameter name=":J2K:YOsiz" length="4">
<Value xsi:type="xsd:unsignedInt">0</Value>
</Parameter>
<Parameter name=":J2K:XTsiz" length="4">
<Value xsi:type="xsd:unsignedInt">640</Value>
</Parameter>
<Parameter name=":J2K:YTsiz" length="4">
<Value xsi:type="xsd:unsignedInt">480</Value>
</Parameter>
<Parameter name=":J2K:XTOsiz" length="4">
<Value xsi:type="xsd:unsignedInt">0</Value>
</Parameter>
<Parameter name=":J2K:YTOsiz" length="4">
<Value xsi:type="xsd:unsignedInt">0</Value>
</Parameter>
<Parameter name=":J2K:Csiz" length="2">
<Value xsi:type="xsd:unsignedShort">3</Value>
</Parameter>
<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C0"/>
<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C1"/>
<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C2"/>
</gBSDUnit>
Abbildung 32: Parameter
Digital Item Adaptation
56
<gBSDUnit start="12288" length="47768" marker="Violence 6">
<gBSDUnit syntacticalLabel=":MV4:P_VOP" start="12288” length="7589"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="19877" length="3218"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="23095" length="3371"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="26466" length="3511"/>
<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]
Digital Item Adaptation
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
Digital Item Adaptation
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
Digital Item Adaptation
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
(siehe Abschnitt 3.3.3).
<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
Digital Item Adaptation
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.
Digital Item Adaptation
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">
<Values xsi:type="IntegerVectorType">
<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">
<Values xsi:type="IntegerVectorType">
<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>
<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>
</AdaptationOperator>
<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
Digital Item Adaptation
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>
Digital Item Adaptation
63
</SupplementalInformation>
</PointOfView>
<TemporalDecomposition>
<AudioVisualSegment id="personABC">
<MediaTime>
<MediaTimePoint>00:00:45</MediaTimePoint>
<MediaDuration>00:05:15</MediaDuration>
</MediaTime>
<PointOfView viewpoint="room">
<Importance>
<Value>0.75</Value>
</Importance>
<SupplementalInformation>
<FreeTextAnnotation>
Persons A, B and C discussing.
</FreeTextAnnotation>
</SupplementalInformation>
</PointOfView>
<TemporalDecomposition>
<AudioVisualSegment id="personAB">
<MediaTime>
<MediaTimePoint>00:00:45</MediaTimePoint>
<MediaDuration>00:03:00</MediaDuration>
</MediaTime>
<PointOfView viewpoint="personAB">
<Importance>
<Value>0.5</Value>
</Importance>
<SupplementalInformation>
<FreeTextAnnotation>
Person A and B talking.
</FreeTextAnnotation>
</SupplementalInformation>
</PointOfView>
<TemporalDecomposition>
<AudioVisualSegment id="personA">
<MediaTime>
<MediaTimePoint>00:00:45</MediaTimePoint>
<MediaDuration>00:01:15</MediaDuration>
</MediaTime>
<PointOfView viewpoint="personA">
<Importance>
<Value>0.25</Value>
</Importance>
<SupplementalInformation>
<FreeTextAnnotation>
Person A talking.
</FreeTextAnnotation>
</SupplementalInformation>
</PointOfView>
</AudioVisualSegment>
</TemporalDecomposition>
<TemporalDecomposition>
Digital Item Adaptation
64
<AudioVisualSegment id="personB">
<MediaTime>
<MediaTimePoint>00:02:00</MediaTimePoint>
<MediaDuration>00:01:45</MediaDuration>
</MediaTime>
<PointOfView viewpoint="personB">
<Importance>
<Value>1.0</Value>
</Importance>
<SupplementalInformation>
<FreeTextAnnotation>
Person B talking.
</FreeTextAnnotation>
</SupplementalInformation>
</PointOfView>
</AudioVisualSegment>
</TemporalDecomposition>
</AudioVisualSegment>
</TemporalDecomposition>
<TemporalDecomposition>
<AudioVisualSegment id="personC">
<MediaTime>
<MediaTimePoint>00:03:45</MediaTimePoint>
<MediaDuration>00:02:15</MediaDuration>
</MediaTime>
<PointOfView viewpoint="personC">
<Importance>
<Value>0.5</Value>
</Importance>
<SupplementalInformation>
<FreeTextAnnotation>
Person C talking.
</FreeTextAnnotation>
</SupplementalInformation>
</PointOfView>
</AudioVisualSegment>
</TemporalDecomposition>
</AudioVisualSegment>
</TemporalDecomposition>
<TemporalDecomposition>
<AudioVisualSegment id="personD">
<MediaTime>
<MediaTimePoint>00:06:00</MediaTimePoint>
<MediaDuration>00:00:45</MediaDuration>
</MediaTime>
<PointOfView viewpoint="personD">
<Importance>
<Value>0.5</Value>
</Importance>
<SupplementalInformation>
<FreeTextAnnotation>
Person D talking.
</FreeTextAnnotation>
Digital Item Adaptation
65
</SupplementalInformation>
</PointOfView>
</AudioVisualSegment>
</TemporalDecomposition>
</AudioVisualSegment>
</TemporalDecomposition>
</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
Digital Item Adaptation
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.
Digital Item Adaptation
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).
Digital Item Adaptation
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.
Digital Item Adaptation
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">
<!-- description of UsageHistory -->
</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.
Digital Item Adaptation
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.
Design einer DIA Engine
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.
Design einer DIA Engine
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
Design einer 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
Design einer DIA Engine
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.
Design einer DIA Engine
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.
Design einer DIA Engine
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
Design einer DIA Engine
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).
Design einer DIA Engine
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.
Design einer DIA Engine
80
Abbildung 49: Generieren eines neuen CDI
4.4.7 Zusammenfassung des Adaptierungsprozesses
Abbildung 50 zeigt den gesamten Adaptierungsprozess noch einmal in einer Grafik.
Design einer DIA Engine
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
Design einer DIA Engine
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">
<!-- gBSD -->
</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
Evaluierungsexperimente
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">
<Value xsi:type="xsd:unsignedInt">1024</Value>
</Parameter>
<Parameter name=":J2K:Ysiz" length="4">
<Value xsi:type="xsd:unsignedInt">768</Value>
</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
Evaluierungsexperimente
100
Abbildung 61). Eine genaue Beschreibung des JPEG-2000-Kodierformates findet
man in [43].
...
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R0"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R1"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R1"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R1"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R2"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R2"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R2"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R3"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R3"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R3"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R4"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R4"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R4"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R5"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R5"/>
<gBSDUnit syntacticalLabel=":J2K:Spqcd_2" length="2" marker="R5"/>
</gBSDUnit>
...
Abbildung 60: Die Subbänder eines JPEG-2000-Bildes
...
<gBSDUnit syntacticalLabel=":J2K:Packet" start="3385" length="9" marker="R0 L31 C2 P0">
<Header>
<DefaultValues addressMode="Consecutive"/>
</Header>
<gBSDUnit length="4"/>
<Parameter name=":J2K:Nsop" length="2">
<Value xsi:type="xsd:unsignedShort">95</Value>
</Parameter>
<gBSDUnit length="3"/>
</gBSDUnit>
<gBSDUnit syntacticalLabel=":J2K:Packet" start="3394" length="189" marker="R1 L0 C0 P0">
...
</gBSDUnit>
...
<gBSDUnit syntacticalLabel=":J2K:Packet" start="9261" length="9" marker="R2 L1 C2 P0">
...
</gBSDUnit>
...
Abbildung 61: Pakete mit marker-Attribut
Evaluierungsexperimente
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.
Evaluierungsexperimente
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.
Evaluierungsexperimente
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).
Evaluierungsexperimente
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.
Evaluierungsexperimente
105
...
<Parameter name=":J2K:Csiz" length="2">
<Value xsi:type="xsd:unsignedShort">3</Value>
</Parameter>
<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C0"/>
<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C1"/>
<gBSDUnit syntacticalLabel=":J2K:Comp_siz" length="3" marker="C2"/>
</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.
...
<gBSDUnit syntacticalLabel=":J2K:Packet" start="2998" length="9" marker="R0 L28 C0 P0">
<Header>
<DefaultValues addressMode="Consecutive"/>
</Header>
<gBSDUnit length="4"/>
<Parameter name=":J2K:Nsop" length="2">
<Value xsi:type="xsd:unsignedShort">84</Value>
</Parameter>
<gBSDUnit length="3"/>
</gBSDUnit>
<gBSDUnit syntacticalLabel=":J2K:Packet" start="3007" length="9" marker="R0 L28 C1 P0">
...
</gBSDUnit>
<gBSDUnit syntacticalLabel=":J2K:Packet" start="3016" length="9" marker="R0 L28 C2 P0">
...
</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
Evaluierungsexperimente
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).
Evaluierungsexperimente
107
0
50000
100000
150000
200000
250000
1024x768 512x384 256x192 128x96 64x48
Auflösung [Pixel]
Grö
ße [B
yte]
RessourceBeschreibung
Abbildung 69: Größenvergleich von Beschreibung und Ressource
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.
Evaluierungsexperimente
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
Evaluierungsexperimente
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.
Evaluierungsexperimente
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 syntacticalLabel=":MV4:P_VOP" start="13540" length="15128"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="28668" length="2734"/>
...
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="512751" length="7443"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="520194" length="7049"/>
</gBSDUnit>
Abbildung 72: gBSD eines Videos
Evaluierungsexperimente
111
0
5000000
10000000
15000000
20000000
25000000
30000000
Mit B-Frames B-Frames verworfen
Grö
ße [B
yte]
RessourceBeschreibung
Abbildung 73: Größenvergleich von Beschreibung und Ressource
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
Evaluierungsexperimente
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 syntacticalLabel=":MV4:P_VOP" start="13540" length="15128"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="28668" length="2734"/>
...
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="512751" length="7443"/>
<gBSDUnit syntacticalLabel=":MV4:B_VOP" start="520194" length="7049"/>
</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.
Evaluierungsexperimente
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
Evaluierungsexperimente
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
Evaluierungsexperimente
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
Evaluierungsexperimente
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
Literaturverzeichnis
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
Literaturverzeichnis
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
Literaturverzeichnis
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
Literaturverzeichnis
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
Literaturverzeichnis
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 4: DID Beispiel 3.............................................................................................................. 13
Abbildung 5: DID Beispiel 4.............................................................................................................. 15
Abbildung 6: DID Beispiel 5.............................................................................................................. 16
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
Abbildungsverzeichnis
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
Abbildungsverzeichnis
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
Abbildungsverzeichnis
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 69: Größenvergleich von Beschreibung und Ressource ............................................ 107
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 73: Größenvergleich von Beschreibung und Ressource ............................................ 111
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 org.w3c.dom.*;
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.
package DIAEngine.Interfaces;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
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.*;
public interface XDIProcessor {
public void parseXDI();
public void setXDI(Node xdi);
public void getXSLT();
public void extractXDI() throws TransformerException,
TransformerConfigurationException, FileNotFoundException, IOException;
}
10.1.3 XSLTProcessor // This class takes a DID and extracts die DIA Description of the Resource included
// in it.
package DIAEngine.Interfaces;
import java.io.*;
Anhang
131
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 org.w3c.dom.*;
import javax.xml.parsers.*;
import java.io.*;
import org.xml.sax.*;
import java.net.*;
public interface XSLTProcessor {
public Node getTransformedDescription();
public void setDescription(Node description);
public void setXslt(Node xslt);
public void transform() throws TransformerException,
TransformerConfigurationException, FileNotFoundException, IOException;
}
10.1.4 gBSDtoBin // 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 org.w3c.dom.*;
import javax.xml.parsers.*;
import java.io.*;
Anhang
132
import org.xml.sax.*;
import java.net.*;
// gbsd
import DIAEngine.gBSD.*;
public interface gBSDtoBin {
public void setDescription(Node description);
public void setResource(Node resource);
public Node getUpdatedDescription();
public Node getAdaptedResource() ;
public void exec_gBSDtoBin() throws TransformerException,
TransformerConfigurationException, FileNotFoundException, IOException;
}
10.1.5 CDIGenerator // 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 org.w3c.dom.*;
import javax.xml.parsers.*;
import java.io.*;
import org.xml.sax.*;
import java.net.*;
public interface CDIGenerator {
public Node getAdaptedCDI();
public void setResource(Node resource);
public void setDescription(Node description);
public void generateCDI() throws TransformerException,
TransformerConfigurationException, FileNotFoundException, IOException;
}