 |
Webdesignvon Prof. Jürgen Plate |
|
Webdesignvon Prof. Jürgen Plate |
Chunks beginnen mit einem Identifizierer (ID), der im FOURCC (Four Character Code), d. h. in ASCII angegeben wird. Nach dem ID folgt eine Längenangabe, die sich auf die folgenden Daten bezieht.
Der erste Chunk einer AVI-Datei hat den FOURCC 'RIFF', die ersten vier Bytes der Daten des Chunks, der sogenannte Form-Typ, geben die Form der weiteren Daten an, in diesem Fall steht hier 'AVI '. Die restlichen Daten werden in zwei LIST-Chunks gespeichert (ID 'LIST'). Am Ende kann noch ein optionaler Index-Chunk (ID 'idx1') enthalten sein, der die Vorgabe einer bestimmte Abspielreihenfolge erlaubt.
RIFF-Dateien haben immer dieselbe Struktur, damit sie problemlos verarbeitet werden können. Vergleichbar mit globalen und lokalen Prozeduren einer höheren Programmiersprache bestehen RIFF-Dateien wieder aus einem sogenannten Chunk (engl.: Klumpen, Happen, globale Prozedur), der wiederum beliebig viele ineinander verschachtelte Subchunks (lokale Prozeduren) enthalten kann. Der allgemeine Aufbau eines solchen (SUB-)Chunks besteht aus drei Einträgen:
Für den Fall, daß die Länge der Daten in Byte ungerade ist, wird
rechts ein Füllbyte angehängt. Dem ID kann man entnehmen, um welche Art
von Daten es sich handelt. Er ist als FOURCC (Four Character Code)
gespeichert, wobei die vier Byte als ASCII-Zeichen interpretiert
werden. Die einzige ID mit dem ein RIFF-Chunk beginnen kann, ist 'RIFF'.
Unterschiede können dann nur noch in den IDs der Subchunks auftreten.
Hat eine Datenform einen ID mit weniger als vier ASCII-Zeichen Länge,
wird rechts mit Leerzeichen aufgefüllt.
Es ist möglich, sich FOURCC IDs (bestehend aus Großbuchstaben) bei
Microsoft registrieren zu lassen, der Lizenznehmer muß dann zu seinem
ID eine eindeutige Spezifikation des Formates der abgelegten Daten angeben.
Kleinbuchstaben werden bei FOURCC´s verwendet, die zu Subchunks gehören.
Es kann durchaus vorkommen, daß Chunks mit verschiedenen IDs Subchunks
haben, deren IDs identisch sind. Dies ist möglich, da die Interpretation
der Daten innerhalb der Subchunks nur im Zusammenhang mit denen des
übergeordneten Chunks vollzogen wird.
Innerhalb einer RIFF-Datei werden immer mindestens zwei Chunks vorhanden
sein: ein RIFF- und ein LIST-Chunk. Schon in den ersten vier Bytes der Daten
(Offset 8...12 der RIFF-Datei, dem sogenannten Form-Typ), wird die weitere
Form der Daten angegeben. Auch hier verwendet man wieder den FOURCC,
erwartungsgemäß trifft man an dieser Stelle bei einer AVI-Datei
auf die Zeichenfolge 'AVI '. Nach dem Form-Typ kommen die restlichen Chunks
der RIFF-Datei. Wie oben erwähnt ist immer auch noch ein spezieller Chunk,
der LIST-Chunk, enthalten (ID: 'LIST'). Die Daten eines LIST-Chunk
bestehen aus einer Typdefinition der Liste (Byte 0...3 der Daten des LIST
Chunk als FOURCC), den sogenannten List-Typ, gefolgt von aneinandergereihten
Chunks.
Beispiel für eine einfache RIFF-Struktur:
ID:[RIFF] Size:0x0000220 Form-Typ = [DEMO] ID:[LIST] Size:0x0000214 List-Typ = [xyz ] ID:[abcd] Size:0x0000100 ID:[efgh] Size:0x0000100.
Beispiel:
RIFF ('AVI '
LIST ('hdrl'
..
..
)
LIST ('movi'
..
..
)
['idx1'(AVI Index)]
)
Beispiel: Subchunks im &Uunl;berblick
RIFF ('AVI '
LIST ('hdrl'
'avih'([Main AVI Header])
LIST ('strl'
'strh' ([Stream Header])
'strf' ([Stream Format])
'strd' (zusätzliche Header)
)
)
LIST ('movi'
(SubChunk: LIST ('rec '
SubChunk1
SubChunk2
)
)
['idx1' (AVIIndex)]
)
)
Im 'strh'-Chunk sind allgemeine Informationen zum Stream gespeichert, beispielsweise, um welche Art von Daten (Bild oder Ton) es sich handelt, welcher Kompressor benutzt oder mit welcher Rate digitalisiert wurde. Im 'strf'-Chunk ist dann das genaue Format des Streams gespeichert. Die der 'strl'-Liste folgenden Chunks in der 'hdrl'-Liste sind nicht genauer spezifiziert.
Nach den Headern folgen im 'movi'-Chunk die eigentlichen Bild- und Tondaten. Diese können Stream für Stream als Subchunks der 'movi'-Liste oder aber ineinander verschachtelt gespeichert sein. Im ersten Fall existiert pro Stream ein Subchunk, im zweiten Fall pro Schachtelung ein LIST-Chunk mit dem Form Typ 'rec '.
Die 'movi'-Liste speichert dann letztlich die (eventuell komprimierten) Daten für die einzelnen Bilder des Videos, sowie den (ebenfalls möglicherweise komprimierten) Ton. Nach den eigentlichen Daten kann, je nach Bedarf, der 'idx1' Chunk eingesetzt werden.
Das M-JPEG-Verfahren basiert auf der Serialisierung von im JPEG-Format
komprimierten Einzelbildern. Die Qualität der verlustbehafteten
JPEG-Kompression ist dabei in weiten Grenzen konfigurierbar.
Der Kompressionsgrad liegt in der Einstellung für gute
Bildqualität bei einem Faktor von 20 - 25. Die Einbindung von Audiodaten ist
jedoch nicht im M-JPEG definiert. Ein Norm für M-JPEG existiert
nicht. Durch die Fixierung auf Einzelbildkompression erwies sich das Verfahren
als zu ineffizient.
Mit der Recommendation H.261 stand ein audiovisueller
Standard der CCITT zur Verfügung. H.261 besitzt durch seine Ausrichtung auf
Bewegtbildübertragung bereits einen hybriden Kompressionsalgorithmus, der
aus einer Spielart des Deltaverfahrens, einer Restbildkompression sowie einem
optional einbindbaren Verfahren zur Bewegungskompensation besteht. Der
Standard ist u. a. in Auflösung und Bildrate (7,5 - 30 Bilder/s)
konfigurierbar, wobei sich die Bandbreite im Bereich von 40 KBit/s bis zu
2 MBit/s bewegt. Die relativ enge Auslegung der
Recommendation erwies sich jedoch als starkes Handicap.
Eine Lösung für die oben aufgeführten Probleme steht mit MPEG-1 und MPEG-2 zur Verfügung, wobei wesentliche Merkmale von M-JPEG als auch H.261 in die Normung eingingen. MPEG wurde dabei als generische Norm entworfen, wodurch eine Anpassung an verschiedene Anwendungen möglich gemacht werden soll.
Die ältere MPEG-1 Norm findet Anwendung in der PC-Welt und im Unterhaltungsmarkt. Die Übertragungsrate liegt bei den dort üblichen Auflösungen im Bereich bis zirka 1,5 MBit/s (192 KByte/s), wobei aus praktischen Gründen die Grenzen des MPC-1-Standards (für single-speed CD-ROM Laufwerke) eingehalten werden. Neben der CD-ROM eigenen sich auch andere Medien als Basis für MPEG. Hierzu gehört das DAT-System als auch die Verwendung in LANs zur Unterstützung von Video-Mail oder Video-Übertragungen über Telefonleitungen (ISDN).
MPEG 2 wurde im Hinblick auf digitales Fernsehen definiert, es
unterstützt das Zeilensprungverfahren (Interlace). Die der Kompression
zugrundeliegenden Verfahren wie Bewegungskompensation, DCT, Quantisierung und
Huffman-Codierung sind für beide MPEG-Normen im Prinzip identisch.
Verbesserungen erfolgten lediglich auf Detailebene. MPEG 2 stellt also von
den Grundprinzipien her keinen größeren Fortschritt gegenüber
MPEG 1 dar, insbesondere löst MPEG 2 nicht MPEG 1 ab. So erreichen beide
Verfahren in der Regel identische Datenverdichtungen.
Die folgende Funktionen sollten innerhalb der Norm möglich sein
(soweit sie vom jeweiligen Medium unterstützt werden):
Die Funktion der Systemschicht definiert, auf welche Weise Bitströme von Video- und Audio-Daten sowie optional privater Daten zu einem einzigen Bitstrom zusammengefaßt werden. Außerdem werden Zeitmarken (Presentation Time Stamp) bereitgestellt, die der synchronisierten Wiedergabe von Bild und Ton dienen. Der maximale Abstand zwischen zwei Synchronisationspunkten liegt bei 0,7 Sekunden. Die Systemschicht ist unterteilt in den Pack-Layer und den Packet-Layer. Innerhalb eines Packs werden Packets aneinander gereiht. Packets enthalten neben den Headerinformationen nur Daten einer einzigen Art, also entweder Audio-Daten, Video-Daten oder private Daten
Diese Daten werden von den Kompressionsschichten für Video und Audio codiert und zur Übertragung in die Päckchen eingefügt.
Das MPEG-Verfahren nutzt die Tatsache, daß in Folgen bewegter Bilder zwischen aufeinanderfolgenden Bildern große Ähnlichkeit besteht. Mit der Ausnahme krasser Szenenwechsel werden sich Bilddetails kontinuierlich von einem Bild zum nächsten fortsetzen, wie zum Beispiel eine sich von links nach rechts bewegende Person. Ein zentraler Bestandteil von MPEG ist nun die sogenannte Motion Compensation: Die Bewegung der Person wird einfach durch einen Vektor beschrieben, zum Beispiel durch die Angabe, daß sie sich von einem Bild zum nächsten um 12 Pixel nach rechts und 10 Pixel nach oben bewegt hat.
Die Erkennung eines zusammengehörigen Objekts wäre in der Praxis allerdings viel zu aufwendig. Stattdessen werden sogenannte Makroblöcke mit einer Pixelgröße von 16 x 16 untersucht. Diese Makroblöcke entsprechen vier Blöcken, wie sie bei JPEG codiert werden. Im nächsten Schritt wird die Differenz aus dem realen Makroblock in Filmbild 1 und dem verschobenen Makroblock aus Filmbild 2 gebildet, Dieses Fehlerbild muß neben dem Verschiebungsvektor zur Beobachtung der Fehlerfortpflanzung codiert und gespeichert werden. Der geringste Speicheraufwand entsteht natürlich, wenn der Unterschied zwischen den verschobenen Makroblöcken und den tatsächlich dargestellten Blöcken so klein ist, daß auf die Codierung der Differenz ganz verzichtet werden kann.
MPEG steuert die Darstellung von komprimiertem Video durch die Festlegung einer Syntax. Die Regeln zur Erfassung der Bewegungskompensation lassen hingegen viele Freiheiten zu, so daß die Qualität des MPEG-Endprodukts auch maßgeblich von der Güte des verwendeten Codierungs-Algorithmus abhängt.
I-Frames (intracodierte Bilder) verwenden nur Informationen aus einem einzigen digitalisierten Vollbild. Bei I-Frames findet die 'Motion Compensation' somit keine Anwendung. Sie dienen aber als Ausgangspunkt für die Ermittlung von P- und B-Frames. Der Kompressionsfaktor beträgt typisch 7:1.
P-Frames werden durch 'Motion Estimation' aus zeitlich zurückliegenden Bildern vom Typ I oder P abgeleitet. Auch P-Frames dienen demnach als Referenzbilder für die Ermittlung von Verschiebungsvektoren. Der Kompressionsfaktor beträgt typisch 20:1.
B-Frames werden entweder aus früheren oder späteren P- bzw. I-Frames abgeleitet oder auf Basis von Nachbarbildern interpoliert. Sie dienen niemals zur Berechnung von Motion-Vektoren. Daher tragen B-Frames im Gegensatz zu P-Frames nicht zur Fehlerfortpflanzung bei. MPEG-Encoder haben darauf zu achten, daß ein gewisses Datenbudget eingehalten wird, um den Decoder (bzw. das Speichermedium) nicht zu überlasten. Bei B-Frames darf wegen der fehlenden Fehlerfortpflanzung mit weniger Bits codiert werden als bei P-Frames, so daß die Verwendung von B-Frames auch zur Regulierung des Bitstroms dienen kann. Der Kompressionsfaktor beträgt typisch 50:1.
I-Bilder erhalten die Zugriffsfreiheit auf das komprimierte Videomaterial, weil die Bildinformationen nicht über mehrere Bilder verteilt sind. Ein typisches Muster für die Abfolge von I-, P- und B-Frames ist die Abfolge
Zur bildgenauen Positionierung ist somit eine Berechnung über maximal sechs Zwischenbilder erforderlich. Die Kompressionsmethode der Makroblöcke, aus denen I- und P-Frames aufgebaut sind, basiert auf der Huffman-codierten quantisierten DCT auf 8 x 8 Pixelblöcken (4 Blöcke = 1 Makroblock), wie sie bei JPEG Verwendung findet.
Die Berechnung der Bewegungskompensation (Motion Compensation) ist sehr aufwendig. Bei Software-Encoding, auch 'Non Real Time MPEG Encoding' genannt, kann die Codierung auf Standardprozessoren meist nicht in Realzeit erfolgen.
Ein denkbares Entscheidungskriterium ist zum Beispiel der mittlere quadratische Abstand der Werte der beiden 16 x l6-Pixelblöcke. Gemeint ist damit, daß die Quadrate der Differenzen aller Luminanzwerte und Chrominanzwerte des Originalblocks und des Kandidatenblocks innerhalb des Suchbereiches errechnet und aufsummiert werden. Auf diese Art und Weise erhält man ein Maß für die Ähnlichkeit zweier Blöcke. Hat sich ein Block zum nächsten fortgepflanzt ohne sich zu verändern, ist die Differenz gleich Null. Eine sehr rechenaufwendige Methode wäre, für alle denkbaren Verschiebungen innerhalb des Suchbereichs die Summe der quadrierten Differenzen zu bilden. Im Encoder wird dann der Bewegungsvektor des Bildes mit dem kleinsten quadratischen Abstand zum Original als der beste ausgewählt. Die Suche nach dem besten Motion-Vektor kann mit einer Auflösung von 1 oder 1/2 Pixel erfolgen. Die für die Codierung verwendeten Vektoren besitzen dabei eine Auflösung von bis zu einem halben Pixel. Für die Suche nach dem Motion-Vektor kann linear zwischen benachbarten Pixeln interpoliert werden. Da der Rechenaufwand sehr groß ist, werden unterschiedliche Suchstrategien angewandt. So kann beispielsweise zunächst das Gitter der 48 x 48 ganzzahligen Verschiebungen abgesucht werden, um danach die acht benachbarten Positionen zu untersuchen.
Eine andere Methode benutzt für die Suche zunächst ein grobes Raster mit einem Abstand von mehreren Pixeln um es dann um die beste Position nach und nach zu verfeinern. Diese Methode kommt mit noch weniger Schritten aus. Allerdings wird die Wahrscheinlichkeit geringer, den optimalen Motion-Vektor zu finden.
Die Auflösungsreduzierung wird in Dezimierungsfiltern entweder im MPEG-Prozessorbaustein oder in Videodigitalisierung-Bausteinen vorgenommen. Bei der Darstellung komprimierten Videomaterials muß umgekehrt die anfängliche Auflösung wiederhergestellt werden. Dazu werden zwischen den Luminanz- bzw. Chrominanzwerten Nullwerte eingefügt, und anschließend eine gewichtete Mittelung durchgeführt. Die Gewichte sind die Filterkoeffizienten eines Interpolationsfilters. So wird zum Beispiel aus der Folge
10, 11, 12die Folge
10, 10.5, 11, 11.5, 12erzeugt. Einfachere Verfahren zur Interpolation arbeiten mit der Wiederholung von Werten.
| Sequence-Layer | Diese Schicht dient der Zusammenfassung einer oder mehrere Bildgruppen. Im zugehörigen Header werden allgemeine Parameter gespeichert. Konkret sind dies Bild-Breite, Bild-Höhe, Bildformat (z. B. 4:3), Bildwiederholrate (pps), Übertragungsrate und Puffergröße. |
|---|---|
| Group-of-Picture- (GOP-)Layer |
Oberhalb der Picture-Ebene wird in der GOP-Ebene eine beliebige Anzahl von Bildern in natürlicher Abfolge zu Gruppen von Bildern zusammengefaßt. In jeder Gruppe muß mindestens ein I-codierter Frame enthalten sein. Sogenannte geschlossene Gruppen können decodiert werden, ohne daß für die Motion-Compensation auf die vorherige GOP Bezug genommen werden muß; sie ist ohne jeden anderen Bezug für sich decodierbar. Der GOP-Header spezifiziert unter anderem, ob Standard- oder anwenderdefinierte Quantisierungsmatrizen zur Anwendung kommen. Der Encoder darf diese Informationen vor jeder Bildgruppe wiederholen, um einen wahlfreien Zugriff zu erleichtern, die Quantisierungsmatrizen dürfen dabei sogar geändert werden. |
| Picture-Layer |
Diese Schicht enthält alle Informationen, die zum Decodieren eines Bildes
benötigt werden. Der Header enthält die Information, als wievieltes Bild
der entsprechenden 'Group of Pictures' (GOP) das Bild dargestellt werden soll.
Diese Angabe ist notwendig, da wegen der Ruckwärtsbezüge bei B-Frames
der Decoder die Bilder in einer anderen Reihenfolge benötigt als es der
natürlichen Reihenfolge entspricht.
 Außerdem wird beschrieben, um welche Art von Frame (I, B oder P) es sich handelt und ob die Verschiebungsvektoren mit einer Genauigkeit von einem oder einem halben Pixelabstand dargestellt werden. |
| Slice-Layer | Slices sind Streifen von aufeinanderfolgenden Makroblöcken. Ein Decoder kann jedes Slice getrennt decodieren, ohne auf andere Slices zurückgreifen zu müssen. Auf diese Weise wird verhindert, daß sich bei Übertragungsfehlern eine Störung über das ganze Bild fortsetzt. Mit Beginn des nächsten Slices werden wieder korrekte Daten geliefert. Slices müssen nicht an der rechten oder linken Bildkante beginnen, sondern können mit beliebig positionierten Makroblöcken beginnen oder aufhören. |
| Makro-Layer | Hier wird beschrieben, wo der Makroblock im Bild liegt, und um welche Art von Makroblock es sich handelt (I, B oder P). Der Encoder hat bei P- und B-Frames eine Reihe von Entscheidungen auf der Makroblock-Ebene zu treffen, die maßgeblich für den Platzbedarf des codierten Bildes sind. Bei P-Frames ist zunächst festzulegen, ob Motion Compensation angewendet wird. Danach ist zu entscheiden, ob der Makroblock wegen zu großer Fehlerfortpflanzung intracodiert wird. Falls ein Verschiebungsvektor verwendet wird, muß desweiteren geklärt werden, ob das Fehlerbild codiert wird. Bei B-Bildern ergeben sich drei Ableitungsmöglichkeiten für den Makroblock: die Ableitung aus zurückliegenden oder zukünftigen Referenzbildernund schließlich eine Kombination beider Möglichkeiten (Average). Bei letzteren werden die Luminanzwerte im Encoder durch Mittelung errechnet. Der Encoder darf nicht mehr Bits pro Sekunde generieren als der Decoder später verarbeiten kann bzw. als der Kommunikationskanal übertragen kann. |
| Block-Layer | Auf dieser Ebene wird ein Block von 8 x 8 Pixeln mit Original- bzw. Fehlerbildinformation in Form von quantisierten und Huffman-codierten DCT-Koeffizienten dargestellt (siehe auch JPEG). Der in den DCT-Matrizen am unmittelbarsten ins Auge fallende Unterschied zwischen Original- und Fehlerbildern ist das Vorzeichen der Luminanzwerte und der Chrominanzwerte. Während diese Werte im Original stets positiv sind, ergeben sich bei der Differenzbildung positive und negative Werte. Die Differenzwerte werden in einer anderen Art und Weise quantisiert, da die psychovisuellen Gewichtsfunktionen für die Differenzen zweier realer Bilder keine augenfällige Bedeutung haben. Für die Fehlerbilder wird eine Quantisierungskennlinie verwendet, die um den Nullwert herum in einem doppelt so breiten Intervall wie an allen anderen Stellen den Wert Null erzeugt. Das bedeutet in der Praxis, daß der Encoder bei nur geringen Unterschieden von Helligkeit und Farbsättigung keinen Unterschied codiert. |
Um nicht bei Null zu beginnen und statt dessen eine geeignete, bereits vorhandene 3D-Technologie zu nutzen, fiel die Wahl der Entwickler auf 'Open Inventor' von Silicon Graphics (SGI). Open Inventor unterstützt 3D-Szenarien mit Polygonobjekten, verschiedenen Belichtungsmöglichkeiten, Materialien oder Texturen. Zudem stellte SGI noch eine erste VRML-Parser-Library zur Verfügung, die als Grundlage für die Implementierung von 3D-Viewern diente.
Mittlerweile hat die Entwicklung von VRML weitere Fortschritte gemacht. VRML-Szenerien werden in eigenen Dateien abgelegt, auf die - wie bei normalen HTML-Dateien - Verweise mittels URLs (Uniform Resource Locator) zeigen. Klickt der Benutzer in seinem WWW-Browser auf ein solches Link, erkennt die Software die 3D-Datei und startet einen VRML-Viewer, der die weitere Darstellung übernimmt. VRML ersetzt also weder HTML, noch stellt sie eine Erweiterung von HTML dar. Beides sind eigenständige Sprachen, ergänzen sich jedoch insofern, als daß Hypertext-Links von HTML zu 3D-Daten und umgekehrt möglich sind. Die Grundlagen von VRML sind recht einfach. Jede Szenerie setzt sich aus verschiedenen Objekten, den Nodes, zusammen. Ein Node kann ein geometrisches Gebilde, wie eine Kugel oder ein Kegel sein. Darüber hinaus existieren Nodes, die ein bestimmtes Material und seine Eigenschaften (Glanz, Reflexion, Farbe) festlegen, mit dem alle folgenden Nodes dann ausgestattet werden. Einige Nodes bestimmen die Position von anderen Nodes im dreidimensionalen Koordinatensystem von VRML. Spezielle Nodes dienen als Eltern-Objekte für andere Nodes, so daß eine baumartige Strukturierung von Eltern- und Kind-Nodes möglich ist. VRML erlaubt zudem eine Gliederung der Beschreibung mit Blöcken, ähnlich wie die {}-Blöcke in C. Auf diese Weise lassen sich alle Objekte einer Szenerie übersichtlich festlegen.
Wer sich für weitere Informationen zu VRML interessiert, kann sich unter folgenden WWW-Adressen umsehen:
#VRML V1.0 ascii
Separator {
Material { diffuseColor .8 .1 .2 transparency .5 }
Translation { translation 0 -1 0 }
Cube {
width 7
height 1
depth 7
}
Material { diffuseColor .1 .8 .2 }
Translation { translation 1.5 .5 1.5 }
Cube { }
}
Material { diffuseColor .1 .2 .8 }
Translation { translation -1.5 .5 -1.5 }
Sphere { }
Im Bild eines VRML-Browser sieht das dann so aus:
 Zum vorhergehenden Abschnitt |
 Zum Inhaltsverzeichnis |
 Zum nächsten Abschnitt |