studie

GMD
STUDIE
K ONZEPTION
UND R EALISIERUNG EINER
MULTIMEDIALEN S CHNITTSTELLE AUF
B ASIS EINES OBJEKTRELATIONALEN
DBMS
Autor
Martin Mierse
Dipl. Inf. Matthias Malsy
Dipl. Inf. Matthias Hemmje
GMD – Forschungszentrum Informationstechnik GmbH
Institut für integrierte Publikations- und Informationssysteme
Copyright  1998
2
KURZBESCHREIBUNG
Bei der Bearbeitung von Videos durch digitalen Videoschnitt und deren Analyse
beispielsweise durch Schnitterkennung bzw. die Erkennung von Szenenwechseln ist
häufig der Zugriff auf Teile (Segmente) eines Videos erforderlich. Die dabei notwendige
Extraktion dieser Segmente aus dem gesamten Video ist keineswegs immer trivial,
besonders im Fall von komprimierten Videos. Häufig muß dazu das Datenmaterial
vorher aufbereitet und die interne Struktur des Videos analysiert werden. Da das dabei
notwendige Parsen recht rechenzeitintensiv ist, wäre es wünschenswert, es nur einmal
durchzuführen und das Ergebnis persistent zu speichern. Um die Vorteile von
Datenbankmanagementsystemen zu nutzen, bietet sich eine Speicherung in einem
solchen an.
Der Zugriff auf die Struktur von Videos ist außerdem für eine Reihe weiterer
Anwendungen erforderlich. So entstand die Idee, ein System zu entwerfen, das Zugriff,
Management und Retrieval von internen Strukturinformationen von Videos bietet.
Ziel der Arbeit war es, das Video Foundation DataBlade des Informix Dynamic Servers
um MPEG 1/2-Verwaltungsfunktionalitäten zu erweitern. Hierzu wurden zunächst
verschiedene Benutzungsanforderungen unter ORDBMS-Gesichtspunkten untersucht
und bewertet. Eine davon diente als Grundlage für die Konzeption eines effizienten
Speichermodells.
Schlagworte: MPEG, objektrelationale DBMS, Video Archive
3
ABSTRACT
Post-processing of digital video like video editing or video analysis (e.g. for cut
detection) requires frequent access on parts resp. segments of videos. Especially in the
case of compressed video stream data, the extraction is not trivial. Most often, the video
data itself must be prepared and internal structures must be analyzed which is done by a
so called ‘parser’. Due to the fact, that parsing large amounts of video data is a timely
expensive process, the demand for persistent storage and reuse of parser results is
obvious. The functional properties of data base management systems (DBMS) qualifies
these systems for the persistent storage of parsed meta data.
Since the access on internal video structures is useful for further applications the idea
arise for developing a system for efficient management and retrieval of structural
information of video streams.
In practice, the Video Foundation DataBlade of the Informix Dynamic Server was
extended by MPEG 1+2 support functions. Different user requirements have been
examined under the perspective of ORDBMS. One scenario acts as a base for the
storage model.
Keywords: MPEG, object-relational DBMS, Video Archives
4
INHALT
0 Einleitung ............................................................................................................................ 9
0.1 Motivation.................................................................................................................... 9
0.2 Überblick....................................................................................................................10
1 Stand der Technik ............................................................................................................13
1.1 Datenbanken .............................................................................................................13
1.1.1 Grundlegende Technologien ...........................................................................13
1.1.2 Datenbankmodelle ............................................................................................16
1.1.2.1 Relationale Datenbanken ..........................................................................16
1.1.2.2 Objektorientierte Datenbanken ...............................................................17
1.1.2.3 Objektrelationale Datenbanken ...............................................................18
1.1.3 Informix Dynamic Server.................................................................................21
1.1.3.1 Architektur ..................................................................................................22
1.1.3.2 DataBlade-Technologie.............................................................................25
1.2 Digitales Video ..........................................................................................................25
1.2.1 Formate für digitales Video .............................................................................26
1.2.2 Komprimierungsstandards...............................................................................26
1.2.2.1 DVI ..............................................................................................................28
1.2.2.2 Motion-JPEG .............................................................................................28
1.2.2.3 MPEG 1 ......................................................................................................29
1.1.2.4 MPEG 2 ......................................................................................................32
1.3 Video und Datenbanken..........................................................................................33
1.3.1 Multimediale Datenbanken ..............................................................................33
1.3.2 Das Video Foundation-DataBlade..................................................................34
2 Anforderungsanalyse .......................................................................................................39
2.1 Benutzungsszenarios ................................................................................................39
2.1.1 Verwaltung von MPEG-Videos......................................................................39
2.1.2 Zugriff auf Segmente eines MPEG-Videos...................................................39
2.1.2.1 Digitaler Videoschnitt................................................................................39
2.1.3 Zugriff auf strukturelle Metadaten eines MPEG-Videos ............................40
2.1.3.1 Erkennen von Szenenwechseln................................................................40
2.1.3.2 Objekterkennung........................................................................................40
2.1.3.3 Watermarking..............................................................................................40
2.1.3.4 Adaption ......................................................................................................41
2.1.3.5 Panoramabilder...........................................................................................42
2.1.3.6 Evaluierung von Encodern.......................................................................45
3 Entwurf..............................................................................................................................47
3.1 Entwurfsansatz..........................................................................................................47
5
3.1.1 Prinzipien............................................................................................................47
3.1.2 Grundsätzliche Überlegungen .........................................................................48
3.2 Spezifikation der SQL-Schnittstelle .......................................................................48
3.2.1 Erste Alternative: Abbildung der MPEG-Hierarchie ..................................49
3.2.1.1 Datentypen und Tabellen..........................................................................49
3.2.1.2 Funktionen ..................................................................................................50
3.2.1.3 Bewertung....................................................................................................51
3.2.2 Zweite Alternative: Funktionale Sicht ............................................................52
3.2.2.1 Tabellen........................................................................................................52
3.2.2.2 Funktionen ..................................................................................................53
3.2.2.3 Bewertung....................................................................................................54
4 Realisierung .......................................................................................................................57
4.1 Bereits existierende Module ....................................................................................57
4.1.1 MPEG-Library...................................................................................................57
4.1.2 Video Foundation-Datablade ..........................................................................60
4.1.3 Videoserver.........................................................................................................60
4.2 Architektur.................................................................................................................61
4.3 Speicherkonzepte ......................................................................................................63
4.3.1 Generelle Überlegungen ...................................................................................64
4.3.2 Primary Access Method....................................................................................64
4.3.3 Secondary Access Method ...............................................................................65
4.3.4 Parse Tree ...........................................................................................................65
4.4 Integration der bereits existierenden Module .......................................................66
4.4.1 MPEG-Library...................................................................................................66
4.4.2 Video Foundation-DataBlade..........................................................................67
4.4.3 Videoserver.........................................................................................................68
4.5 Implementierung der DataBlade-Funktionen.......................................................69
4.5.1 Generelles Schema der DataBlade-Funktionen ............................................69
4.5.2 Deklaration in SQL ...........................................................................................70
4.5.3 MPEGcreateVideo ............................................................................................70
5 Evaluierung .......................................................................................................................73
5.1 Das Web-DataBlade .................................................................................................73
5.2 Die Demonstrationsanwendung.............................................................................74
5.2.1 Ablauf der Demonstration ...............................................................................75
6 Ausblick .............................................................................................................................79
Anhang A: Die Klasse IDSaccess ....................................................................................81
Anhang B: Implementierung der DataBlade-Funktionen............................................83
Anhang C: Funktionen des MPEG-DataBlades............................................................87
Anhang D: Installation ......................................................................................................91
Installation des MPEG-DataBlades..............................................................................91
Installation der Demonstrationsanwendung ...............................................................93
6
Anhang E: Glossar.............................................................................................................95
Anhang F: Abbildungsverzeichnis...................................................................................97
Anhang G: Tabellenverzeichnis .......................................................................................99
Anhang H: Literatur.........................................................................................................101
7
0 Einleitung
In der Entwicklung der Computertechnologie spielen multimediale Daten eine immer
wichtiger werdende Rolle. Sie ermöglichen dem Computer ein Vordringen in Bereiche,
die bisher anderen Technologien und Geräten, zumeist analogen, vorbehalten waren. So
ist die Vision einer Integration von verschiedenen Medien wie Fernsehen, Rundfunk,
den klassischen Printmedien und Kommunikationsmedien wie Briefpost, Telefon und
Telefax längst keine Utopie mehr, sondern bereits weitgehend realisiert. Der Computer
spielt dabei eine zentrale Rolle, indem er durch die Entwicklung von TV- und RadioErweiterungssteckkarten, durch das Internet mit dem World Wide Web, Email und
Internettelefonie sowie Zusatzperipherie wie Faxmodems in alle genannten
Medienbereiche eindringt. Eine multimediale Ausstattung eines Rechners mit
Soundkarte und CD ROM-Laufwerk ist bereits Standard; wer einen Rechner ohne diese
Komponenten erwerben will, braucht eine Sonderanfertigung.
Auch das multimediale Medium Video hat Einzug in die Welt der Computer gehalten.
Eine Vielzahl von Datenformaten für Videos wie AVI, Quicktime sowie MPEG 1 und
die anderen Standards der MPEG-Familie unterstreicht dies. Auch
Hardwareunterstützung ist beispielsweise in Form von MPEG-Erweiterungssteckkarten
erhältlich.
0.1 Motivation
Computerunterstützung ist bei zahlreichen Anwendungen hilfreich. Als Beispiele seien
hier die Videobearbeitung mit digitalem Videoschnitt und die Videoanalyse mit
Schnitterkennung bzw. der Erkennung von Szenenwechseln genannt. Dabei ist häufig
der Zugriff auf Teile (Segmente) eines Videos erforderlich. Die dabei notwendige
Extraktion dieser Segmente aus dem Gesamtvideo ist keineswegs trivial, besonders im
Fall komprimierter Videos. Häufig muß dazu das Datenmaterial aufbereitet und die
interne Struktur des Videos analysiert werden. Da das dabei notwendige Parsen
rechenzeitintensiv ist, wäre es wünschenswert, es nur einmal durchzuführen und das
Ergebnis persistent zu speichern. Um die Vorteile von Datenbankmanagementsystemen
zu nutzen, bietet sich eine Speicherung in einem solchen an.
Der Zugriff auf die Struktur von Videos ist außerdem für eine Reihe weiterer
Anwendungen erforderlich; Beispiele dazu finden sich im Kapitel „2.1
Benutzungsszenarios“. So entstand die Idee, ein System zu entwerfen, das den Zugriff
9
0 E INLEITUNG
auf interne Strukturinformationen von Videos sowie deren Management und Retrieval
bietet. Dieses System wird in dieser Arbeit beschrieben.
0.2 Überblick
Im folgenden wird ein kurzer Überblick über die weiteren Kapitel dieser Arbeit
gegeben.
Kapitel I beschreibt den aktuellen Stand der Technik. Es geht auf die grundlegenden
Technologien und Modelle von Datenbanken ein und illustriert sie anhand eines
Beispielsystems, des Dynamic Servers von Informix. Weiterhin beschreibt es Formate
und Komprimierungsstandards für digitales Video und stellt eine Beziehung zwischen
Videos und Datenbanken her.
Das Kapitel II beinhaltet die Analyse der Anforderungen an das zu erstellende System.
Anhand von Benutzungsszenarios werden verschiedene Anwendungsfälle aufgezeigt.
In Kapitel III wird der Entwurf des Systems dargestellt und auf verschiedene
Alternativen bei der Spezifikation der SQL-Schnittstelle eingegangen.
Kapitel IV erläutert die Realisierung und Implementierung des Systems. Dabei werden
die Systemarchitektur, verschiedene Speicherkonzepte und die Integration bereits
existierender Module beschrieben.
Die Evaluierung anhand einer Demonstrationsanwendung wird in Kapitel V aufgezeigt.
Das Kapitel IV bietet
Ergänzungsmöglichkeiten.
einen
Ausblick
auf
zukünftige
Erweiterungs-
und
Anhang A gibt die Header-Datei der in C++ implementierten Klasse IDSaccess wieder.
Der Anhang B zeigt anhand einiger ausgewählter Beispiele die Implementierung der
DataBlade-Funktionen auf.
In Anhang C werden sämtliche Funktionen des MPEG-DataBlades mit ihrer Signatur
aufgeführt.
Der Anhang D beschreibt die bei der Installation des MPEG-DataBlades sowie der
Demonstrationsanwendung notwendigen Schritte.
Ein Glossar findet sich in Anhang E.
Anhang F bietet ein Verzeichnis aller Abbildungen.
10
In Anhang G befindet sich das Tabellenverzeichnis.
Schließlich rundet der Anhang H die Arbeit mit einem Verzeichnis der verwendeten
Literatur ab.
11
1 Stand der Technik
1.1 Datenbanken
1.1.1 Grundlegende Technologien
Die folgende Einführung in Datenbankmanagementsysteme orientiert sich an [DB1]
und [MMOODB].
Prinzipiell könnte jedes Anwendungsprogramm die Speicherung der von ihm
bearbeiteten Daten selbst übernehmen. Oft arbeiten jedoch mehrere Anwendungen
teilweise oder vollständig auf demselben Datenbestand (siehe Abbildung 1).
Abbildung 1: Mehrere Anwendungen arbeiten auf demselben Datenbestand
Dabei entstehen die folgenden Probleme:
• Inkonsistenzen
• Redundanzen
• Konkurrierende Zugriffe auf Daten
13
1 S TAND DER T ECHNIK
• Änderungen an der Struktur der gespeicherten Daten müssen in allen beteiligten
Anwendungen vorgenommen werden.
• Abhängigkeiten zwischen
- Daten untereinander
- Daten und Programmen
- Programmen untereinander
Zur Lösung dieser Probleme wurden Datenbanksysteme erfunden. Sie bestehen aus
einer Datenbank und einem Datenbankmanagementsystem. Dabei ist die Datenbank
eine einheitlich beschriebene Darstellung eines Weltausschnittes mittels diskreter Daten
auf externen und persistenten Speichermedien, wobei es sich üblicherweise um
Magnetplatten handelt. Der Zugriff auf die Daten in der Datenbank ist nur über das
Datenbankmanagementsystem möglich. Es ist für das Einfügen, Lesen, Ändern und
Löschen von Daten zuständig.
Wie Abbildung 2 zeigt, existiert in Form des Datenbankmanagementsystems eine
einheitliche Schnittstelle für den Zugriff auf die gemeinsame Datenbasis. Somit findet
eine Entkopplung von Applikationen und Datenverwaltung statt. Alle
Anwendungsprogramme haben die gleiche logische Sicht auf den Datenbestand, und
um die Strukturen der physischen Speicherung kümmert sich das
Datenbankmanagementsystem. Die Programmteile zur Verwaltung der Daten werden
also aus den Anwendungen herausfaktorisiert.
14
1.1 D ATENBANKEN
Abbildung 2: Mehrere Anwendungen greifen auf eine Datenbank zu
Aus diesem Ansatz ergeben sich folgende grundlegende Eigenschaften von
Datenbanksystemen:
• Verwaltung großer Datenmengen
• Persistente Speicherung der Daten
• Strukturierte Datenverwaltung
• Querying
• Redundanzfreiheit durch einen integrierten Datenbestand
• Korrektheit in Mehrbenutzerbetrieb durch Concurrency Control
• Zugriffsregelung
mit
Transaktionsmanagement
feinkörnigen
Zugriffsrechten
und
• Korrektheit der Daten durch Überprüfen der Einhaltung definierter
Konsistenzregeln
15
1 S TAND DER T ECHNIK
• Datensicherheit bei fehlerhaftem Ablauf einzelner Anwendungen und
Systemabsturz durch Recovery
• Datenunabhängigkeit
1.1.2 Datenbankmodelle
1.1.2.1 Relationale Datenbanken
Das Konzept der relationale Datenbanken folgt dem Relationenmodell von [Codd]. Die
Darstellung der zu modellierenden Wirklichkeit erfolgt hier mit einem einzigen
Konstrukt, dem der Relation, wie sie aus der Mathematik bekannt ist. Relationen
können dabei als Tabellen gesehen werden. Die Einträge jeder Spalte sind alle vom
selben fest definierten Datentyp. Eine Zeile, Tupel genannt, entspricht einem Datensatz.
Auf den Tabellen sind Operationen definiert; eine der wichtigsten ist die Selektion, die
eine Menge von Tupeln aus einer Tabelle, die einer angegebenen Bedingung
entsprechen, zurückliefert. Durch Beziehungen zwischen Tabellen können komplexe
Sachverhalte modelliert werden.
Für relationale Datenbanken existieren Sprachen zur Definition der Datenschemata
(DDLs, Data Definition Languages) und Abfragesprachen (DMLs, Data Manipulation
Languages). SQL ist die am weitesten verbreitete Datenbanksprache und dient
gleichzeitig als DDL und DML.
Relationale Datenbanken eignen sich besonders für die klassischen administrativen und
betriebswirtschaftlichen Anwendungen wie die Verwaltung von Kundendaten oder
Lohnbuchhaltung. Die Ursache dafür liegt in der sehr flachen und einfachen Struktur
der dabei anfallenden Daten, die sich mit relationalen Modellen sehr einfach modellieren
läßt.
Relationale Datenbanken weisen aber auch eine Reihe von Unzulänglichkeiten auf. Da
mit Tupeln nur flache Strukturen nachgebildet werden können, sind die
Modellierungsmöglichkeiten stark eingeschränkt, besonders wenn man als Vergleich
objektorientierte Programmiersprachen heranzieht. Die Darstellung der Objektstruktur
ist
nur
über
Fremdschlüssel
möglich,
damit
existieren
keine
Unterscheidungsmöglichkeiten für Generalisierung und Aggregation. Relationale
Datenbanken kennen keine globalen Operatoren für komplexe Objekte. Weiterhin
fehlen benutzerdefinierbare Operationen. Schließlich ist die Bearbeitung von
Datenobjekten großen Volumens mit Ausnahme von proprietären Lösungen wie
BLOBs (Binary Large Objects) nicht vorgesehen.
16
1.1 D ATENBANKEN
1.1.2.2 Objektorientierte Datenbanken
Um die Nachteile relationaler Datenbanksysteme aus dem Weg zu räumen, wurde die
Familie der objektorientierten Datenbanken entwickelt. Sie entstehen durch Erweitern
eines (relationalen) Datenbankmanagementsystems um objektorientierte Konzepte oder
durch Hinzufügen von Datenbankfunktionalität zu einer objektorientierten
Programmiersprache. So bleiben die im Kapitel „1.1.1 Grundlegende Technologien“
erwähnten Eigenschaften erhalten.
Das Objektkonzept geht auf die Idee des abstrakten Datentyps zurück. Abstrakte
Datentypen bestehen aus einer Datenstruktur und darauf definierten Operationen.
Genauso haben Objekte eine interne Struktur (Attribute) und typspezifische Operatoren
(Methoden). Die Implementierungsdetails sind dabei für den Benutzer nicht sichtbar.
Die Werte der Attribute können nur durch die Methoden verändert werden, somit sind
sie nach außen abgekapselt.
Objektorientierte Datenbanksysteme haben die folgenden grundlegenden Eigenschaften
[Manifesto]:
• Komplexe Objekte
• Objektidentität: Jedes Objekt hat einen systemweit eindeutigen Identifier. Zwei
Objekte sind identisch, wenn ihre Identifier identisch sind; sie sind gleich, wenn
ihre Attribute die gleichen Werte haben.
• Datenunabhängigkeit durch Kapselung
• Typen oder Klassen: Typen beschreiben das nach außen sichtbare Verhalten
und können mehrere Implementierungen haben. Klassen definieren eine
Struktur und liefern eine Implementierung für Operationen. (Also binden
Klassen eine Implementierung an einen Typ. Oder anders gesagt:
Klassenzugehörigkeit impliziert Typzugehörigkeit, umgekehrt ist das nicht der
Fall.)
• Vererbung: Klassen können von anderen Klassen Eigenschaften erben.
Vererbung dient zur Kontrolle von Redundanz und Konsistenz.
• Überladen (Overloading) und Überschreiben (Overriding) von Operatoren
sowie spätes Binden
• Erweiterbarkeit: Neue Typen und Operatoren sind benutzerdefinierbar.
• Computational Completeness: Jede berechenbare Funktion ist in der DML
spezifizierbar
17
1 S TAND DER T ECHNIK
• Persistenz
• Sekundärspeicherverwaltung:
Indizes,
Zugriffspfade, Queryoptimierung
Clustering,
Puffermechanismen,
• Nebenläufigkeit (Concurrency Control): Sicherung nebenläufiger Transaktionen
und Mehrbenutzerbetrieb
• Recovery
• Ad hoc Queries: Eine einfache Möglichkeit, Abfragen zu stellen, z. B. durch eine
spezielle Abfragesprache
Mit diesen Merkmalen sind objektorientierte Datenbanksysteme ihren relationalen
Verwandten in vieler Hinsicht überlegen. Das resultiert im wesentlichen aus der
Möglichkeit einer adäquateren Modellierung des Umweltausschnittes durch
benutzerdefinierte komplexe Objekte. Ihr wohl größter Nachteil ist die im Vergleich zu
relationalen Systemen geringere Performanz aufgrund des zusätzlichen
Verwaltungsaufwandes.
Besondere Bedeutung haben objektorientierte Datenbanken im Bereich der NichtStandardanwendungen wie CAD/CAM/CIM, geographischen Informationssystemen,
Workflowmanagementsystemen, multimedialen Systemen, wissensbasierten Systemen,
naturwissenschaftlichen Anwendungen sowie in der Dokumentverwaltung mit
Büroautomation, Hypertext und Autorensystemen.
1.1.2.3 Objektrelationale Datenbanken
Nach [Stonebraker] lassen sich Datenbankanwendungen in Kategorien einteilen. Dabei
wird zwischen einfachen und komplexen Daten sowie zwischen Anwendungen mit und
ohne Abfragen unterschieden. Somit ergeben sich insgesamt vier Kategorien (siehe
Abbildung 3).
18
1.1 D ATENBANKEN
Abbildung 3: Die Klassifizierung von Datenbankanwendungen nach
[Stonebraker]
In die erste Kategorie mit einfachen Daten und ohne Abfragen fallen Anwendungen wie
Editoren oder Textverarbeitung. Diese benötigen keine Datenbank, sondern benutzen
für die persistente Speicherung der bearbeiteten Texte das vom Betriebssystem
bereitgestellte Dateisystem.
Beispiele für die zweite Kategorie von Anwendungen sind etwa eine
Kundendatenverwaltung und eine Lohnbuchhaltung. Diese werden typischerweise mit
relationalen Datenbanken und der Abfragesprache SQL implementiert.
Die dritte Kategorie steht für Anwendungen, die komplexe Datenstrukturen benötigen,
aber ohne Abfragen auskommen, wie etwa CAD-Programme. Würden diese wie bei der
ersten Kategorie das Dateisystem nutzen, wären aufwendige Konvertierungen zwischen
den Formaten durchzuführen, in denen die Daten in der Datei bzw. im Hauptspeicher
gespeichert sind. Statt dessen werden bei solchen Applikationen Erweiterungen für
Programmiersprachen verwendet, die die persistente Speicherung von in der
Programmiersprache definierten Datenstrukturen unterstützen. Es wird also ein
objektorientiertes Datenbanksystem verwendet.
Die letzte Kategorie ist abfrageorientiert und erfordert komplexe Datenstrukturen.
Anwendungsbeispiele für diese Kategorie sind die Verwaltung multimedialer
Datenbeständen wie Bild-, Ton- und Videoarchive.
19
1 S TAND DER T ECHNIK
Um dafür ein geeignetes Hilfsmittel zu haben, wurde eine neue Familie von
Datenbanken geschaffen: die objektrelationalen Datenbanksysteme. Sie versuchen, die
Vorteile von relationalen und objektorientierten Systemen zu vereinen, indem sie
relationale Datenbanken um objektorientierte Konzepte erweitern.
Für objektrelationale
charakteristisch:
Datenbanksysteme
sind
die
folgenden
Eigenschaften
• Die Daten werden wie bei relationalen Systemen in Tabellen gespeichert.
• Den Spalten der Tabellen ist ebenso wie bei relationalen Datenbanken ein fester
Typ zugewiesen.
• Als Datentypen sind erlaubt:
-
Vordefinierte Typen wie integer oder varchar(100)
-
Basisdatentypenerweiterung: Es sind benutzerdefinierte Typen wie row
type point (x float, y float) möglich. Diese neuen Typen sind
genauso wie die vordefinierten z. B. bei Abfragen einsetzbar. Dies ermöglicht
nebenbei auch die Verwaltung von Datentypen großen Volumens, die
besonders im multimedialen Bereich auftreten.
• Komplexe Datentypen, die aus mehreren Basisdatentypen bestehen
• Tabellen sind Instanzen eines Datentyps.
• Benutzerdefinierte Routinen
• Einfache Vererbungsmechanismen: Ein Typ kann von seinem Vatertyp
Eigenschaften erben.
Beispiel:
create row type person (name varchar(32));
create row type professor (department varchar (32))
under person;
create row
person;
type
student
(major
20
varchar
(100))
under
1.1 D ATENBANKEN
Der Typ Professor hat durch diese Deklaration die Datenfelder department
und name, wobei er letzteres vom Typ Person erbt. Analog hat der Typ Student
die Felder major und name.
Außer Datenfeldern werden auch die für den Vatertyp definierten Funktionen
vererbt.
Auch Mehrfachvererbung sowie das Überladen von Operationen sind erlaubt.
• Die gute Performance und die effizienten Abfragemöglichkeiten relationaler
Systeme bleiben im wesentlichen erhalten.
• Anders als bei relationalen Datenbanken kann auch ein großer Teil der
Funktionalität, die dort durch das Anwendungsprogramm implementiert wird,
direkt in den Datenbankkern verlagert werden. Dadurch ergibt sich ein nicht
unerheblicher Geschwindigkeitsgewinn.
• Durch Regel in der Form on event [...] do action [...] läßt sich
die Integrität des Datenbestandes sicherstellen. Diese Regeln spezifizieren eine
Reaktion des Systems auf bestimmte Ereignisse wie beispielsweise das
Modifizieren von Daten.
Mit diesen Eigenschaften, vor allem mit der Basisdatentypenerweiterung und der guten
Performance, eignen sich objektrelationale Datenbankmanagementsysteme besonders
für multimediale Anwendungen. Sie lassen sich aber auch in vielen Bereichen
verwenden, in denen wegen der Unzulänglichkeiten relationaler Systeme bisher
objektorientierte Datenbanken eingesetzt wurden.
1.1.3 Informix Dynamic Server
Da es sich bei der vorgestellten Implementierung um eine multimediale Anwendung
handelt, liegt es nahe, ein objektrelationales Datenbankmanagementsystem zu
verwenden.
Der Dynamic Server der Firma Informix Software, Inc. bietet neben einer nativen
Implementierung die volle Funktionalität objektrelationaler Datenbanken mit
Basisdatentypenerweiterung, komplexen Objekten, Vererbung und Regeln. Dies ist bei
allen seinen Konkurrenten nicht der Fall. So fiel nicht zuletzt wegen der Verfügbarkeit
des im Kapitel „1.3.2 Das Video Foundation-DataBlade“ vorgestellten DataBlades die
Wahl auf dieses Datenbanksystem, das im folgenden kurz vorgestellt werden soll.
21
1 S TAND DER T ECHNIK
1.1.3.1 Architektur
Der Dynamic Server ist ein hochperformantes Datenbanksystem, das mit
Multithreading arbeitet. Es läuft sowohl auf Einzelprozessormaschinen als auch auf
symmetrischen Multiprozessorsystemen. Mit sogenannten DataBlades kann es um neue
Datentypen und Operationen erweitert werden.
Kennzeichnend für die Architektur des Informix Dynamic Servers sind die folgenden
Aspekte [IDS]:
• Client/Server-Architektur: Der Dynamic Server reagiert auf ClientAnwendungen, die Daten aus der Datenbank anfordern, und stellt diese zur
Verfügung. Ein Client kann dabei das mit dem Dynamic Server ausgelieferte
Hilfsprogramm DB-Access, das interaktive SQL-Abfragen ermöglicht, oder eine
in INFORMIX-ESQL/C, C++, Java oder einer anderen Sprache geschriebene
Anwendung sein.
• Skalierbarkeit: Entsprechend den Anforderungen, die die Anwendungen an das
Datenbanksystem stellen, können die Ressourcen skaliert werden. Nach
Herstellerangaben hat diese sogenannte „Dynamic Scalable Architecture“ durch
die Bereitstellung virtueller Prozessoren, die weiter unten näher erläutert werden,
Performanzvorteile sowohl für Einzel- als auch für Mehrprozessorsysteme.
Besonders symmetrische Multiprozessorsysteme werden durch diese Architektur
gut unterstützt.
• Durch systemnahe Optimierungen läßt sich eine gute Performanz erreichen. Ein
Beispiel dafür ist Raw Disk Management, wobei das Dateisystem des
Betriebssystems nicht benutzt wird.
• Durch Replikation des gesamten Datenbanksystems auf einem zweiten Rechner
kann eine hohe Verfügbarkeit sichergestellt werden.
• Verteilte Datenbanken: Innerhalb einer Transaktion können mehrere
Datenbanken auf verschiedenen Datenbankservern abgefragt werden. Das
erlaubt eine Aufteilung des Datenmaterials nach organisatorischen
Gesichtspunkten.
Die Architektur stützt sich im wesentlichen auf mehrere Betriebssystemprozesse und –
threads, die virtuelle Prozessoren genannt werden [DBDK]. Das Datenbanksystem teilt
Aufgaben in Teilaufgaben auf, die dann jeweils einem virtuellen Prozessor zugewiesen
werden. Auf einem Mehrprozessorsystem können die virtuellen Prozessoren auf die
physikalisch vorhandenen verteilt werden. So läßt sich durch Ausnutzung der parallelen
Architektur eine gute Performanz erreichen.
22
1.1 D ATENBANKEN
Abbildung 4 veranschaulicht die Prozesse einer einfachen Installation des Dynamic
Servers.
Abbildung 4: Prozeßdiagramm des Dynamic Server
Jedes Quadrat in der Abbildung stellt einen virtuellen Prozessor dar, der als
Betriebssystemprozeß oder –thread läuft. Von den einzelnen Kategorien virtueller
Prozessoren können beliebig viele Instanzen existieren. Ihre genaue Anzahl ist abhängig
von Performanzanforderungen und Auslastung.
Der Dynamic Server kennt die folgenden Arten virtueller Prozessoren:
• Der CPU Virtual Processor stellt das Herzstück des Dynamic Servers dar. Er ist
zuständig für das Parsen einer in SQL gestellten Abfrage und für deren Planung
und Optimierung. Er unterteilt eine Anfrage in mehrere Threads, überwacht
deren Ausführung und sammelt die Ergebnisse.
• Der Extension Virtual Processor hat die gleichen Aufgaben wie ein CPUProzessor. Er lockert jedoch die bei der Entwicklung von DataBlades zu
beachtenden Vorschriften. So sind beispielsweise blockierende Systemaufrufe
wie I/O-Operationen erlaubt. Die blockierenden Operationen versetzen einen
Extension Virtual Processor in den Wartezustand, die Abarbeitung von
Abfragen durch die CPU-Prozessoren wird jedoch nicht beeinträchtigt.
23
1 S TAND DER T ECHNIK
• Ein Asynchronous I/O Virtual Processor implementiert asynchrone I/OOperationen. Wenn ein CPU-Prozessor Daten von dem Massenspeicher lesen
will, wird diese Aufgabe dem I/O-Prozessor übertragen. Der CPU-Prozessor
kann bis zum Ende der I/O-Operation weiterarbeiten. Nur falls keine Arbeit für
ihn anliegt, wird er in einen Wartezustand versetzt.
• Der Network Virtual Processor ist für die Netzwerkkommunikation mit dem
Client und mit anderen Datenbankservern zuständig.
Die virtuellen Prozessoren kommunizieren untereinander über Shared Memory. Dabei
handelt es sich um einen Speicherbereich, den alle Prozesse lesen und schreiben
können. Die Größe des Shared Memory-Bereiches kann sich während der Lebensdauer
des Datenbankservers je nach Speicheranforderungen von Abfragen verändern.
Im Shared Memory werden die folgenden Informationen abgelegt:
• Puffer beinhalten Daten aus Datenbanktabellen oder Indizes.
• Es wird eine Liste der zu Zeit laufenden Abfragen geführt.
• Die Sperren von laufenden Transaktionen werden hier registriert.
• Lokaler Speicher von Funktionen eines DataBlades wird hier allokiert.
Die Betriebssysteme, unter denen der Dynamic Server läuft, stellen sicher, daß die
Adreßräume aller virtuellen Prozessoren identisch sind. So wird beispielsweise unter
Unix jeder virtuelle Prozessor mit Hilfe des Systemaufrufs fork() erzeugt. Für die auf
diese Weise generierten Adreßräume wird kein Code reallokiert. Daher müssen keine
Adressen umgerechnet werden, wenn die Zuweisung eines Threads von einem virtuellen
Prozessor auf einen anderen wechselt.
Weiterhin unterstützt der Informix Dynamic Server multimediale Datentypen durch die
folgenden Eigenschaften:
• Es gibt den vordefinierten Datentyp external_file, der eine Referenz in das
lokale Dateisystem darstellt, was das folgende Beispiel verdeutlicht:
create table
_file);
insert into
.jpg″);
Bilder(Name
Bilder
varchar(20),
values(″Test″,
Bild
external
″~mierse/bilder/test
• Außerdem gibt es mit dem Datentyp large object lange Bytefelder zur
Aufnahme multimedialer Daten. Auf diesem Typ sind Operationen zum Im-
24
1.2 D IGITALES V IDEO
und Export aus dem Dateisystem sowie zum Byte-orientierten Zugriff auf das
Feld und zur Suche nach Bytemustern definiert.
1.1.3.2 DataBlade-Technologie
DataBlades sind Softwarebibliotheken in Form von Shared Objects. Sie dienen der
Basisdatentypenerweiterung und werden zur Laufzeit dynamisch zum Datenbankkern
dazugeladen. Daraus resultiert eine besonders gute Performanz, die nicht erreicht
werden könnte, wenn die entsprechende Funktionalität im Anwendungsprogramm und
damit in einer anderen Schicht außerhalb des Kernes implementiert würde, wie es oft
üblich ist.
DataBlades ergänzen das Datenbanksystem um spezielle Funktionalität, die für einen
spezifischen Anwendungsbereich benötigt wird. Ein Beispiel ist die Erstellung von
HTML-Seiten für das World Wide Web, die mit Datenmaterial aus der Datenbank
dynamisch generiert werden können.
DataBlades bestehen aus
• benutzerdefinierten Datentypen,
• benutzerdefinierten Operationen auf diesen Typen und
• Tabellen, die das Schema des DataBlades bilden.
Nachdem DataBlades in der Datenbank registriert wurden, wird deren Datenmodell
dynamisch in das der Datenbank integriert. Daher kann auf die Erweiterungen auf die
gleiche Weise wie auf vordefinierte Funktionalität z. B. mit SQL zugegriffen werden.
Als Beispiel wird im Kapitel „1.3.2 Das Video Foundation-DataBlade“ das Video
Foundation DataBlade vorgestellt. Außerdem existieren DataBlades beispielsweise für
Textretrieval, pixelorientierte Manipulation von Bildern wie Formatkonvertierungen
oder Skalierungen sowie ein Toolkit für die Erstellung von HTML-Seiten. Mit Hilfe des
DataBlade Developer’s Kit kann jeder Anwender auch eigene DataBlades entwickeln.
1.2 Digitales Video
Multimediale Anwendungen können in zwei Kategorien eingeteilt werden:
• Streaming-orientiert: Im Vordergrund steht die kontinuierliche Wiedergabe in
Echtzeit, beispielsweise das Playback (Wiedergabe) von Videos.
25
1 S TAND DER T ECHNIK
• Interaktiv: Hier ist ein effizienter Zugriff auf Teile des multimedialen Mediums
wichtig. Beispiele dafür sind der digitale Videoschnitt oder CBT (Computer
Based Training).
Wie die genannten Beispiele zeigen, fällt das zeitabhängige visuelle Medium Video in
beide Kategorien. Das im Verlauf dieser Arbeit vorgestellte System betont den
interaktiven Aspekt.
1.2.1 Formate für digitales Video
Digitales Video wird in der Fernsehtechnik häufig genutzt. Der Verbreitungsbereich
erstreckt sich dabei allerdings fast ausschließlich auf die Programmanbieter. Für die
deutschen Konsumenten ist digitales Fernsehen erst seit kurzem in Form des Pay-TVSenders DF1 verfügbar. Nicht zuletzt wegen der hohen monatlichen Kosten und der
benötigten digitalen Zusatzhardware zum analogen Fernsehgerät hat sich DF1 bis heute
nicht durchsetzen können.
Die Formate für digitales Video können wie folgt unterschieden werden:
• Standards ohne Komprimierung. Sie zeichnen sich durch gute Qualität und eine
hohe Übertragungsrate aus. Solche Formate werden vor allem zur
professionellen Videoproduktion bei Fernsehsendern eingesetzt. Als wichtigste
Vertreter seien hier Digital Component Video (CCIR 601), Digital Composite
Video, CIF (Common Intermediate Format) und QCIF (Quarter-CIF) sowie
HDTV (High Definition Television) genannt.
• Standards mit Komprimierung. Ihre Qualität und andere Parameter wie
Auflösung oder Farbtiefe sind den Formaten ohne Komprimierung oft
unterlegen. Dafür sind sie auch auf weniger leistungsstarken Systemen wie
üblichen PCs ohne besondere Zusatzausstattung abspielbar und finden
dementsprechend nicht nur in der Fernsehtechnik, sondern auch im
semiprofessionellen und im Heimbereich Verwendung.
1.2.2 Komprimierungsstandards
Das größte Problem bei digitaler Videotechnologie ist die Menge der anfallenden Daten.
Multimediale Daten benötigen im Vergleich zu alphanumerischem Material ein
Vielfaches an Speicherplatz. Ohne Komprimierungsverfahren sind heutige
Speichermedien und Übertragungsnetzwerke nicht in der Lage, Videos in einigermaßen
anspruchsvoller Qualität wiederzugeben. Dies wird durch Tabelle 1, Tabelle 2 und
Tabelle 3 deutlich.
26
1.2 D IGITALES V IDEO
Medienart
Volumen
Datendurchsatz
500 Seiten Text
1 MB
2 KB/Seite
500 Seiten Bilder (Telefax)
32 MB
64 KB/Seite
500 Bilder (True color)
1,6 GB
3,2 MB/Bild
5 Min. Sprache
2,4 MB
8 KB/sec
5 Min. CD-Audio
52,8 MB
176 KB/sec
5 Min. unkomprimiertes MPEG 1-Video
760 MB
2,5 MB/sec
5 Min. PAL-Video
6,6 GB
22 MB/sec
5 min. HDTV-Video
33 GB
110 MB/sec
Tabelle 1: Volumen und Datenrate verschiedener Medien
Art des Speichers
Typisches Volumen
Datendurchsatz
Hauptspeicher
64 MB
100 MB/sec
Diskette
1,5 MB
30 KB/sec
Magneto-optische Wechselplatte (eine Seite) 300 MB
620 KB/sec
CD-ROM
644 MB
2 MB/sec
Magnetplatte
5 GB
6 MB/sec
Magneto-optische Wechselplatte, Jukebox
50 GB
Magnetband-Wechsler
Bis 600 GB
Tabelle 2: Volumen und Datenrate verschiedener Speicher
27
1 S TAND DER T ECHNIK
Art des Netzwerkes
Datenrate
Telefon
Ca. 2,5 KB/sec
Schmalband-ISDN (64 Kbit-Netz)
2 x 8 KB/sec
Ethernet (praktisch, bei 1:1-Verbindung)
120 KB/sec, 1,2 MB/sec
FDDI (z. Zt. praktisch, theoretisch)
2,4 MB/sec, 12 MB/sec
Tabelle 3: Datenrate verschiedener Netzwerke
Es gibt zwei Arten von Kompressionsverfahren [MMOODB]:
• Bei verlustlosen Verfahren bleiben alle Informationen erhalten. So können bei
der Dekompression die ursprünglichen Daten wiederhergestellt werden.
• Bei verlustbehafteten Verfahren gehen Informationen unwiederbringlich
verloren, die ursprünglichen Daten können also nicht wiederhergestellt werden.
In der Praxis sind diese Systeme jedoch so konzipiert, daß der Unterschied
zwischen dem Original und der komprimierten Version für den Benutzer kaum
wahrnehmbar ist.
Mit verlustloser Kompression läßt sich bei multimedialen Daten ein
Kompressionsfaktor von etwa 2 bis 4 erreichen. Da dies, wie Tabelle 1, Tabelle 2 und
Tabelle 3 deutlich machen, viel zu gering ist, finden zumindest im Video- und
Audiobereich nur verlustbehaftete Verfahren Anwendung.
1.2.2.1 DVI
DVI (Digital Video Interactive) wurde von Intel entwickelt und definiert zwei
Videoformate: Mit PLV (Production-Level Video) können Videos in einer ungefähr
dem VHS-Standard entsprechenden Qualität dargestellt werden. Durch ein proprietäres
Komprimierungsverfahren wird eine Datenrate von etwa 1 MBit/s erreicht. Das zweite
Format nennt sich RTV (Real-Time Video) und hat eine ähnliche Datenrate, bietet
jedoch keine so gute Qualität wie PLV.
1.2.2.2 Motion-JPEG
Dieser Standard orientiert sich an JPEG, einem Komprimierungsformat für Graustufenund Farbbilder. Mit Motion-JPEG werden Videos komprimiert, wobei jedes Einzelbild
entsprechend dem JPEG-Standard komprimiert wird. Damit handelt es sich um ein
28
1.2 D IGITALES V IDEO
Intraframe-Verfahren. Motion-JPEG hat sich im Vergleich zu MPEG nicht richtig
durchgesetzt, da MPEG durch ausgefeiltere Verfahren eine höhere Kompressionsrate
erreicht.
1.2.2.3 MPEG 1
Das Komprimierungsverfahren MPEG 1 verdankt seinen Namen dem internationalen
Standardisierungsgremium „Motion Picture Expert Group“. MPEG 1 ist ein ISOStandard [MPEG1SYS] [MPEG1VID].
Das wichtigste Ziel bei der Entwicklung von MPEG 1 war eine Videokompression mit
einer Datenrate von höchstens 1,5 MBit pro Sekunde. Damit können MPEG 1-Videos
mit den damals handelsüblichen Double Speed-CD-ROM-Laufwerken abgespielt
werden.
MPEG 1 ist ein Verfahren zur Videoübertragung und –speicherung mit den folgenden
Eigenschaften:
• Verlustbehaftete Videokomprimierung
• Beschränkung der Bildgröße auf eine Auflösung von 352 X 240 Bildpunkten
• Neben den Videodaten wird der dazugehörige (Stereo-)Ton ebenfalls
komprimiert.
• Unterstützung von variablen Bitraten
Der Trick, durch den die Komprimierung erreicht wird, besteht darin, daß nicht jedes
einzelne Bild für sich gespeichert wird. Statt dessen wird nur etwa jedes achte Bild
vollständig gespeichert. Für die dazwischen liegenden Bilder werden nur die Differenzen
zu anderen Einzelbildern kodiert. MPEG 1 ist also ein Intraframe-Verfahren. Sofern
kein Schnitt oder Kameraschwenk erfolgt, ähneln sich zeitlich aufeinanderfolgende
Bilder in der Regel sehr stark; so läßt sich eine gute Kompressionsrate erreichen.
Der MPEG 1-Standard sieht drei unterschiedliche Frametypen vor (siehe Abbildung 5):
I-Frames (intrakodiert) sind unabhängig von anderen Bildern als Einzelbilder kodiert.
Damit sind sie die Anker für wahlfreien Zugriff. Im Vergleich zu den anderen beiden
Typen wird nur eine geringe Kompressionsrate erreicht. Die Kodierung von I-Frames
orientiert sich am JPEG-Standard (Joint Photographic Expert Group), der die
Kompression von Graustufen- und Farbbildern spezifiziert.
Zur Dekodierung von P-Frames (predicted) muß auf den jeweils vorherigen I-Frame
und alle darauffolgenden P-Frames zugegriffen werden.
29
1 S TAND DER T ECHNIK
B-Frames (bidirektional) enthalten Informationen über die Unterschiede sowohl zu
vorangegangenen als auch zu nachfolgenden I- und P-Frames. Sie erreichen die
höchsten Kompressionsraten.
Abbildung 5: Die drei Frametypen von MPEG 1-Videos
Die Gesetzmäßigkeit der Folge von I-, P- und B-Frames wird von der konkreten
Anwendung und deren Anforderungen bestimmt. Soll eine möglichst hohe
Komprimierung erreicht werden, muß der Anteil von B-Frames relativ hoch sein. Wenn
dagegen ein möglichst feinkörniger wahlfreier Zugriff gewünscht wird, ist ein hoher
Anteil an I-Frames erforderlich. Als sinnvolle Folge für die meisten praktischen
Anwendungen hat sich die in Abbildung 5 dargestellte Sequenz „I B B P B B P B B I B
B P B B P B B I ...“ herausgestellt. In diesem Fall hat der wahlfreie Zugriff eine
Auflösung von neun Einzelbildern, was etwa 330 ms entspricht.
Die Datenstruktur des MPEG 1-Standards [MPEG1VID] besteht aus einer Hierarchie
von verketteten Elementen (siehe Abbildung 6). So modelliert ein Element des Picture
Layers ein Einzelbild des Videos, das mit anderen Bildern zu einer Group of Pictures
zusammengefaßt wird. Ein Bild besteht aus Slices, diese wiederum aus Macro Blocks
usw. Innerhalb der einzelnen Hierarchiestufen sind die Elemente entsprechend ihrer
Reihenfolge verkettet. Sie enthalten außerdem Referenzen auf das Element in der
jeweils höheren Ebene, zu dem sie gehören, sowie auf das erste Element in der sie
konstituierenden Liste der nächstniedrigeren Stufe.
30
1.2 D IGITALES V IDEO
Abbildung 6: Die MPEG 1-Hierarchie
31
1 S TAND DER T ECHNIK
Ein Video Stream kann als reiner Videodatenstrom existieren, der z. B. von einer
Kamera geliefert wird, oder aus einem in der Abbildung 6 nicht gezeigten ISO 11172
Stream berechnet werden.
Ein Video Stream besteht aus den folgenden Layers:
• Video Sequence Layer: Ein Video Stream kann aus mehreren Video Sequence
Layers bestehen.
• Sequence Header Layer: Der Sequence Header beinhaltet globale Informationen
über die Videosequenz und existiert nur einmal pro Video Sequence Layer. Er
speichert Informationen über die Auflösung, die sogenannte Quantizer Matrix,
die Bildwiederholrate und ähnliche Parameter.
• Group Of Pictures Layer: Die Numerierung der Bilder erfolgt innerhalb ihrer
Gruppe. Es gibt keine globale Numerierung im Video Stream.
• Der Picture Layer beinhaltet Einzelbilder des Videos.
• Macro Block Layer
• Block Layer
Bei MPEG 1 handelt es sich um ein asymmetrisches Verfahren, denn die Kompression
dauert im allgemeinen deutlich länger als die Dekompression. Auch dadurch wird die
Ausrichtung auf den CD-ROM-Markt deutlich.
Weiterhin legt die MPEG 1-Spezifikation nur das Verfahren für die Dekomprimierung
fest. Daher kann das Ergebnis einer Kompression desselben Videos je nach
verwendetem Encoder unterschiedlich ausfallen und seine Qualität schwanken. Die
Qualität eines MPEG 1-Videos ist in der Regel etwas besser als die eines VHS-Videos.
MPEG 1 bietet aber nur ungefähr ein Viertel der bei VHS üblichen Auflösung.
1.1.2.4 MPEG 2
Auch MPEG 2 ist ein ISO-Standard, spezifiziert im Jahre 1994. Im Gegensatz zu
MPEG 1 wird hier Wert auf eine höhere Qualität mit höheren Übertragungsraten gelegt.
So wurde MPEG 2 nicht für das Speichermedium CD-ROM, sondern für die digitale
Übertragung von Filmen in Fernsehqualität, beispielsweise im HDTV-Format, mit
Bitraten zwischen 4 und 9 MBit/sec entworfen.
Die wesentlichen Neuerungen gegenüber MPEG 1 sind die Definition einer Syntax für
das effiziente Kodieren von interlaced Videos sowie skalierbare Erweiterungen, die die
Aufteilung eines Videosignals in zwei oder mehr kodierte Bitstreams erlauben, die das
Video in verschiedenen Auflösungen oder Bildwiederholraten repräsentieren
[MPEG2VID].
32
1.3 V IDEO UND D ATENBANKEN
1.3 Video und Datenbanken
1.3.1 Multimediale Datenbanken
Aus dem Grundgedanken, von den Vorteilen von Datenbankmanagementsystemen
auch bei der Verwaltung multimedialer Daten wie Video-, Audio- und Bildmaterial zu
profitieren, ist die Klasse der multimedialen Datenbanken entstanden.
Multimediale Datenbankmanagementsysteme lassen sich durch die folgenden
Eigenschaften charakterisieren:
• Unterstützung der multimedialen Medien durch eigene Datentypen:
-
diskret: Text, Bilder/Grafiken
-
kontinuierlich: Audio/Sound, Video/Animation
• Ein objektorientiertes Datenmodell mit (mindestens)
-
Typkonstruktoren für generische Typen wie Tupel, Mengen, Felder und
Listen
-
Kapselung von Objekten
-
Typhierarchie
• Eingebaute (!) Datentypen für beliebig lange Bytefolgen (BLOBs, Binary Large
Objects), Text, Bild, Audio, Video und Animation
• Das System ist um neue Datentypen und Operationen erweiterbar.
• Zeitabhängigkeit
• Multimediale Datenbanken sind sehr speicherintensiv. Sei verwalten ein hohes
Datenvolumen auf verschiedenen Speichergeräten.
• Die Eigenschaften von Datenbankmanagementsystemen (s. Kapitel „1.1
Datenbanken“) finden sich auch hier.
• Modellierung von räumlichen und zeitlichen Beziehungen zwischen Objekten
• Präsentation, d. h. Wiedergabe von verschiedenen Medientypen
• Eventuell Integration verschiedener multimedialer Medien
• Scripting: Beschreiben und Festlegen von Abläufen und Synchronisationen
33
1 S TAND DER T ECHNIK
• Inter- und Intra-Objekt-Synchronisation (typisches Beispiel: Synchronisation
von Bild und Ton)
• Interaktion mit dem Benutzer
• Möglichst gute Quality of Service
• Inhaltsorientierter Zugriff
• Information Retrieval: Der Benutzer wird bei der Suche von relevanter
Information zu einer gegebenen Fragestellung vom System unterstützt.
Wie bereits im Kapitel „1.1.2 Datenbankmodelle“ erwähnt, eignen sich objektrelationale
Datenbankmanagementsysteme besonders gut für multimediale Anwendungen.
1.3.2 Das Video Foundation-DataBlade
Bei dem im Kapitel „1.1.3 Informix Dynamic Server“ näher erläuterten und für die
Implementierung des in dieser Arbeit vorgestellten Systems verwendeten
Datenbanksystem handelt es sich nicht um eine multimediale, sondern um eine
objektrelationale Datenbank. Der Informix Dynamic Server läßt sich jedoch einfach
durch die im gleichen Kapitel erwähnten DataBlades um multimediale Funktionalität
erweitern. Besonders hilfreich für die Aufgabenstellung war das Video Foundation
DataBlade, das daher im folgenden kurz vorgestellt wird.
Es bietet folgende Features:
• Es dient als Grundlage („Foundation“) für alle Erweiterungen des Dynamic
Server, die in den Bereich Video fallen.
• Es definiert eine generelle Architektur für die Erweiterung des
Datenbanksystems um den Datentyp Video. Diese Architektur stützt sich auf
drei Komponenten (siehe Abbildung 7):
- Der Dynamic Server verwaltet die Metadaten und kontrolliert den Zugriff auf
den externen Speichermanager, beispielsweise einen Videoserver oder eine
Magnetbandmaschine.
- Der externe Speichermanager übernimmt die physikalische Speicherung des
Videomaterials.
- Die Anwendung benutzt SQL zur Interaktion mit dem Dynamic Server und
kann für zeitkritische Operationen direkt auf den externen Speichermanager
zugreifen. Der direkte Zugriff wird beim Dynamic Server angefordert und
von ihm kontrolliert.
34
1.3 V IDEO UND D ATENBANKEN
Abbildung 7: Architektur des Video Foundation-DataBlades
• Es definiert ein einheitliches Datenmodell für die Verwaltung von Metadaten
über Videos in der Datenbank. Dieses Datenmodell spezifiziert zwei Kategorien
von Tabellen, um die Metadaten in der Datenbank zu speichern (siehe
Abbildung 8; aus Gründen der Übersichtlichkeit wurden einige Tabellen
ausgelassen, deren Beschreibung sich in [VFDB] findet):
- Tabellen für technische und physikalische Metainformationen wie die
Bildwiederholrate oder den Videostandard (VidMDGeneral, VidMedia,
VidPVideo, VidPAudio, VidPOther)
- Tabellen für inhaltsorientierte Metainformationen über das Video wie
Beschreibungen von Szenen (VidChunkMD, VidTextDesc, VidImgDesc,
VidAudDesc, VidVidDesc, VidStrata)
35
1 S TAND DER T ECHNIK
Abbildung 8: Entity-Relationship-Diagramm der wichtigsten Tabellen des
Video Foundation-DataBlades
• Es verfügt über eine generische, d. h. vom verwendeten Speichermedium
unabhängige Schnittstelle; für die Schnittstelle ist nicht relevant, ob das Video
auf einem Magnetband, einem Videoserver oder als Datei im Dateisystem liegt.
• Abschnittsweise Verwaltung von Videos
• Schnittstelle zu Videoservern
• Verwaltung von strukturellen Metadaten in Strata. Ein Stratum ist eine
Beschreibung eines Segmentes, was die Abbildung 9 verdeutlicht: Die WhoStrata beschreiben beispielsweise die in einer Szene agierenden Personen.
36
1.3 V IDEO UND D ATENBANKEN
Abbildung 9: Strata
37
2 Anforderungsanalyse
Die Anforderungen an das zu entwickelnde System lassen sich aus den
Anwendungsfällen ableiten, für die das System konzipiert wurde. Im folgenden sollen
daher einige Benutzungsszenarios vorgestellt und ihr Bezug zum System aufgezeigt
werden. Wichtig dabei ist die Antwort auf die Frage, welche Rolle strukturelle
Metadaten spielen, da deren Bereitstellung die wesentliche Aufgabe des MPEGDataBlades ist.
2.1 Benutzungsszenarios
2.1.1 Verwaltung von MPEG-Videos
Ein Anwendungsfall ist die Verwaltung und Archivierung mehrerer Videos. In seinem
Archiv kann der Benutzer neue Filme hinzufügen, sich eine Liste der im System
gespeicherten Filme ansehen und einen Film zur weiteren Bearbeitung auswählen.
Von Bedeutung ist dabei, wieviel Funktionalität das Archivierungssystem dem Benutzer
zur Verfügung stellen soll. Bei Beschränkung auf die unbedingt notwendige
Funktionalität wäre für die Verwaltung das Dateisystem des Betriebssystems
ausreichend.
Um dem Benutzer das Auffinden eines bestimmten Filmes zu erleichtern, wäre jedoch
weitere Funktionalität wünschenswert, beispielsweise die Möglichkeit, nicht nur nach
Filmtiteln und anderen Attributen eines Filmes wie etwa Regisseur oder Drehbuchautor
zu suchen, sondern auch nach inhaltlichen Beschreibungen, etwa in Form von Stratas
(siehe Abbildung 9).
Da ein Zugriff auf strukturelle Metadaten dazu nicht benötigt wird, ist die Funktionalität
eines Videoservers, der über das Video Foundation-DataBlade angesteuert wird, für
diesen Fall ausreichend.
2.1.2 Zugriff auf Segmente eines MPEG-Videos
2.1.2.1 Digitaler Videoschnitt
Als weiteres Szenario möchte der Benutzer ein neues Video zusammenschneiden und
dazu Teile von gespeicherten Filmen kopieren.
39
2 A NFORDERUNGSANALYSE
Wenn auf Segmente von umkomprimierten Videos zugegriffen werden soll, sind
strukturelle Metadaten unwichtig, da die einzelnen Bilder auch als solche gespeichert
sind. Handelt es sich dagegen um ein komprimiertes Video, müssen strukturelle
Metadaten verfügbar sein, um eine Sequenz von Bildern extrahieren zu können.
2.1.3 Zugriff auf strukturelle Metadaten eines MPEG-Videos
Für einige Anwendungen müssen die in den MPEG-Standards [MPEG1VID] und
[MPEG2VID] definierten strukturellen Metadaten eines MPEG-Videos, beispielsweise
der picture_coding_type am Anfang des Picture Layers, abgefragt werden können. Die
Notwendigkeit des Zugriffs auf diese strukturellen Metadaten soll im folgenden anhand
einiger Beispiele verdeutlicht werden.
2.1.3.1 Erkennen von Szenenwechseln
Bei der Verwaltung von Videomaterial ist es hilfreich, die Daten in handhabbare
Einheiten zu zerlegen und sie zu indexieren. Dafür wäre eine rechnergestützte
Schnitterkennung bzw. eine Erkennung von Szenenwechseln wünschenswert. Ein
Schnitt ist dabei ein diskontinuierlicher Übergang von einer Szene in eine andere ohne
Überblendungen (Fades).
Für die Schnitterkennung existieren verschiedene Verfahren [MMOODB]. Im
wesentlichen wird ein Schnitt dann erkannt, wenn die Differenz zwischen Bereichen
zweier aufeinanderfolgender Einzelbilder eine bestimmte Schwelle überschreitet. Somit
sind Zugriffe auf Teilflächen eines Bildes bis hinunter zu einzelnen Pixeln erforderlich.
2.1.3.2 Objekterkennung
Der Zugriff auf strukturelle Metadaten ist auch bei der rechnerunterstützten
Objekterkennung wichtig. Von einer Fernsehübertragung eines Fußballspieles
beispielsweise sind vor allem die Szenen interessant, in denen ein Tor geschossen wird
oder der Ball nach einem Schuß auf das Tor dieses nur knapp verfehlt. Daher wäre es
hilfreich, automatisch genau die Einzelbilder zu erkennen, in denen die Torpfosten
sichtbar sind. Ein Objekterkennungsalgorithmus würde mit Methoden wie Kanten- und
Eckenerkennung versuchen, die Torpfosten zu finden.
2.1.3.3 Watermarking
Unter Watermarking versteht man die Überlagerung eines Bild mit einem zweiten, das
beispielsweise Informationen über den Urheber des ersten Bildes enthält. Das zweite
Bild kann dabei nach der Überlagerung sichtbar oder unsichtbar sein. So lassen sich
Copyrightinformationen im Bild selbst codieren. Bei Manipulationen am Bildmaterial
40
2.1 B ENUTZUNGSSZENARIOS
wird das Watermark mit verändert; so läßt sich die Authentizität von Bildern feststellen.
Die Abbildung 10 zeigt ein Beispiel einer sichtbaren Überlagerung, das aus [IBM]
übernommen wurde.
Abbildung 10: Sichtbare Überlagerung mit einem Watermark. Links das
Watermark, rechts die Überlagerung.
Um ein MPEG-Video mit Watermarks zu versehen, ist es sehr hilfreich, eine
Modifikation von Helligkeits- und Farbwerten durchführen zu können. Dazu muß man
auf verschiedene Codes von mehreren Layers der MPEG-Hierarchie (s. Kapitel „1.2.2
Komprimierungsstandards“) zugreifen und diese verändern.
2.1.3.4 Adaption
Als zweites Beispiel wäre eine Adaption von MPEG-Filmen hinsichtlich der Auflösung
oder der Framerate in Bilder pro Sekunde denkbar, um die Wiedergabe von Videos auch
auf weniger leistungsstarken Systemen oder in Netzwerken mit niedrigen
Durchsatzraten zu ermöglichen.
Für die Adaption multimedialer Daten gibt es allgemein zwei Strategien [Adaption]:
Entweder werden einige Präsentationseinheiten (bei Videos wären das Einzelbilder)
ausgelassen, oder das zu präsentierende Objekt ist mehrfach in unterschiedlicher
Wiedergabequalität vorhanden. Im letzteren Fall wird die Version ausgewählt, die das
wiedergebende System nicht überfordert.
Bei der Adaption von MPEG-Videos ist bei der erstgenannten Adaptionsstrategie ein
Zugriff auf strukturelle Metadaten der MPEG-Struktur nötig, vor allem auf die
Frametypen und die Header der einzelnen Layer. Die Frametypen sind wichtig, da bei
Auslassen eines P- oder sogar eines I-Frames die diese Frames referenzierenden
Einzelbilder nicht mehr dargestellt werden können. B-Frames können dagegen
problemlos ausgelassen werden.
41
2 A NFORDERUNGSANALYSE
2.1.3.5 Panoramabilder
Ein Panoramabild entsteht durch Verarbeitung einer Filmsequenz zu einem einzigen
Bild. So kann aus einem Kameraschwenk oder einer Kamerafahrt ein Bild generiert
werden, das die gesamte aufgenommene Szenerie, das „Panorama“, zeigt. Abbildung 11
und Abbildung 12 verdeutlichen die Entstehung eines Panoramabildes.
Abbildung 11: Bild 1 und 150 einer Kamerafahrt
Abbildung 12: Panoramabild
Die Abbildung 11 zeigt das erste und einhundertfünfzigste Bild einer Kamerafahrt
entlang einer Häuserzeile. Aus den Einzelbildern der Kamerafahrt wurde
rechnergestützt das Panoramabild in Abbildung 12 generiert. Wie das Beispiel zeigt,
können die Sicht behindernde oder anderweitig störende Objekte bei der Herstellung
eines Panoramabildes entfernt werden: Der Baumstamm im Vordergrund des linken
42
2.1 B ENUTZUNGSSZENARIOS
Bildes aus Abbildung 11 ist im resultierenden Panoramabild nicht mehr zu sehen. Statt
dessen können wir jetzt sehen, was hinter ihm liegt und vorher von ihm verdeckt wurde.
Im einzelnen erfolgt die Herstellung eines Panoramabildes in fünf Schritten:
1. Analyse von Kamerabewegung und Zoom
2. Verarbeitung der einzelnen Bilder unter Beachtung von Kameraposition und
Zoom in/Zoom out
3. Die Einzelbilder werden so übereinander projiziert, daß die Bildpunkte jedes
Einzelbildes mit ihrer Position in dem resultierenden Panoramabild
übereinstimmen.
4. Bei sich überlappenden Bildpunkten ist der resultierende Bildpunkt im
Panoramabild deren Median.
5. Sich bewegende Objekte werden herausgefiltert.
Als eine Anwendung von Panoramabildern sei die Analyse von Fußballspielzügen
genannt [Yow]. Abbildung 13 zeigt Einzelbilder aus der digitalisierten
Fernsehübertragung eines Fußballspiels und Abbildung 14 ein daraus generiertes
Panoramabild.
Abbildung 13: Einzelbilder aus der Fernsehübertragung eines Fußballspiels
43
2 A NFORDERUNGSANALYSE
Abbildung 14: Panoramabild
Sich bewegende Objekte wie die Spieler und der Fußball wurden herausgefiltert. Das hat
nebenbei zur Folge, daß einige Details wie die Markierung des Strafraums und des
Fünfmeterraums verloren gehen.
Da der Umriß, die Farbe und die Größe der sich bewegenden Objekte bekannt sind,
können diese erkannt und ihre Bewegungsrichtung verfolgt werden. So wurde in
Abbildung 15 der Ball, der bei der Herstellung des Panoramabildes herausgefiltert
worden ist, wieder eingefügt.
Abbildung 15: Panoramabild mit Ball
Auf die gleiche Weise werden auch die Spieler wieder in das Panoramabild eingefügt
(siehe Abbildung 16). Das resultierende Bild zeigt die Bewegungen aller Spieler und
veranschaulicht so die Taktik der beiden Mannschaften.
44
2.1 B ENUTZUNGSSZENARIOS
Abbildung 16: Panoramabild mit Ball und Spielern
Anwendung könnten solche Bilder beispielsweise bei der Analyse eines Fußballspiels im
Fernsehen im Anschluß an die Übertragung des Spiels finden.
2.1.3.6 Evaluierung von Encodern
Wenn interne Details eines MPEG-Videos bekannt sind, kann damit auf die Qualität
der Kodierung eines Videos geschlossen werden. So wäre beispielsweise für ein kurzes
Video mit 20 Bildern die Kodierungsreihenfolge „I P B B B B B B B B P B B B B B B
B B B“ wegen der höheren Komprimierung eindeutig der Reihenfolge „I I I I I I I I I I
I I I I I I I I I I“ vorzuziehen, wobei hier die Buchstaben I, P und B für die im Kapitel
„1.2.2 Komprimierungsstandards“ näher erläuterten Frametypen stehen. Dafür bietet
die letztere Reihenfolge einen feinkörnigeren wahlfreien Zugriff. Damit ist die
Grundlage für die Entwicklung von Qualitätsbenchmarks für Software-Encoder oder
für Hardwarelösungen in Form von MPEG-Erweiterungskarten geschaffen.
45
3 Entwurf
Die Realisierung erfolgte als DataBlade für den Informix Dynamic Server. Als
Videoformate werden MPEG 1 und MPEG 2 unterstützt, da es sich dabei um
weitverbreitete Standards mit guten Kompressionsraten handelt.
3.1 Entwurfsansatz
3.1.1 Prinzipien
Mit einem DataBlade-Moduls soll möglichst vielen Anwendungen Funktionalität
bereitgestellt werden. Um dieses Ziel zu erreichen, ist es ratsam, die folgenden
Entwurfsprinzipien zu beachten [DBDK]:
• Der gesamte Entwurf sollte möglichst einfach gehalten und nicht überfrachtet
werden.
• Das User Interface sollte von den abstrakten Operationen auf den definierten
Datentypen getrennt werden.
• Die Kombination aus den dem Benutzer zugänglichen Datentypen und
Funktionen ist so zu wählen, das typische SQL-Anfragen möglichst einfach
formulierbar sind. Diesem Thema widmet sich das Kapitel „3.2 Spezifikation der
SQL-Schnittstelle“.
• Bei der Entscheidung, ob eine Routine im DataBlade, d. h. auf dem
Datenbankserver implementiert wird, oder ob ihre Realisierung der Anwendung
überlassen bleibt, können die folgenden Gesichtspunkte als Grundlage dienen:
-
Ein DataBlade sollte nur Routinen enthalten, die von vielen Anwendungen
benötigt werden. (Dies bietet nebenbei eine elegante Möglichkeit zum Code
Sharing.) Spezielle Funktionen, die nur für eine bestimmte Anwendung
benötigt werden, werden in der Anwendung selbst implementiert.
-
Wenn durch die Realisierung auf dem Datenbankserver ein geringeres
Datenvolumen über das Netzwerk zum Client geschickt werden kann, indem
z. B. nur das Ergebnis einer Berechnung und nicht alle zur Berechnung
benötigten Daten übertragen werden, ist die Funktion im DataBlade zu
implementieren.
47
3 E NTWURF
• Wenn ein Datentyp seiner Natur nach unteilbar ist oder seine Implementierung
dem Benutzer nicht zugänglich sein soll, ist es angebracht, ihn als opaquen Typ
zu definieren.
• Für die üblichen Operationen zum Zugriff auf opaque Typen sind vom
DataBlade entsprechende Funktionen zur Verfügung zu stellen.
3.1.2 Grundsätzliche Überlegungen
Beim Versuch, einen top down-Entwurf durchzuführen, ist der erste Schritt die Suche
nach den die API konstituierenden Funktionen, d. h. nach deren Signatur; gefragt sind
also ein neuer Datentyp und auf ihm definierte Operatoren. Schon bei der Definition
der üblichen Operatoren wie Vergleichsoperatoren stellen sich Fragen nach deren
Semantik: Wann ist beispielsweise ein Video größer als ein anderes?
Auch bei dem Versuch, eine Signatur von Operatoren zu definieren, die den im Kapitel
„2.1 Benutzungsszenarios“ dargestellten Anforderungen genügen, ergeben sich
Probleme. Wenn z. B. Bilder mit Watermarks versehen werden sollen, läßt sich ein
Operator mit der Signatur Bild r Bild Ü Bild definieren, der ein Bild mit einem zweiten
Bild, dem Watermark, überlagert. Bei (MPEG-)Videos gibt es keine eindeutige
Vorgehensweise, sondern viele unterschiedliche Verfahren zum Watermarking, so daß
die Definition eines oder auch mehrerer Operatoren zu restriktiv wäre.
Statt dessen ist für die Unterstützung der verschiedenen Watermarking-Verfahren wie
auch für andere Anwendungsbereiche der Zugriff auf strukturelle Metadaten eines
MPEG-Videos nötig, was im Kapitel „2.1.3 Zugriff auf strukturelle Metadaten eines
MPEG-Videos“ näher begründet wird. Zentrale Aufgabe des MPEG-DataBlades muß
es daher sein, den Zugriff auf die MPEG-Datenstruktur ermöglichen. Es ist also ein
„low-level“-DataBlade, das z. B. das eigentliche Watermarking nicht durchführt,
sondern nur die Voraussetzungen dazu schafft. Für die verschiedenen Methoden zum
Watermarking könnte ein eigenes DataBlade entwickelt werden, das auf dem MPEGDataBlade aufbaut, genauso wie das MPEG-DataBlade seinerseits auf dem Video
Foundation-DataBlade aufbaut (siehe Kapitel „4.1 Bereits existierende Module“).
3.2 Spezifikation der SQL-Schnittstelle
Ein DataBlade besteht aus Datentypen sowie darauf aufbauenden Tabellen und
Funktionen. Diese bilden die Schnittstelle des DataBlades nach außen. Wie für
Datenbanktabellen üblich, ist die Sprache dieser Schnittstelle SQL. Objektrelationales
SQL bietet als Abfragesprache für objektrelationale Datenbanken auch die Möglichkeit,
benutzerdefinierte Funktionen aufzurufen.
48
3.2 S PEZIFIKATION DER SQL-S CHNITTSTELLE
Um die im Kapitel „2.1 Benutzungsszenarios“ aufgestellten Anforderungen zu erfüllen,
soll das MPEG-DataBlade den Zugriff auf strukturelle Metadaten wie Frametypen,
Bewegungsvektoren, Bitraten oder die Auflösung bieten. Im folgenden sollen zwei
Entwurfsalternativen einer Schnittstelle unter Verwendung von objektrelationalem SQL
vorgestellt werden.
3.2.1 Erste Alternative: Abbildung der MPEG-Hierarchie
Der MPEG-Standard modelliert Videos mit einer Hierarchie untereinander verketteter
Layer (siehe Kapitel „1.2.2 Komprimierungsstandards“, besonders Abbildung 6).
Für den Entwurf einer SQL-API liegt es daher nahe, diese Hierarchie durch das
Datenbankschema abzubilden. Dann gäbe es für jede Hierarchiestufe einen
entsprechenden Tabellentyp in der Datenbank.
3.2.1.1 Datentypen und Tabellen
Der Datentyp MPEGLibrary dient zur Verwaltung der verschiedenen Videos:
create row type MPEG1_Library
(
id
int not null primary key,
top_layer
ref(MPEG1_Layer),
title
text,
description
text
);
Dabei ist id ein eindeutiger Bezeichner und top_layer eine Referenz auf die höchste
Hierarchiestufe. title ist der Titel des Videos, und description beinhaltet
benutzerdefinierbare Informationen über das Video wie eine kurze Beschreibung des
Inhalts.
Der Datentyp MPEG_Layer wird zur Definition von Daten einer Hierarchiestufe
benötigt. MPEG_Layer ist ein abstrakter Typ, von dem es keine Tabellen gibt. Alle
Typen, die die verschiedenen Layers modellieren, erben von diesem Typ.
create row type MPEG_Layer
(
id
int not null primary key,
higher_layer
ref(MPEG_Layer),
lower_layer
ref(MPEG_Layer),
previous_element
ref(MPEG_Layer),
next_element
ref(MPEG_Layer),
data
large_object not null unique
);
49
3 E NTWURF
Auch hier ist id ein eindeutiger Bezeichner. higher_layer ist eine Referenz auf die
nächsthöhere und lower_layer auf die nächstniedrigere Hierarchiestufe.
previous_element und next_element sind Verweise, die zur Verkettung
innerhalb des jeweiligen Layers dienen. data beinhaltet die binären Daten wie
Headerinformationen, die für den Layer definiert sind.
Für alle weiteren Layer gibt es nun einen Datentyp, der von MPEG_Layer erbt und
damit dieselben Datenfelder besitzt. Als Beispiel sei hier die Definition des Picture
Layers aufgeführt:
create row type MPEG_PictureLayer under MPEG_Layer;
Von diesen Typen werden Tabellen angelegt. Stellvertretend für alle Layer dient wieder
der Picture Layer als Beispiel:
create table MPEG_Pictures of type MPEG1_PictureLayer under
MPEG1_Layer_Table;
3.2.1.2 Funktionen
Die Prozedur WriteStreamToDb liest den Stream, der durch den als ersten Parameter
übergebenen Dateinamen definiert wird, und erzeugt die interne Repräsentation des
Streams in der Datenbank. Außerdem wird ein entsprechender Eintrag in der Tabelle
MPEG1_Library erzeugt. Die Datenfelder title und description dieses
Eintrages werden durch den zweiten bzw. dritten Parameter spezifiziert:
WriteStreamToDb(text, text, text)
Um auf die Daten des Stream zugreifen zu können, werden Funktionen zur Navigation
in der Hierarchie zur Verfügung gestellt. Diese sind für alle Layer gleich.
So gibt die Funktion getHigherLayerEntry einen Zeiger auf das erste Element der
nächsthöheren Hierarchiestufe relativ zu der Stufe zurück, zu der das als Parameter
übergebene Element gehört.
getHigherLayerEntry(pointer) returns pointer
Analog wird getLowerLayerEntry definiert. Innerhalb einer Hierarchiestufe kann
mit getNextEntry und getPreviousEntry navigiert werden. Beide Funktionen
besitzen dieselbe Signatur wie getHigherLayerEntry:
getNextEntry(pointer) returns pointer
50
3.2 S PEZIFIKATION DER SQL-S CHNITTSTELLE
Für den Zugriff auf die binären Daten des jeweiligen Elementes gibt es die Funktion
getStream. Diese liefert nicht nur die Daten des als Parameter übergebenen
Elementes, sondern auch die Daten aller in der Hierarchie darunter liegender Elemente:
getStream(pointer) returns pointer
Damit läßt sich das Video in Ausschnitten oder auch vollständig rekonstruieren.
Um nicht auf die binären Daten als Large Object, sondern auch auf die einzelnen
Metadaten eines MPEG-Videos zugreifen zu können, werden für jeden Layer
spezifische Funktionen definiert, die die entsprechenden Daten liefern. Für den Picture
Layer beispielsweise sind das die folgenden (vgl. [MPEG1VID]):
getFullPelForwardVector
getForwardFCode
getFullPelBackwardVector
getBackwardFCode
getExtraInformationPicture
getPictureExtensionData
getUserData
getTemporalReference
getPictureCodingType
getVbvDelay
(pointer)
(pointer)
(pointer)
(pointer)
(pointer)
(pointer)
(pointer)
(pointer)
(pointer)
(pointer)
returns
returns
returns
returns
returns
returns
returns
returns
returns
returns
boolean
int1
boolean
int1
pointer
pointer
pointer
integer
int1
integer
Diese Funktionen parsen den jeweils relevanten Teil des MPEG-Streams und suchen
die gewünschten Informationen heraus.
3.2.1.3 Bewertung
Die Abbildung der MPEG-Hierarchie durch das Datenbankschema modelliert die
MPEG-Datenstruktur und ist somit naheliegend. Die im Kapitel „2.1
Benutzungsszenarios“ dargestellten Anforderungen sind erfüllt. Wegen der Menge der
anfallenden Daten ist dieser Ansatz jedoch kaum praktikabel: Ein MPEG-Video in
Spielfilmlänge belegt einige hundert MB an Speicherplatz; der Speicherbedarf für die die
MPEG-Struktur abbildenden Tabellen kommt noch dazu. Auch, wenn auf das
Datenfeld data in der Tabelle MPEG_Layer verzichtet wird und statt dessen ein
Videoserver die Daten liefert, fällt noch eine immense Menge an Metadaten an.
Der Ansatz könnte verbessert werden, indem nur die Ebenen der MPEG-Hierarchie
gespeichert werden, die für die jeweilige Anwendung relevant sind. Die Tiefe der
Modellierung wäre dann konfigurierbar und könnte generisch angepaßt werden. Auch
das Anlegen von Indizes kann je nach Bedarf stattfinden oder nicht. Das
51
3 E NTWURF
Speicherplatzproblem würde durch diese Überlegungen allerdings nur wenig verringert;
grundsätzlich befindet sich der Speicherplatzbedarf noch in derselben Größenordnung.
Für diesen Ansatz sind noch weitere Modifikationen denkbar. So könnten aus
Performanzgründen manche Informationen in entsprechenden Feldern von
Datenbanktabellen persistent gespeichert werden und müßten dann nicht mehr aus dem
Large Object berechnet werden. Der Speicherplatzbedarf würde dadurch jedoch weiter
anwachsen.
Als weiterer Nachteil ist bei diesem Ansatz oft der Aufruf von Navigationsfunktionen
wie getNextEntry erforderlich, die überhaupt keine Nutzdaten liefern. Daraus
resultiert eine schlechte Performanz, da jeder Aufruf einer Funktion aus einem
DataBlade verglichen mit einem normalen Prozeduraufruf relativ lange dauert.
Eine Verallgemeinerung der obigen Überlegungen zur Konfigurierbarkeit soll im
folgenden vorgestellt werden.
3.2.2 Zweite Alternative: Funktionale Sicht
Führt man die Überlegungen zur Konfigurierbarkeit fort, stellt sich die Frage, warum
überhaupt ein starres Datenbankschema vordefiniert werden soll. Als Alternative dazu
könnte die Schnittstelle so entworfen werden, daß der Benutzer seine Tabellen selbst
definiert. Das würde auch die Rolle des MPEG-DataBlades als low level-Blade
unterstreichen.
3.2.2.1 Tabellen
Aus dem Grundgedanken, kein Datenbankschema vorzugeben, ergibt sich, daß die
Granularität der Modellierung mit Tabellen ein ganzes Video ist. Es wird also eine
Tabelle benötigt, die die einzelnen Videos repräsentiert:
create table media(
title
author
description
value
parsetree_filename
);
varchar(50),
varchar(50),
varchar(250),
MedLoc not NULL,
varchar(250)
Die ersten drei Datenfelder speichern eine textuelle Beschreibung des Videos. Das Feld
value ist eine Referenz auf den Speicherort eines Videos, beispielsweise auf einem
Videoserver. Zusammen mit dem folgenden Datenfeld parsetree_filename wird
es im Kapitel „4 Realisierung“ näher beschrieben.
52
3.2 S PEZIFIKATION DER SQL-S CHNITTSTELLE
3.2.2.2 Funktionen
Zur besseren Unterscheidung beginnen alle Funktionen des MPEG-DataBlades mit
dem Präfix MPEG.
Ein neues Video muß in der Tabelle media registriert werden. Das wäre mit einem
insert-Statement möglich. Um den Benutzer der SQL-API nicht mit internen
Verwaltungsdaten zu konfrontieren, stellt das MPEG-DataBlade hierfür eine spezielle
Funktion zur Verfügung:
MPEGcreateVideo(lvarchar, lvarchar, lvarchar, lvarchar)
Als die ersten drei Parameter werden der Titel, der Autor und eine kurze Beschreibung
des Videos erwartet (vgl. die ersten drei Datenfelder der Tabelle media). Das vierte
Argument spezifiziert einen Dateinamen eines MPEG-Videos im Unix-Dateisystem.
Ein Beispielaufruf wäre:
execute procedure MPEGcreateVideo(
'Random', 'Alan Smith', 'Dices flying around',
'/home/mierse/mpg/random.mpg'
);
Weitere Details zu dieser Funktion und ihre Implementierung finden sich im Kapitel „4
Realisierung“.
Die weiteren Funktionen dienen dem Zugriff auf die strukturellen Metadaten eines
MPEG-Videos. Der erste Parameter aller Funktionen ist eine Referenz auf den
Speicherort eines Videos, gibt damit das vom Benutzer gewünschte Video an und
entspricht dem vierten Datenfeld der Tabelle media. Viele Funktionen haben Indizes
als weitere Argumente, beispielsweise eine Bildnummer. Als Funktionsergebnis liefern
sie die jeweils gewünschte Information.
Anhand der Rückgabewerte lassen sich die Funktionen in zwei Kategorien einteilen: Sie
liefern entweder nur einen Wert, der eine Information über ein Element der MPEGDatenstruktur, z. B. über ein Bild, darstellt, oder geben mehrere Werte, beispielsweise
von mehreren Bildern, zurück.
Als Beispiel seien hier drei Funktionen aufgeführt. Der Code der Implementierung
einiger ausgewählter Funktionen wird in Anhang B: Implementierung der DataBladeFunktionen aufgeführt. Eine vollständige Auflistung aller Funktionen findet sich in
Anhang C: Funktionen des MPEG-DataBlades.
MPEGgetStreamMode (MedLoc)
MPEGgetPictCodType (MedLoc, integer)
MPEGgetFrameorder (MedLoc)
53
returns lvarchar
returns integer
returns lvarchar
3 E NTWURF
Die Funktion MPEGgetPictCodType erwartet als zweites Argument die Nummer des
Bildes, dessen Frametypen sie zurückgibt. Die anderen beiden Funktionen benötigen
außer der Referenz auf das Video keine weiteren Parameter. Im Gegensatz zu den
beiden ersten Funktionen liefert MPEGgetFrameorder nicht nur einen Wert, sondern
alle Frametypen des gesamten Videos.
Die drei vorgestellten Funktionen können in der folgenden Weise aufgerufen werden:
select MPEGgetStreamMode
where title='Random';
select MPEGgetPictCodType
where title='Random';
select MPEGgetFrameorder
where title='Random';
(value)
from media
(value, 5)
from media
(value)
from media
Der Benutzer des DataBlades kann sich nun eigene Tabellen definieren und diese mit
den Daten füllen, die das MPEG-DataBlade durch seine Funktionen zur Verfügung
stellt. Um die obigen Beispiele fortzuführen, sei für einen Anwendungsfall eine Tabelle
nützlich, die von allen Videos den Stream Mode enthält, etwa um einen Überblick zu
erhalten, welche Videos eine Tonspur haben und welche nicht. Diese kann wie folgt
deklariert werden:
create table myVideos(
value
MedLoc,
streamMode
lvarchar
);
Die Tabelle myVideos kann mit dem folgenden Statement gefüllt werden:
insert into myVideos
select value, MPEGgetStreamMode(value) from media;
Analog lassen sich je nach Anwendungsfall weitere Tabellen definieren und mit Daten
füllen.
3.2.2.3 Bewertung
Auch die zweite Alternative genügt allen Anforderungen, die im Kapitel „2.1
Benutzungsszenarios“ dargestellt wurden. Ihre Schnittstelle ist jedoch wesentlich
einfacher, klarer, übersichtlicher und damit leichter verständlich als die erste Alternative.
Das Datenbankschema kommt mit deutlich weniger Tabellen, nämlich nur einer aus.
Zusätzliche Funktionen, die nicht direkt Metadaten eines MPEG-Videos liefern wie die
Navigationsfunktionen des ersten Ansatzes, gibt es nicht mehr. Das
Speicherplatzproblem ist optimal gelöst: Liegen die Videos auf einem Videoserver,
speichert die Datenbank nur noch genau die Daten in Tabellen, die der Benutzer
definiert; der Verwaltungs-Overhead ist mit der Tabelle media, die genau einen Eintrag
54
3.2 S PEZIFIKATION DER SQL-S CHNITTSTELLE
pro Video enthält, verschwindend gering. Damit hat der zweite Ansatz keinen der
Nachteile des ersten. Weiterhin genügt die zweite Alternative auch den im Kapitel „3.1.1
Prinzipien“ vorgestellten Entwurfsrichtlinien.
Falls doch eine Modellierung der MPEG-Hierarchie durch das Datenbankschema
gewünscht wird, ist dies weiterhin möglich, indem der Benutzer wie im ersten Ansatz
jeweils eine Tabelle für jede Hierarchiestufe anlegt.
Die zweite Alternative ist gegenüber der ersten also in jedem Falle vorzuziehen.
55
4 Realisierung
Aufgrund seiner Vorteile wurde der im Kapitel „3.2.2 Zweite Alternative: Funktionale
Sicht“ dargestellte Ansatz zur Realisierung ausgewählt. In diesem Kapitel soll nun seine
Implementierung vorgestellt werden.
4.1 Bereits existierende Module
Das MPEG-DataBlade setzt neben dem Informix Dynamic Server auf drei unabhängig
von ihm entwickelte Module auf. Dabei handelt es sich um eine MPEG-Library, das
Video Foundation-DataBlade sowie einen Videoserver.
4.1.1 MPEG-Library
Die MPEG-Library ist eine in C++ geschriebene Klassenbibliothek. Sie bietet einen
Zugriff auf verschiedene Metadaten von MPEG 1- und MPEG 2-Videos.
Grundsätzlich ist die MPEG-Library ein eigenständiges Modul, das nicht an ein
Datenbanksystem oder einen Videoserver gebunden ist. Sie ist mit einem kurzen
zusätzlichem Hauptprogramm alleine lauffähig und erwartet die einzulesenden Videos
dann als Dateien im Dateisystem. Für das MPEG-DataBlade wurde sie so modifiziert,
daß sie die Videos über die generische Schnittstelle des Video Foundation DataBlade
von einem Videoserver liest (siehe Kapitel „4.4 Integration der bereits existierenden
Module“).
Die wesentliche Funktionalität der MPEG-Library besteht darin, ein MPEG-Video
einzulesen, entsprechend der Spezifikation [MPEG1VID] [MPEG2VID] zu parsen und
dabei einen Parse Tree aufzubauen, in dem die Metadaten gespeichert werden. Für den
Zugriff auf die Metadaten werden entsprechende Funktionen angeboten. Um von einem
bestimmten Element der MPEG-Hierarchie, etwa einem Bild, Informationen
abzufragen, muß in der Regel vor dem Aufruf der Funktion in der Datenstruktur des
Parse Trees erst zu dem Element navigiert werden.
Damit nicht bei jedem Zugriff auf Metadaten der Parse Tree neu aufgebaut werden
muß, bietet die Library die Möglichkeit, ihn nach dem Aufbau persistent zu speichern
und zu einem späteren Zeitpunkt neu einzulesen. Diese Möglichkeit erhöht die
Performanz beträchtlich, da der Aufbau des Parse Tree bereits bei relativ kurzen Videos
einige Zeit in Anspruch nimmt.
57
4 R EALISIERUNG
Weiterhin unterstützt die MPEG-Library über einen Index den wahlfreien Zugriff auf
Einzelbilder, was bei der MPEG-Datenstruktur mit ihren Vorwärts- und
Rückwärtsverkettungen durchaus nicht trivial ist. Damit ist die Library geradezu
prädestiniert für digitalen Videoschnitt.
Außerdem können einzelne Bilder eines Videos dekodiert und als Bilddatei in den
Formaten YUV, SIF, TGA und PPM gespeichert werden. Auch dieses Feature ist nicht
trivial zu implementieren, besonders dann, wenn es sich bei dem zu dekodierenden Bild
nicht um einen I-Frame handelt.
Die Abbildung 17 zeigt die wesentlichen Klassen des Parse Trees: Über einen Index in
der Klasse VideoStream wird der wahlfreie Zugriff auf Einzelbilder realisiert. Die
MPEG-Hierarchie (siehe Abbildung 6) wird durch die Klassen VideoStream,
VideoSequence, GOP (für Group Of Pictures), Picture und Slice modelliert.
Die Navigation im Parse Tree erfolgt durch das Traversieren der Listen dieser Klassen,
die Referenzen auf die zugehörigen Elemente der jeweils nächstniedrigeren
Hierarchiestufe enthalten. Zu jeder Instanz der Klassen VideoSequence, GOP und
Picture existieren Instanzen von Extensions-Klassen, die weitere Metadaten
speichern.
58
4.1 B EREITS EXISTIERENDE M ODULE
Abbildung 17: Der Parse Tree
In Abbildung 18 sind weitere wichtige Klassen sowie deren Beziehungen untereinander
dargestellt. Eine einfache Umrandung stellt dabei eine abstrakte Klasse dar.
59
4 R EALISIERUNG
Abbildung 18: Auszug aus dem Klassendiagramm der MPEG-Library
Die
Klasse
UnixFile implementiert die von den abstrakten Klassen
RandomAccessIO sowie BasicIO geerbten Operationen read(), write(),
seek() und tell() und wird von der Klasse BitStream zum Einlesen eines Videos
verwendet. In den Klassen VideoTree und VideoStream finden sich wesentliche
Bestandteile des Parsers. Die Klasse BinaryIOStream wird von VideoStream zum
Schreiben und späteren Einlesen des persistenten Parse Tree benutzt.
Ein Nachteil der MPEG-Library ist das Fehlen von Macroblock und Block Layer; die
MPEG-Hierarchie wird also nicht vollständig abgebildet. Außerdem bietet die Library
nicht alle Informationen der verschiedenen Header in der MPEG-Datenstruktur.
4.1.2 Video Foundation-Datablade
Wie im Kapitel „1.1.3 Informix Dynamic Server“ begründet, wurde als
Datenbankmanagementsystem der objektrelationale Informix Dynamic Server
verwendet. Mit Hilfe des im Kapitel „1.3.2 Das Video Foundation-DataBlade“
beschriebenen DataBlades wurde dieser um Funktionalitäten zur Verwaltung von
Videos sowie zum Zugriff auf einem Videoserver erweitert. Vor allem die generische,
vom verwendeten Speichermedium unabhängige Schnittstelle ist dabei von Nutzen.
4.1.3 Videoserver
Das Videomaterial liegt auf dem kommerziellen Videoserver WebFORCE MediaBase,
der von der Firma Silicon Graphics Inc. angeboten wird.
60
4.2 A RCHITEKTUR
Da der Zugriff auf die Videos über die generische Schnittstelle des Video FoundationDataBlades erfolgt, wäre ebensogut die Verwendung eines anderen Videoservers oder
das Ablegen der Videos im Unix-Dateisystem möglich.
4.2 Architektur
An die Architektur des MPEG-DataBlades gibt es die folgenden Anforderungen:
• Die im Kapitel „3 Entwurf“ beschriebene SQL-Schnittstelle soll realisiert
werden.
• Die MPEG-Library soll Bestandteil des Systems sein.
• Ebenso sind das Video Foundation DataBlade und
• ein Videoserver zu integrieren.
• Natürlich müssen auch alle Vorschriften beim Design eines DataBlades beachtet
werden.
Die in der Abbildung 19 dargestellte Architektur trägt allen diesen Anforderungen
Rechnung.
Abbildung 19: Die Architektur des MPEG-DataBlades
61
4 R EALISIERUNG
Kernstück der Architektur ist der Universal Server. Dieser wird zunächst mit dem Video
Foundation-DataBlade erweitert. Das MPEG-DataBlade baut dann auf dem Video
Foundation-DataBlade auf. Es kommuniziert in drei Richtungen:
• Wie jedes DataBlade mit dem Universal Server.
• Mit dem Video Foundation-DataBlade. Über dessen generische Schnittstelle
wird der Videoserver angesprochen.
• Es liest Dateien im Unix-Dateisystem, die ein MPEG-Video beinhalten.
Im folgenden soll diese Architektur anhand von zwei Beispielen verdeutlicht werden.
Abbildung 20 zeigt den Ablauf bei Einlesen eines neuen Videos durch den Aufruf der
Funktion MPEGcreateVideo.
Abbildung 20: Einfügen und Parsen eines Videos
Der Parser der in das MPEG-DataBlade integrierten MPEG-Library liest über die
generische Schnittstelle des Video Foundation-DataBlade, die Funktionen für den
Zugriff auf den Videoserver bereitstellt, das Video ein. Anschließend erzeugt er den
Parse Tree und speichert ihn persistent.
62
4.3 S PEICHERKONZEPTE
Abbildung 21 stellt den Ablauf beim Aufruf einer Funktion des MPEG-DataBlades dar.
Abbildung 21: Aufruf einer Funktion des MPEG-DataBlades
Über (objektrelationales) SQL wird die DataBlade-Funktion aufgerufen. Handelt es sich
dabei um eine Funktion wie beispielsweise MPEGgetStreamMode, die ihre Daten nicht
aus dem Parse Tree bezieht, kann direkt vom Videoserver gelesen werden. In der Regel
ist es jedoch nötig, vorher den beim Einfügen des Videos geschriebenen Parse Tree
wiederherzustellen.
Danach wird die gewünschte Information aus dem Parse Tree extrahiert und als
Funktionsergebnis zurückgegeben.
4.3 Speicherkonzepte
Ähnlich wie beim Design der Schnittstelle des MPEG-DataBlades (siehe Kapitel „3.2
Spezifikation der SQL-Schnittstelle“) gibt es auch für die Speicherung des anfallenden
Datenmaterials verschiedene Möglichkeiten, die im folgenden betrachtet werden sollen.
63
4 R EALISIERUNG
4.3.1 Generelle Überlegungen
Prinzipiell existieren für die Speicherung von Metadaten über Videos die folgenden
Alternativen:
• Als primitivster Ansatz kann das gesamte Video als ein Large Object gespeichert
werden. Alle gewünschten Metainformationen müssen dann während des
Aufrufs einer DataBlade-Funktion zur Laufzeit aus dem Large Object berechnet
werden. Entsprechend lange würde ein Funktionsaufruf dauern; damit ergibt
sich als Nachteil eine schlechte Performanz. Vorteilhaft ist der geringe
Speicherplatzbedarf, denn außer dem Video selbst fallen keine Daten an.
• Als Weiterentwicklung des vorigen Ansatzes können die Videos nicht als Large
Object in der Datenbank, sondern auf einem Videoserver liegen. Die schlechte
Performanz bleibt jedoch erhalten.
• Eine weiterer Ansatz entspricht den im Kapitel „3.2.1 Erste Alternative:
Abbildung der MPEG-Hierarchie“ angestellten Überlegungen: Die MPEGHierarchie wird durch Tabellen abgebildet. Ein Parser liest die Videos ein und
füllt dabei die Tabellen. Alle Metadaten werden als Tabellenfelder gespeichert.
Diese Alternative hat die im Kapitel „3.2.1 Erste Alternative: Abbildung der
MPEG-Hierarchie“ genannten Nachteile.
• Die beste und deshalb zur Realisierung ausgewählte Alternative bleibt der im
Kapitel „3.2.2 Zweite Alternative: Funktionale Sicht“ dargestellte Ansatz.
4.3.2 Primary Access Method
Eine andere Möglichkeit ist die Implementierung einer Primary Access Method [VTI]
für den Informix Dynamic Server. Dabei handelt es sich um eine Schnittstelle, mit der
auf Daten in einem beliebigen Format, z. B. als Datei im Dateisystem, in einer
Datenbank eines Konkurrenzherstellers oder im Hauptspeicher genauso wie auf eine
Tabelle im IDS zugegriffen werden kann; die Schnittstelle stellt also im Prinzip virtuelle
Tabellen bereit.
Im Gegensatz zur Speicherung einer Referenz auf eine externe Datei durch
beispielsweise den Dateinamen versetzt die Implementierung einer Primary Access
Method den IDS immerhin in die Lage, mit externen Daten umzugehen. Durch diese
Realisierungsvariante bliebe jedoch ein Großteil der Funktionalität, nämlich das gesamte
Storage Management des DBMS (s. Kapitel „1.1.1 Grundlegende Technologien“)
ungenutzt bzw. würde reimplementiert. Weiterhin ähnelt diese Realisierungsvariante bei
unstrukturierter Speicherung einer Datei im Dateisystem der ersten Alternative im
vorigen Kapitel „4.3.1 Generelle Überlegungen“ mit denselben Vor- und Nachteilen
und dem zusätzlichen Aufwand für die Schnittstelle. Auch bei strukturierter
64
4.3 S PEICHERKONZEPTE
Speicherung bietet diese Methode keine Vorteile gegenüber der Definition der
Datenstrukturen im IDS; virtuelle Tabellen lassen sich dann auch durch einen View
realisieren.
Die Implementierung von Primary Access Methods kann auch durchaus vorteilhaft sein.
Wenn beispielsweise ein Hersteller einen Videoserver anbietet, der MPEG-Videos
strukturiert entsprechend dem MPEG-Standard speichert und den Zugriff auf
technische Metadaten des Filmes anbietet, sind Primary Access Methods angebracht.
Dem IDS bleibt dann die Metadatenverwaltung und die Bereitstellung einer
einheitlichen Schnittstelle überlassen; beides wird z. B. vom Video Foundation Blade
(siehe Kapitel „1.3.2 Das Video Foundation-DataBlade“) angeboten.
Generell sind Primary Access Methods gegenüber einer Verwendung von Tabellen
jedoch eher als Extrem zu sehen. Sie könnten allerdings bei schwierigen Anwendungen
die letzte Rettung sein, wenn alle anderen Speicherkonzepte nicht praktikabel sind.
4.3.3 Secondary Access Method
Eine Secondary Access Method bietet die Möglichkeit, eine Indexstruktur für einen
benutzerdefinierten Datentyp eines objektrelationalen Datenbankmanagementsystems
zu definieren. Nötig wird dies bei Datentypen, die sich nicht mit binären Bäumen
indexieren lassen wie beispielsweise mehrdimensionale Daten. Genauere Erläuterungen
dazu finden sich in [VII] sowie in [Stonebraker], Kapitel 10.
Für das MPEG-DataBlade ist die Definition einer Secondary Access Method nicht
erforderlich, da es sich bei den relevanten Datentypen der Metadaten um
alphanumerisches Datenmaterial wie Integers und Strings handelt. Somit sind B-Bäume
und vorhandene Vergleichsoperatoren ausreichend.
4.3.4 Parse Tree
Für die Behandlung des Parse Tree der MPEG-Library sind mehrere Ansätze denkbar:
• Auf Persistenz des Parse Tree wird verzichtet. Das wäre die einfachste Lösung.
Bei jedem Aufruf einer Funktion des MPEG-DataBlades müßte der Parse Tree
dann jedoch neu aufgebaut werden, was bereits bei relativ kurzen Videos einige
Zeit in Anspruch nimmt. Wegen der daraus resultierenden suboptimalen
Performanz ist dieser Ansatz indiskutabel.
• Die MPEG-Library bietet die Möglichkeit, den Parse Tree als Datei im UnixDateisystem zu speichern bzw. wieder einzulesen. Dazu stellt die Klasse
VideoStream die Funktionen write und read zur Verfügung. Dieser Ansatz
wurde realisiert.
65
4 R EALISIERUNG
• Am konsequentesten wäre eine Speicherung des Parse Tree in der Datenbank.
Dafür kann eine neue Klasse PersistParseTree definiert werden, die von
BasicIO erbt. PersistParseTree wird dann von der Klasse
BinaryIOStream zum Lesen und Schreiben des Parse Tree benutzt. Die
Abbildung 22 zeigt diesen Sachverhalt (auch hier steht eine einfache Umrandung
für eine abstrakte Klasse). Dieser Ansatz wäre als zukünftige Erweiterung des
MPEG-DataBlades denkbar (s. a. Kapitel 6 Ausblick).
Abbildung 22: Die Klasse PersistParseTree
4.4 Integration der bereits existierenden Module
4.4.1 MPEG-Library
Der Parser der MPEG-Library liest ein Video aus einer Datei im Unix-Filesystem. Das
MPEG-DataBlade soll seine Daten dagegen über die generische Schnittstelle des Video
Foundation-DataBlades von einem Videoserver beziehen. Die dadurch erforderliche
Anpassung der MPEG-Library wird im folgenden beschrieben.
Durch das VSI (Virtual Storage Interface) stellt das Video Foundation DataBlade
Zugriffsfunktionen auf Videos wie open, close, read, write, seek und
tell zur Verfügung. Mit diesen Funktionen können Anwendungen auf das
66
4.4 I NTEGRATION DER BEREITS EXISTIERENDEN
M ODULE
Datenmaterial zugreifen, das von externen Speichermanagern wie Videoservern
bereitgestellt wird.
In der MPEG-Library werden Videos von der Klasse BitStream eingelesen. Bisher
wurden dazu entsprechende Methoden der Klasse UnixFile aufgerufen, die Zugriff
auf Dateien im Unix-Filesystem bieten. Anstatt UnixFile wird dazu jetzt die neue
Klasse IDSaccess verwendet (siehe Abbildung 23; auch hier steht eine einfache
Umrandung für eine abstrakte Klasse). Sie ist analog zu UnixFile aufgebaut, da sie
ebenfalls von RandomAccessIO erbt, und stellt durch Aufruf von
mi_routine_get() die oben erwähnten Funktionen des Video Foundation
DataBlades zur Verfügung.
Die Header-Datei der Klasse IDSaccess findet sich in Anhang A:
IDSaccess.
Die Klasse
Abbildung 23: Die Klasse IDSaccess
4.4.2 Video Foundation-DataBlade
Zur Konfigurierung des Video Foundation DataBlade muß zunächst das verwendete
Speichermedium angemeldet werden [VFDB]. Dies geschieht durch einen Eintrag in der
Tabelle MedVSIRegister:
insert into Medvsiregister values (MedStorage('VSI_FILE',
67
4 R EALISIERUNG
3,NULL,NULL,NULL,'/var/tmp/ius_mierse/videoserver/',
NULL, NULL));
Um die Beispiele einfach zu halten, wird die Integration des Video FoundationDataBlades anhand von im Unix-Filesystem gespeicherten Dateien vorgeführt. Dazu ist
noch ein Eintrag in der Tabelle MedVSI_File erforderlich:
insert into MedVSI_File
values('/var/tmp/ius_mierse/videoserver/',0);
Nach Erstellen der im Kapitel „3.2.2 Zweite Alternative: Funktionale Sicht“
vorgestellten Tabelle media können mit der Funktion Copy Videos vom Dateisystem
des Datenbankclients auf das angemeldete Speichermedium kopiert werden:
insert into media values ('Random', 'Alan Smith', 'Dices
flying around', Copy('VSI_CLIENT:/home/mierse/mpg/
random.mpg',Storage('VSI_FILE#3:')), NULL);
Um den Benutzer von diesen internen Verwaltungsdetails abzuschirmen und um
sicherzustellen, daß auch ein persistenter Parse Tree geschrieben wird, stellt das MPEGDataBlade die Funktion MPEGcreateVideo zur Verfügung (siehe auch die Kapitel
„3.2.2 Zweite Alternative: Funktionale Sicht“ und „4.5.3 MPEGcreateVideo“).
Ein auf dem Speichermedium liegendes Video kann auch wieder zurück in das
Dateisystem des Clients kopiert werden:
select Copy(value,Storage('VSI_CLIENT:/home/mierse/mpg/
out.mpg')) from media where title='Random';
Mit Hilfe der im vorigen Kapitel vorgestellten Klasse IDSaccess kann die MPEGLibrary ihre Daten jetzt über das Video Foundation-DataBlade beziehen.
Die Verbindung zum Datenbankschema des Video Foundation-DataBlades (siehe
Abbildung 8) wird über die Tabelle media hergestellt: Ihr Datenfeld value entspricht
dem Datenfeld Location der Tabelle VidPVideo.
4.4.3 Videoserver
Da vom Video Foundation-DataBlade eine generische Schnittstelle zu verschiedenen
Speichermedien bereitgestellt wird, sind für die Integration eines Videoservers keine
besonderen Maßnahmen nötig.
68
4.5 I MPLEMENTIERUNG DER D ATA B LADE F UNKTIONEN
4.5 Implementierung der DataBlade-Funktionen
4.5.1 Generelles Schema der DataBlade-Funktionen
Mit Ausnahme der Funktion MPEGcreateVideo, deren Implementierung im Kapitel
„4.5.3 MPEGcreateVideo“ vorgestellt wird, weist der Ablauf aller DataBladeFunktionen eine Reihe von Gemeinsamkeiten für alle Funktionen auf, die im folgenden
aufgezeigt werden.
Zunächst sind einige Initialisierungen nötig:
• Erzeugen einer Instanz der Klasse IUSaccess durch Aufruf ihres Konstruktors
mit einem Parameter vom Typ mi_bitvarying*. Daher haben alle Funktionen
des MPEG-DataBlades ein Argument diesen Typs.
• Erzeugen einer Instanz der Klasse BitStream durch Aufruf ihres Konstruktors
mit der Referenz auf die im vorigen Schritt erzeugte Klasse IUSaccess als
Parameter
• Erzeugen einer Instanz der Klasse VideoStream durch Aufruf ihres Konstruktors
mit der Referenz auf die im vorigen Schritt erzeugte Klasse BitStream als
Parameter
Danach muß die Methode parse() der Klasse VideoStream aufgerufen werden,
damit die MPEG-Library die gewünschten Daten liefern kann. Alternativ kann durch
Aufruf der Methode read() der Klasse VideoStream auch der Parse Tree geladen
werden.
Anschließend kann entweder direkt eine Funktion der MPEG-Library aufgerufen
werden, die die verlangten Daten liefert, oder es ist vorher eine Navigation im Parse
Tree nötig. Ein Beispiel einer solchen Navigation findet sich im Anhang B:
Implementierung der DataBlade-Funktionen.
Falls dies für das aktuelle Video noch nicht geschehen ist, kann noch der Parse Tree
durch Aufruf der Methode write() der Klasse VideoStream geschrieben werden.
Zuletzt müssen noch die erzeugten Instanzen der drei Klassen VideoStream,
BitStream und IUSaccess vernichtet werden. Insgesamt ergibt sich damit der
folgende Code, der sich in allen Funktionen des MPEG-DataBlades wiederfindet (dabei
ist loc ein Argument der Funktion vom Typ mi_bitvarying*):
{
IUSaccess *ius;
BitStream *bits;
69
4 R EALISIERUNG
VideoStream *vs;
int verbose_level=1; //SEQUENCE_LAYER
// open file
ius=new IUSaccess(loc, MED_READ | MED_WRITE | MED_SEEK);
// create BitStream and VideoStream
bits=new BitStream(ius);
vs=new VideoStream(bits, verbose_level);
// build parse-tree
vs->parse();
// get data
// ...
// clean up
delete vs;
delete bits;
delete ius;
}
4.5.2 Deklaration in SQL
Die in C/C++ geschriebenen DataBlade-Funktionen müssen einzeln durch ein SQLStatement deklariert werden. Als Beispiel dient wieder die Funktion
MPEGgetStreamMode:
create function MPEGgetStreamMode(MedLoc)
returning lvarchar
with (class="mpeg")
external name "/home/mierse/MPEGLibSTL/MPEGvideo/lib/
libMPEGvideo.so(MPEGgetStreamMode)"
language C
end function;
Die fertige DataBlade-Funktion kann mit (objektrelationalem) SQL aufgerufen werden:
select MPEGgetStreamMode(value) from media where
title='CTHead';
4.5.3 MPEGcreateVideo
Um ein neues Video für die Bearbeitung mit dem MPEG-DataBlade vorzubereiten, sind
die folgenden Schritte notwendig:
• Kopieren des Videos auf das Speichermedium, das über die Schnittstelle des
Video Foundation-DataBlades zur Verfügung gestellt wird (siehe Kapitel „4.4
Integration der bereits existierenden Module“)
70
4.5 I MPLEMENTIERUNG DER D ATA B LADE F UNKTIONEN
• Erzeugen eines Eintrags in der Tabelle media (siehe Kapitel „4.4 Integration
der bereits existierenden Module“)
• Erzeugen und Schreiben des persistenten Parse Trees (siehe Kapitel „4.5.1
Generelles Schema der DataBlade-Funktionen“). Dabei wird auch das Datenfeld
parsetree_filename der Tabelle media geschrieben.
Die Funktion MPEGcreateVideo, deren Signatur im Kapitel „3.2.2 Zweite
Alternative: Funktionale Sicht“ vorgestellt wird, führt diese Schritte durch.
71
5 Evaluierung
Um einen ersten Eindruck von einer Softwarekomponente wie einer API oder einem
DataBlade zu vermitteln und die Einarbeitung zu erleichtern, sind Beispielanwendungen
äußerst hilfreich. Gleichzeitig können solche Anwendungen der Evaluierung dienen. So
wurde auch für das MPEG-DataBlade eine Demonstrationsanwendung entwickelt.
Um dabei die Plattformunabhängigkeit zu wahren und der immer weiter wachsenden
Bedeutung des Internet Rechnung zu tragen, wurde die Demonstrationsanwendung
Web-basiert entworfen. Dabei war die Verfügbarkeit des Web-DataBlade von
besonderem Vorteil, das deswegen im folgenden kurz vorgestellt werden soll.
5.1 Das Web-DataBlade
Das Web-DataBlade für den Informix Dynamic Server dient der dynamischen
Generierung von HTML-Seite aufbauend aus Datenmaterial aus der Datenbank. Daten,
die von Funktionen eines DataBlades geliefert werden, lassen sich ebenfalls mit dem
Web-DataBlade darstellen. Somit ist es eine ideale Basis für die
Demonstrationsanwendung eines DataBlade.
Für die dynamische Generierung werden spezielle HTML-Tags definiert, die die direkte
Einbettung von SQL-Kommandos in den HTML-Code erlauben. Wie Abbildung 24
verdeutlicht, werden diese SQL-Kommandos durch eine spezielle Komponente, den
WebDriver, behandelt. Das von dem Datenbanksystem gelieferte Ergebnis der SQLAnfrage wird durch die WebExplode-Funktion des Web-DataBlades in den HTMLCode integriert, indem der spezielle Tag textuell ersetzt wird. Die daraus resultierende
dynamisch generierte HTML-Seite wird dann zur Darstellung an den Webserver
weitergereicht.
73
5 E VALUIERUNG
WWW-Server
Web.conf
Anfrage mit
CGI-Umgebung
WebDriver
SQL-Anweisung
(adressiert Dokument)
HTML-Dokument mit
dynamischem Inhalt
Dynamic Server Datenbank
Dokumente mit
eingebetteten
SQL-Anweisungen
Web DataBlade
WebExplode-Funktion
Abbildung 24: Die Architektur des Web-DataBlades
5.2 Die Demonstrationsanwendung
Die Demonstrationsanwendung ist zum Zeitpunkt der Erstellung dieser Arbeit unter
der
URL
http://www.darmstadt.gmd.de/~mierse/mpeg/webdriver?MIval=start
erreichbar. Hinweise zu ihrer Installation finden sich im „Anhang D: Installation“.
74
5.2 D IE D EMONSTRATIONSANWENDUNG
5.2.1 Ablauf der Demonstration
Nach Aufruf der oben genannten URL mit einem Browser Ihrer Wahl erscheint
zunächst der in der Abbildung 25 dargestellte Startbildschirm.
Abbildung 25: Startbildschirm der Demonstrationsanwendung zum MPEGDataBlade
Nach dem Lesen einiger einleitender Bemerkungen kann der Benutzer eines der im
System verfügbaren Videos aus der dargebotenen Liste auswählen. Auf diese Videos
wird vom Dynamic Server aus über das Video Foundation-DataBlade zugegriffen.
Nach einem Mausklick auf den OK-Button erscheint der Bildschirm aus Abbildung 26.
75
5 E VALUIERUNG
Abbildung 26: Der zweite Bildschirm der Demonstrationsanwendung zum
MPEG-DataBlade
Der zweite Bildschirm zeigt nähere Informationen über das zuvor ausgewählte Video
wie den Titel und eine kurze textuelle Beschreibung. Im oberen Bereich beinhaltet der
zweite Bildschirm auch alle Elemente des Startbildschirmes. So kann der Benutzer auch
erneut ein anderes Video auswählen.
Durch Anklicken des Buttons „Display Information“ gelangt der Benutzer zum dritten
Bildschirm, den die Abbildung 27 zeigt.
76
5.2 D IE D EMONSTRATIONSANWENDUNG
Abbildung 27: Der dritte Bildschirm der Demonstrationsanwendung zum
MPEG-DataBlade
Dieser dritte Bildschirm zeigt strukturelle Metadaten wie die Anzahl der Einzelbilder
und die Frameorder des ausgewählten MPEG-Videos, die durch den Aufruf von
Funktionen des MPEG-DataBlades gewonnen wurden.
Mit einem Klick auf den Button „Select video“ gelangt der Benutzer zum
Startbildschirm zurück, wo er ein anderes Video auswählen kann.
77
6 Ausblick
Für die Zukunft sind noch einige Erweiterungen und Ergänzungen des MPEGDataBlades denkbar.
Zur Zeit werden als Komprimierungsstandards nur MPEG 1 und MPEG 2 unterstützt.
Wünschenswert wäre eine Erweiterung der MPEG-Library auf MPEG 4 und 7 sowie
auf weitere Standards.
Wie im Kapitel „3.1 Entwurfsansatz“ erwähnt, ist das MPEG-DataBlade ein low levelDataBlade. Für digitalen Videoschnitt, Adaption, Watermarking usw. können eigene
DataBlades entwickelt werden, die auf dem MPEG-DataBlade aufbauen.
Auch die Fähigkeit der MPEG-Library, Einzelbilder zu dekodieren und zu speichern,
wird bis jetzt nicht ausgenutzt.
Schließlich könnte noch die im Kapitel „4.3.4 Parse Tree“ erwähnte Klasse
PersistParseTree implementiert werden.
79
Anhang A: Die Klasse IDSaccess
/*
IDSaccess.h
Unbuffered IO, needed by BitStream,
derived from RandomAccessIO
Provides the access functions from the storage interface
of the Video Foundation DataBlade
*/
#ifndef IDS_ACCESS
#define IDS_ACCESS
#include <mi.h>
#include <exceptions.h>
#include <RandomAccessIO.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
class IDSaccess : public RandomAccessIO
{
public:
void *operator new(size_t s);
void operator delete(void *p, size_t s);
// constructor
IDSaccess(mi_bitvarying *medloc, mi_integer flags)
throw (IOerror);
// destructor
virtual ~IDSaccess() throw (IOerror);
// implement inherited Interface:
virtual int read(void* buffer, int size)
throw (IOerror);
virtual int write(void* buffer, int size)
throw (IOerror);
virtual int seek(int offset, int whence)
throw (IOerror);
// whence ={ POS_SET, POS_CUR, POS_END }
// returns the new position
virtual int getpos() throw (IOerror);
81
A NHANG A: D IE K LASSE IDS ACCESS
// returns the current position
private:
int filedes;
// our descriptor
MI_CONNECTION* conn;
// function descriptors from the Video Foundation
// DataBlade
MI_FUNC_DESC* f_open;
MI_FUNC_DESC* f_close;
MI_FUNC_DESC* f_read;
MI_FUNC_DESC* f_write;
MI_FUNC_DESC* f_seek;
MI_FUNC_DESC* f_tell;
MI_DATUM medLocFd;
}; // end
#endif
82
Anhang B: Implementierung der
DataBlade-Funktionen
Stellvertretend für alle Funktionen wird hier der Code der Implementierung
ausgewählter Beispielfunktionen vorgestellt. Die Beispiele schließen an die im Kapitel
„3.2.2 Zweite Alternative: Funktionale Sicht“ aufgeführten Funktionen an; die Funktion
MPEGgetStreamMode wurde hier durch MPEGgetNumOfFrames ersetzt. Eine
vollständige Auflistung aller Funktionen findet sich in „Anhang C: “.
Die Funktion MPEGgetNumOfFrames stellt ein einfaches Beispiel dar (vgl. auch das
Codebeispiel im Kapitel „4.5.1 Generelles Schema der DataBlade-Funktionen“):
/**********************
* MPEGgetNumOfFrames *
**********************/
extern "C" mi_integer MPEGgetNumOfFrames(mi_bitvarying*
loc, MI_FPARAM *fp)
{
IDSaccess *ids;
BitStream *bits;
VideoStream *vs;
int verbose_level=1; //SEQUENCE_LAYER
int iresult;
// open file
ids=new IDSaccess(loc, MED_READ | MED_WRITE | MED_SEEK);
// create BitStream and VideoStream
bits=new BitStream(ids);
vs=new VideoStream(bits, verbose_level);
// build parse-tree
vs->parse();
// get data
iresult=vs->getNumOfFrames();
// clean up
delete vs;
delete bits;
delete ids;
return iresult;
} // end MPEGgetNumOfFrames
83
A NHANG B: I MPLEMENTIERUNG DER D ATA B LADE F UNKTIONEN
Die
folgende
Routine MPEGgetPictCodType
unterscheidet sich von
MPEGgetNumOfFrames dadurch, daß sie ein zusätzliches Argument erwartet und
dieses weiterreicht:
/**********************
* MPEGgetPictCodType *
**********************/
extern "C" mi_integer MPEGgetPictCodType(mi_bitvarying*
loc, mi_integer framenumber, MI_FPARAM *fp)
{
/* picture coding types:
#define I_TYPE 1
#define P_TYPE 2
#define B_TYPE 3
#define D_TYPE 4 */
IDSaccess *ids;
BitStream *bits;
VideoStream *vs;
int verbose_level=1; //SEQUENCE_LAYER
int iresult;
// open file
ids=new IDSaccess(loc, MED_READ | MED_WRITE | MED_SEEK);
// create BitStream and VideoStream
bits=new BitStream(ids);
vs=new VideoStream(bits, verbose_level);
// build parse-tree
vs->parse();
// get data
iresult=vs->getPictureCodingType(framenumber);
// clean up
delete vs;
delete bits;
delete ids;
return iresult;
} // end MPEGgetPictCodType
MPEGgetFrameorder steht stellvertretend für diejenigen Funktionen, die ein
Navigieren im Parse Tree erfordern:
/*********************
* MPEGgetFrameorder *
*********************/
extern "C" mi_lvarchar* MPEGgetFrameorder(mi_bitvarying*
loc, MI_FPARAM *fp)
84
A NHANG B: I MPLEMENTIERUNG DER
D ATA B LADE -F UNKTIONEN
{
IDSaccess *ids;
BitStream *bits;
VideoStream *vs;
int verbose_level=1; //SEQUENCE_LAYER
char *result=(char *) mi_alloc(sizeof(char)*50);
mi_lvarchar *miresult;
// open file
ids=new IDSaccess(loc, MED_READ | MED_WRITE | MED_SEEK);
// create BitStream and VideoStream
bits=new BitStream(ids);
vs=new VideoStream(bits, verbose_level);
// build parse-tree
vs->parse();
// get data
strcpy(result, mi_lvarchar_to_string(print_frameorder
(vs)));
// clean up
delete vs;
delete bits;
delete ids;
miresult=mi_string_to_lvarchar(result);
mi_free(result);
return miresult;
} // end MPEGgetFrameorder
Von
MPEGgetFrameorder werden direkt oder
print_frameorder und print_pict aufgerufen:
indirekt
die
Funktionen
/********************
* print_frameorder *
********************/
mi_lvarchar *print_frameorder(VideoStream* vs)
{
PictureNode *pict;
int index;
char *result=(char *) mi_alloc(sizeof(char)*50000);
mi_lvarchar *miresult;
// for all pictures
for(index = 0; index < vs ->frameIndex.size() ; index++ )
{
pict = vs ->frameIndex[index];
if(index==0)
85
A NHANG B: I MPLEMENTIERUNG DER D ATA B LADE F UNKTIONEN
strcpy(result, mi_lvarchar_to_string(
print_pict(index, pict)));
else
strcat(result, mi_lvarchar_to_string(
print_pict(index, pict)));
} // end for
miresult=mi_string_to_lvarchar(result);
mi_free(result);
return miresult;
} // end print_frameorder
/**************
* print_pict *
**************
mi_lvarchar *print_pict(int index, PictureNode *pict)
{
char *result=(char *) mi_alloc(sizeof(char)*50000);
char *resulttemp=(char *) mi_alloc(sizeof(char)*1024);
mi_lvarchar *miresult;
if (pict ==NULL) return(mi_string_to_lvarchar("error"));
switch(pict -> picture_coding_type) {
case I_TYPE:
strcpy(result, "I ");
break;
case P_TYPE:
strcpy(result, "P ");
break;
case B_TYPE:
strcpy(result, "B ");
break;
case D_TYPE:
strcpy(result, "D ");
break;
default:
printf(": ERROR unknown coding type \n" );
return(mi_string_to_lvarchar("error"));
} // end switch type
miresult=mi_string_to_lvarchar(result);
mi_free(result);
mi_free(resulttemp);
return miresult;
}
86
Anhang C: Funktionen des MPEGDataBlades
In diesem Anhang werden alle Funktionen des MPEG-DataBlades aufgeführt. Zur
Erklärung der einzelnen Werte siehe [MPEG1VID] und [MPEG2VID].
MPEGcreateVideo dient zum Einlesen eines neuen Videos:
MPEGcreateVideo(lvarchar, lvarchar, lvarchar, lvarchar)
Die folgenden Funktionen liefern die Daten aus den Stream- und Nodes-Klassen der
MPEG-Library:
MPEGgetStreamMode (MedLoc)
returns lvarchar
MPEGgetNumOfFrames (MedLoc)
returns lvarchar
MPEGgetPictCodType (MedLoc, integer)
returns integer
-- Argument außer MedLoc: framenumber
MPEGgetFrameorder (MedLoc)
returns lvarchar
MPEGextraBitInfo
(MedLoc)
returns integer
MPEGFrameHeight
(MedLoc)
returns integer
MPEGFrameWidth
(MedLoc)
returns integer
MPEGBitRate
(MedLoc)
returns double
MPEGFrameRate
(MedLoc)
returns double
MPEGisMPEG2
(MedLoc)
returns integer
MPEGChromaFormat
(MedLoc)
returns integer
MPEGPictStructure (MedLoc, integer)
returns integer
-- Argument außer MedLoc: framenumber
MPEGMacroblockType (MedLoc, integer, integer, integer)
returns integer
-- Argumente außer MedLoc: picture_coding_type,
-- scalable_mode, pict_scal
MPEGMotionCode
(MedLoc)
returns integer
MPEGDmvector
(MedLoc)
returns integer
MPEGCodedBlockPatt (MedLoc)
returns integer
MPEGMcblockAddrInc (MedLoc)
returns integer
MPEGLumaDCDctDif
(MedLoc)
returns integer
MPEGChromaDCDctDif (MedLoc)
returns integer
MPEGBitsFrameNo
(MedLoc, integer)
returns integer
-- Argument außer MedLoc: framenumber
MPEGSequencFrameNo (MedLoc, integer)
returns integer
-- Argument außer MedLoc: framenumber
Die folgenden Funktionen liefern die Daten aus den Extensions-Klassen der MPEGLibrary:
87
A NHANG C: F UNKTIONEN DES MPEGD ATA B LADES
-- non-normative variables derived from normative elements
MPEGChromaWidth
(MedLoc)
returns integer
MPEGChromaHeight
(MedLoc)
returns integer
MPEGBlockCount
(MedLoc)
returns integer
MPEGSecondField
(MedLoc)
returns integer
MPEGprofile
(MedLoc)
returns integer
MPEGlevel
(MedLoc)
returns integer
-- normative derived variables (as per ISO/IEC 13818-2)
MPEGMBWidth
(MedLoc)
returns integer
MPEGMBHeight
(MedLoc)
returns integer
-- headers
-- ISO/IEC 13818-2 section 6.2.2.1: sequence_header
-- Argument außer MedLoc: sequencenumber
MPEGAspectRatioInf (MedLoc, integer)
returns integer
MPEGFrameRateCode (MedLoc, integer)
returns integer
MPEGBitRateValue
(MedLoc, integer)
returns integer
-- ISO/IEC 13818-2 section 6.2.2.3: sequence_extension
-- Argument außer MedLoc: sequencenumber
MPEGProfLevelIndic (MedLoc, integer)
returns integer
MPEGProgressiveSeq (MedLoc, integer)
returns integer
MPEGLowDelay
(MedLoc, integer)
returns integer
MPEGFrameRateExt
(MedLoc, integer)
returns integer
MPEGFrameRateExtD (MedLoc, integer)
returns integer
-- ISO/IEC 13818-2 section 6.2.2.4: sequence_display
-- _extension
-- Argument außer MedLoc: sequencenumber
MPEGMatrixCoeffics (MedLoc, integer)
returns integer
-- ISO/IEC 13818-2 section 6.2.3: picture_header
-- Argument außer MedLoc: framenumber
MPEGTempReference (MedLoc, integer)
returns integer
MPEGFullPelFwdVec (MedLoc, integer)
returns integer
MPEGForwardFCode
(MedLoc, integer)
returns integer
MPEGFullPelBwdVec (MedLoc, integer)
returns integer
MPEGBackwardFCode (MedLoc, integer)
returns integer
-- ISO/IEC 13818-2 section 6.2.3.1: picture_coding
-- _extension header
-- Argument außer MedLoc: framenumber
MPEGFCode1
(MedLoc, integer)
returns integer
MPEGFCode2
(MedLoc, integer)
returns integer
MPEGIntraDCPrecis (MedLoc, integer)
returns integer
MPEGTopFieldFirst (MedLoc, integer)
returns integer
MPEGFramePredDCT
(MedLoc, integer)
returns integer
MPEGConcMotionVec (MedLoc, integer)
returns integer
MPEGIntraVLCFormat (MedLoc, integer)
returns integer
MPEGProgressFrame (MedLoc, integer)
returns integer
88
A NHANG C: F UNKTIONEN DES MPEGD ATA B LADES
-- ISO/IEC 13818-2 section 6.2.2.5: sequence_scalable
-- _extension header
-- Argument außer MedLoc: sequencenumber
MPEGLayerID
(MedLoc, integer)
returns integer
MPEGLowLayPHorSize (MedLoc, integer)
returns integer
MPEGLowLayPVerSize (MedLoc, integer)
returns integer
MPEGHorSubsFactorM (MedLoc, integer)
returns integer
MPEGHorSubsFactorN (MedLoc, integer)
returns integer
MPEGVerSubsFactorM (MedLoc, integer)
returns integer
MPEGVerSubsFactorN (MedLoc, integer)
returns integer
-- ISO/IEC 13818-2 section 6.2.3.5: picture_spatial
-- _scalable_extension header
-- Argument außer MedLoc: framenumber
MPEGLowLayTempRef (MedLoc, integer)
returns integer
MPEGLowLayHorOffs (MedLoc, integer)
returns integer
MPEGLowLayVerOffs (MedLoc, integer)
returns integer
MPEGSpatTempWCTInd (MedLoc, integer)
returns integer
MPEGLowLayProgFram (MedLoc, integer)
returns integer
MPEGLowLayDFldSel (MedLoc, integer)
returns integer
-- layer specific variables (needed for SNR and
-- scalability)
-- sequence header and quant_matrix_extension
-- Argument außer MedLoc: sequencenumber
MPEGIntQntMatr
(MedLoc, integer)
returns
MPEGNIntQntMatr
(MedLoc, integer)
returns
MPEGCIntQntMatr
(MedLoc, integer)
returns
MPEGCNIntQntMatr
(MedLoc, integer)
returns
integer
integer
integer
integer
MPEGLdIntQntMatr
(MedLoc,
MPEGLdNIntQntMatr (MedLoc,
MPEGLdCIntQntMatr (MedLoc,
MPEGLdCNIntQntMatr (MedLoc,
integer
integer
integer
integer
integer)
integer)
integer)
integer)
returns
returns
returns
returns
DP
-- sequence scalable extension
-- Argument außer MedLoc: sequencenumber
MPEGScalableMode
(MedLoc, integer)
returns integer
-- picture coding
-- Argument außer
MPEGQScaleType
MPEGAlternateScan
extension
MedLoc: framenumber
(MedLoc, integer)
(MedLoc, integer)
returns integer
returns integer
-- picture spatial scalable extension
-- Argument außer MedLoc: framenumber
MPEGPictScal (MedLoc, integer)
returns integer
-- slice/macroblock
-- Argumente außer MedLoc: framenumber, slicenumber
MPEGQuantizerScale (MedLoc, integer, integer)
returns integer
89
A NHANG C: F UNKTIONEN DES MPEGD ATA B LADES
MPEGIntraSlice
(MedLoc, integer, integer)
returns integer
90
Anhang D: Installation
Installation des MPEG-DataBlades
Die Installation des MPEG-DataBlades setzt einen vollständig eingerichteten Informix
Dynamic Server der Version 9.14 unter Unix mit einem virtuellen Prozessor, dessen
Klasse "mpeg" benannt ist, voraus. Anschließend ist das Video Foundation-DataBlade
in einer Datenbank zu registrieren. Die Datei libMPEGvideo.so, das kompilierte
MPEG-DataBlade, wird an eine geeignete Stelle im Unix-Dateisystem kopiert.
Anschließend muß unter Unix mit dem Tool DB-Access, das mit dem Dynamic Server
mitgeliefert wird, das folgende SQL-Skript MPEGDataBlade.sql ausgeführt werden;
die Pfadnamen sind anzupassen:
-- VSI_FILE eintragen
-- Videoserver konfigurieren
insert into Medvsiregister values
(MedStorage('VSI_FILE',3,NULL,NULL,NULL,'/var/tmp /ius
_mierse/videoserver/',NULL,NULL));
insert into medvsi_file values('/var/tmp/ius_mierse
/videoserver/',0);
-- Tabelle für Medien
create table media(title varchar(50), author varchar(50),
description varchar(250), value MedLoc not NULL, parsetree
_filename varchar(250));
-- von Client auf Videoserver kopieren
-- nur mit DBACCESS (wegen Client-Dateisystem)
insert into media values ('Birdwalk', 'nonfamous', 'A
funny bird walking around', Copy('VSI_CLIENT:/home/mierse
/mpg/birdwalk.mpg',Storage('VSI_FILE#3:')));
insert into media values ('CTHead', 'Unk N. Own', 'An
animated view inside a human being´s head', Copy('VSI
_CLIENT:/home/mierse/mpg/CTHead55.mpg',Storage('VSI_FILE#3:
')));
insert into media values ('Random', 'Alan Smith', 'Dices
flying around', Copy('VSI_CLIENT:/home/mierse/mpg/random
.mpg',Storage('VSI_FILE#3:')));
-- Funktionen
create function bladedemoVF(MedLoc) returning lvarchar
91
A NHANG D: I NSTALLATION
with (class="mpeg")
external name
"/home/mierse/MPEGLibSTL/MPEGvideo/lib/libMPEGvideo.so(blad
edemoVF)"
language C
end function;
create function MPEGgetPictCodType(MedLoc, integer)
returning integer
with (class="mpeg")
external name
"/home/mierse/MPEGLibSTL/MPEGvideo/lib/libMPEGvideo.so(MPEG
getPictCodType)"
language C
end function;
create function MPEGgetStreamMode(MedLoc) returning
lvarchar
with (class="mpeg")
external name
"/home/mierse/MPEGLibSTL/MPEGvideo/lib/libMPEGvideo.so(MPEG
getStreamMode)"
language C
end function;
create function MPEGgetNumOfFrames(MedLoc) returning
integer
with (class="mpeg")
external name
"/home/mierse/MPEGLibSTL/MPEGvideo/lib/libMPEGvideo.so(MPEG
getNumOfFrames)"
language C
end function;
create function MPEGgetFrameorder(MedLoc) returning
lvarchar
with (class="mpeg")
external name
"/home/mierse/MPEGLibSTL/MPEGvideo/lib/libMPEGvideo.so(MPEG
getFrameorder)"
language C
end function;
[usw.]
Aus Platzgründen wird das Skript nur bis zu dieser Stelle wiedergegeben; die SQLDeklarationen für alle weiteren Funktionen (siehe „Anhang C: Funktionen des MPEGDataBlades“) sind analog aufgebaut.
92
A NHANG D: I NSTALLATION
Installation der Demonstrationsanwendung
Für die Installation der Demonstrationsanwendung muß das MPEG-DataBlade
installiert sein. Zusätzlich zu den Anforderungen des MPEG-DataBlades muß noch das
Web-DataBlade registriert werden. Es empfiehlt sich, dabei den Application Page
Builder mit zu installieren.
Im Application Page Builder wird dann ein neues Projekt mit Owner default angelegt.
Die beiden Dateien start.html und display_info.html können danach über
einen beliebigen Editor mit Copy and Paste über den Application Page Builder in die
Datenbank geschrieben werden.
Die Demonstrationsanwendung kann anschließend mit einem Browser wie im Kapitel
„5.2 Die Demonstrationsanwendung“ beschrieben aufgerufen werden.
93
Anhang E: Glossar
BLOB
Binary Large Object: Ein Datentyp in der Datenbank, der binäre Daten
mit hohem Speicherbedarf beinhaltet, z. B. Bilder
HTML
Hypertext Markup Language: Eine Seitenbeschreibungssprache für
Hypertext Dokumente. HTML ist die Sprache des World Wide Web.
IDS
Informix Dynamic Server: Ein objektrelationales DBMS
ISO
International Standardization Organisation: Organisation zum Schaffen
von internationalen Standards
MPEG
Motion Picture Expert Group: Eine Reihe von ↑ISO-Standards für
digitales Video
SQL
Structured Query Language: Die Abfragesprache für relationale
Datenbanksysteme
VII
Virtual Index Interface: Sekundärzugriff
VTI
Virtual Table Interface: Primärzugriff
95
Anhang F: Abbildungsverzeichnis
Abbildung 1: Mehrere Anwendungen arbeiten auf dem selben Datenbestand ................13
Abbildung 2: Mehrere Anwendungen greifen auf eine Datenbank zu...............................15
Abbildung 3: Die Klassifizierung von Datenbankanwendungen nach [Stonebraker] .....19
Abbildung 4: Prozeßdiagramm des Dynamic Server............................................................23
Abbildung 5: Die drei Frametypen von MPEG 1-Videos...................................................30
Abbildung 6: Die MPEG 1-Hierarchie...................................................................................31
Abbildung 7: Architektur des Video Foundation-DataBlades ............................................35
Abbildung 8: Entity-Relationship-Diagramm der wichtigsten Tabellen des Video
Foundation-DataBlades ....................................................................................36
Abbildung 9: Stratas...................................................................................................................37
Abbildung 10: Sichtbare Überlagerung mit einem Watermark. Links das Watermark,
rechts die Überlagerung. ...................................................................................41
Abbildung 11: Bild 1 und 150 einer Kamerafahrt.................................................................42
Abbildung 12: Panoramabild....................................................................................................42
Abbildung 13: Einzelbilder aus der Fernsehübertragung eines Fußballspiels...................43
Abbildung 14: Panoramabild....................................................................................................44
Abbildung 15: Panoramabild mit Ball.....................................................................................44
Abbildung 16: Panoramabild mit Ball und Spielern..............................................................45
Abbildung 17: Der Parse Tree .................................................................................................59
Abbildung 18: Auszug aus dem Klassendiagramm der MPEG-Library............................60
Abbildung 19: Die Architektur des MPEG-DataBlades ......................................................61
Abbildung 20: Einfügen und Parsen eines Videos................................................................62
Abbildung 21: Aufruf einer Funktion des MPEG-DataBlades...........................................63
Abbildung 22: Die Klasse PersistParseTree...........................................................................66
Abbildung 23: Die Klasse IDSaccess......................................................................................67
Abbildung 24: Die Architektur des Web-DataBlades...........................................................74
Abbildung 25: Startbildschirm der Demonstrationsanwendung zum MPEG-DataBlade
..............................................................................................................................75
Abbildung 26: Der zweite Bildschirm der Demonstrationsanwendung zum MPEGDataBlade............................................................................................................76
Abbildung 27: Der dritte Bildschirm der Demonstrationsanwendung zum MPEGDataBlade............................................................................................................77
97
Anhang G: Tabellenverzeichnis
Tabelle 1: Volumen und Datenrate verschiedener Medien .................................................27
Tabelle 2: Volumen und Datenrate verschiedener Speicher................................................27
Tabelle 3: Datenrate verschiedener Netzwerke .....................................................................28
99
Anhang H: Literatur
[Adaption]
Silvia Hollfelder, Achim Kraiss, Thomas C. Rakow: A ClientControlled Adaption Framework for Multimedia Database Systems;
1997, European Workshop on Interactive Distributed Multimedia
Systems and Telecommunication Services (IDMS’97), Darmstadt
[CMS]
Silvia Hollfelder, Florian Schmidt, Matthias Hemmje, Karl Aberer,
Arnd Steinmetz: Transparent Integration of Continuous Media Support
into a Multimedia DBMS; 1997, Arbeitspapiere der GMD, Sankt
Augustin
[Codd]
E. F. Codd: A Relational Model for Large Shared Data Banks; 1970,
Communications of the ACM, Vol. 13, No. 6, S. 377-387
[DB1]
Alejandro Buchmann: Datenbanksysteme 1; Skript zur gleichnamigen
Vorlesung an der Technischen Hochschule Darmstadt
[DBDK]
DataBlade Developer's Kit, User’s Guide; 1997, Informix Press, Menlo
Park, Kalifornien
[Färber]
Frank Färber: Digitales Video, Formate und Standards; 1997,
Seminarausarbeitung, http://www.darmstadt.gmd.de/mobile/courses
/digitalvideo/ss97/seminar/reports/frank.färber/index.htm
[IBM]
http://www.research.ibm.com/image_apps/wmsample.html
[ICE]
Matthias Malsy, Andreas Stenger: Konzeption eines MesseInformationssystems für die Messe Frankfurt GmbH; 1996,
Diplomarbeit, Fachhochschule Darmstadt
[IDS]
Getting Started with Informix-Universal Server; 1997, Informix Press,
Menlo Park, Kalifornien
[Lee]
Silvia Hollfelder, Hyo-Jun Lee: Data Abstractions for Multimedia
Database Systems; 1997, Arbeitspapiere der GMD, Sankt Augustin
[Malsy]
Matthias Malsy, Silvia Hollfelder, Arnd Steinmetz, Karl Aberer:
Unterstützung des strukturierten Zugriffs auf MPEG Videos in einem
101
A NHANG H: L ITERATUR
Multimedia-Datenbankmanagementsystem;
1998,
GMD
Forschungszentrum Informationstechnik GmbH, Darmstadt
–
[Manifesto]
Malcolm Atkinson, François Bancilhon, David de Witt, Klaus Dittrich,
Davbid Maier, Stanley Zdonik: The Object-Oriented Database System
Manifesto; 1989, Proc. OOD, Kyoto
[Melton]
Jim Melton: Object Technology and SQL: Adding Objects to a
Relational Language, in: Bulletin of the Technical Committee on Data
Engineering; 1994, Vol. 17 No. 4, IEEE Computer Society
[MMOODB]
K. H. Aberer: Multimediale und objektorientierte Datenbanken; Skript
zur gleichnamigen Vorlesung an der Technischen Universität
Darmstadt
[MPEG1SYS]
Information technology – Coding of moving pictures and associated
audio for digital storage media at up to about 1,5 Mbit/s – Part 1:
Systems; 1993, ISO/IEC 11172-1
[MPEG1VID] Information technology – Coding of moving pictures and associated
audio for digital storage media at up to about 1,5 Mbit/s – Part 2:
Video; 1993, ISO/IEC 11172-2
[MPEG2VID] Generic Coding of Moving Pictures and Associated Audio Information
– Part 2: Video (MPEG-2); 1994, ISO/IEC 13818-2
[Risse]
Thomas Risse: Entwurf und Implementierung einer VRML-Bibliothek
für ein objektrelationales Datenbanksystem auf Basis des VRML-2.0Standards; 1997, Diplomarbeit, Technische Universität Darmstadt
[Schmidt]
Florian Schmidt: Integration kontinuierlicher Daten in ein
objektrelationales Datenbankmanagementsystem; 1997, Diplomarbeit,
Technische Universität Darmstadt
[Stonebraker]
Michael Stonebraker: Object-relational DBMSs: the next great wave;
1996, Morgan Kaufmann Publishers, Inc., San Francisco
[Subrahmanian] V. S. Subrahmanian: Principles of Multimedia Database Systems; 1997,
Morgan Kaufmann Publishers, Inc., San Francisco
[Uli]
Ulrich Müller: Entwurf und Implementierung eines generischen
Mechanismus zur dynamischen Einbettung von multimedialen Daten
in VRML-Szenen auf der Basis eines objektrelationalen DBMS; 1998,
Diplomarbeit, Technische Universität Darmstadt
102
A NHANG H: L ITERATUR
[VFDB]
Video Foundation DataBlade Module, User’s Guide; 1997, Informix
Press, Menlo Park, Kalifornien
[VII]
Informix
Developer
Network
unter
der
URL
http://www.informix.com/idn-secure/DataBlade/WebPages
/dbdevframe.htm: Secondary Access Methods: An overview of
secondary access methods that introduces operator classes and VII.
[VTI]
Informix
Developer
Network
unter
der
URL
http://www.informix.com/idn-secure/DataBlade/WebPages/
dbdevframe.htm: Demystifying VTI: An overview of primary access
methods using the Virtual Table Interface (VTI)
[Yow]
D. Yow, B.L. Yeo, M. M. Yeung, B. Liu: Analysis and Presentation of
Soccer Highlights from Digital Video; 1995, Proceedings of the Second
Asian Conference on Computer Vision (ACCV '95)
103