Das InfoTip Kompendium

Ein kostenloser Service der InfoTip Service GmbH

Zum Anfang der
Seite scrollen

Codecs und Container

Inhaltsverzeichnis

I.CODECs

1. Allgemeines

Codecs sind Komponenten (Schaltkreise, Module) oder Computerprogramme, die einen digitalen Datenstrom kodieren und/oder dekodieren können. Die Bezeichnung "Codec" ist ein Kunstwort bestehend aus Teilen der englischen Bezeichnungen COder und DECoder. (En)Coder (Kodierer) dienen zum Kodieren von Datenströmen zur Übertragung (z.B. Reed-Solomon zum Fehlerschutz bei DVB),  Verschlüsseln (z.B. AACS als Content Protection für Blu-ray Disc) oder zur Verringerung der Datenmenge (Kompressionsverfahren, z.B. MP3 für Audio). Der Decoder (Dekodierer) gewinnt die ursprüngliche Eingangsinformation des Kodierers aus dem kodierten Datenstrom zurück.

2. Codecs zur Komprimierung von Datenströmen

Kein Speicher- und Übertragungsmedium ist unendlich groß. Daher ist mit den zur Verfügung stehenden Resourcen zu haushalten. Eine Verringerung der Datenmengen, die übertragen, bzw. gespeichert, werden müssen, hat somit einen hohen Stellenwert. Angepasst an die Informationen, die komprimiert werden sollen, gibt es unterschiedliche Kompressionsverfahren.
Jedes Kompressionsverfahren hat seine Vor- und Nachteile. Es gilt einen Kompromiss zwischen dem Kompressionsfaktor (= das Verhältnis von der Größe der Quelldatei zur Größe der Zieldatei), Kompressionsqualität (= verlustfrei/verlustbehaftet -> Art und Menge der entstehenden Artefakte ), Schnelligkeit, Bedienbarkeit, Verbreitung des Decoders und schließlich auch Kosten zu finden. Kompressionsverfahren und deren Durchsetzung im Markt spielen eine äußerst wichtige wirtschaftliche Rolle, da Kompressionsalgorithmen patentiert werden können und die Nutzung über Lizenzzahlungen durch die Hersteller von Geräten oder den Nutzern von Software abgegolten werden muss. Auch lässt sich durch proprietäre und nicht offengelegte Kompressionsalgorithmen eine Art Verschlüsselung des Contents erzielen, was eine Kontrolle über die Verbreitung erlaubt.

Funktionsprinzip

Ein digitales Signal zu komprimieren, bedeutet, dass Teile der Information unterdrückt werden müssen, ohne dass sich der Inhalt der Information selbst verändert. Diese 'überflüssigen' Informationsteile, sogenannte Redundanzen und Irrelevanzen, sind einmal Bestandteile der Information, z.B. eines Bildes, die mehrfach vorhanden sind (redundant) oder vom Menschen nicht wahrgenommen werden können (irrelevant). Zudem können  Redundanzen auch in den den digitalen Daten, die z.B. das Bild beschreiben, auftreten. Alle Kompressionsverfahren beruhen auf dem Prinzip der Eliminierung von redundanten Informationen. In den meisten Kompressionsverfahren werden daher mehrere unterschiedliche Algorithmen nacheinander eingesetzt, um Redundanzen im Inhalt und in den Daten auszumerzen. Algorithmen, die auf rein mathematischer Basis Redundanzen entdecken und vermeiden, arbeiten meist verlustfrei ( lossless), d.h. es gehen keine Informationen verloren. Nach einer Komprimierung und der nachfolgenden Dekomprimierung der Information entspricht dieses dann 1:1 dem Original. Kompressionsalgorithmen, die auf der Basis von physiologischen Modellen (z.B. MP3) Informationsbestandteile auf ihre Wichtigkeit hin bewerten und dann die unwichtigen Informationen verwerfen (Irrelevanzreduktion), arbeiten verlustbehaftet ( lossy), da bei der Komprimierung Informationen verloren gehen.

3. Die wichtigsten Kompressionsverfahren

siehe Videokompressionsverfahren

4. Dateien mit komprimierten Inhalten

Werden Daten mit einem bestimmten Verfahren komprimiert, müssen sie in ein Format gebracht werden, in dem sie verteilt werden können. Dieses können Streams sein, die z.B. als DVB ausgestrahlt werden, oder Dateien, die auf einem Speichermedium abgelegt werden. Um die komprimierten "Rohdaten" muss also eine Struktur geschaffen werden, die es ermöglicht, die Daten wie in einem Behälter (Container) zu transportieren. Wie dieser Container, bzw. das Containerformat, beschaffen ist, ist abhängig vom Übertragungsmedium, dem Betriebssystem und der spezifischen Anwendung.

II. CONTAINERFORMATE

1. Allgemeines

Abb. 1.1: Beispiele für Containerformate (Links: Multimediadatei, Rechts: PDF-Datei)
Abb. 1.1: Beispiele für Containerformate (Links: Multimediadatei, Rechts: PDF-Datei)

Container-Dateien sind Dateistrukturen, die (Multimedia-) Daten nach außen hin vereinfachen und einen Austausch, sogar über Plattform-Grenzen hinweg, ermöglichen. Die Containerformate beschreiben wie diese Nutzdaten gespeichert (nicht wie sie kodiert sind!) sind. Prinzipiell können Container-Dateien alle möglichen Daten aufnehmen, meist sind sie aber auf bestimmte Datentypen spezialisiert. So sind PDF-Dateien vorzugsweise für die originalgetreue Wiedergabe von Dokumenten bestehend aus Schriftinformationen und Raster- oder Vektorgrafiken geeignet, während eine AVI-Datei meist Film- und Toninformationen enthalten.

Containerformate für Multimediaanwendungen verwenden als Eingangsinformation immer bereits kodierte, d.h. komprimierte und bereits meist paketierte Datenströme.

Da es gerade bei Multimediadateien auf eine genaue Synchronisation zwischen Bild- und Toninformation ankommt, müssen die Video-, Audio- und Textstreams quasi parallel in der Containerdatei angelegt werden, was natürlich nicht möglich ist. Daher werden die Streams in Blöcke (Chunks, Packets, Pages, Atoms, ...) vorgegebener oder auch variabler Größe unterteilt und abwechselnd ( interleaved) mit Synchroninformation in der Containerdatei abgelegt. Abhängig vom Containerformat erfolgt dies mittels spezialisierter Algorithmen.

Abb. 1.2: Prinzip des Interleaving (Verschachteln) von Multimedia-Streams
Abb. 1.2: Prinzip des Interleaving (Verschachteln) von Multimedia-Streams

2. AUDIO VIDEO INTERLEAVE (AVI)

AVI steht für "Audio Video Interleave", was "verschachteltes Audio und Video" bedeutet. In der Datei sind Audio- und Videodaten so zusammengefasst, dass sie von Abspielprogrammen wiedergegeben werden können. Die Struktur des AVI-Formats hat ihre Ursprünge im Resource Interchange File Format (RIFF), welche wiederum seine Wurzel in der IFF-Spezifikation von Electronic Arts für den Amiga hat. Microsoft übernahm das Konzept und führte es 1991 modifiziert als Teil der Video for Windows (VfW-) Technik ein. Es gibt drei Typen von AVI-Dateien. AVI 1.0 ist das Ursprungsformat. Da diese Version erheblichen technischen Einschränkungen (kein Streaming, keine Kompressionsverfahren, die einen Bezug zu benachbarten Frames benötigen -> MPEG) unterliegt, ist die AVI-Spezifikation 1996 von einer Gruppe um die Firma Matrox mit Open-DML erheblich erweitert worden. Die AVI-Open-DML-Spezifikationen (oft auch AVI2-Format genannt) konnten zwar nicht alle konzeptbedingte Einschränkungen beseitigen, aber mit zahlreichen nicht-spezifizierten "Hacks" ließ sich das AVI-Format an nahezu alle Anforderungen anpassen.
Der dritte AVI-Typ sind Hybrid-Dateien bestehend aus einer Open-DML-Datei mit einem zusätzlichen Index-Chunk, der eine verbesserte Rückwärtskompatibilität gewährleisten soll.

2.1. Struktur einer AVI-Datei

IFF AVI

Die oberste Instanz, praktisch der äußere Rahmen ("Form"), einer AVI-Datei ist eine LIST, die im Header mit "RIFF" gekennzeichnet ist. und den FourCC-Code "AVI " als ID hat. Die RIFF AVI -Liste enthält zwei weitere LISTs und einen Chunk: Die "LIST hdrl", die "LIST movi "und den Chunk "indx1".

LIST hdrl (Header-List)

Die LIST hdrl definiert das Format der Daten. Der FourCC ist "hdrl". In der Header-List steht als erstes der Main-AVI-Header-CHUNK "avih". Es folgen weitere Listen, die die Stream-Eigenschaften beschreiben (LIST strh) und optional ein Chunk "JUNK", der die LIST hdrl bis an die nächste 2k-Byte Grenze mit Nullen auffüllt.

Main-AVI-Header "avih"

In diesem Datenblock (Chunk) sind allgemeine Daten wie die Anzahl der Streams in der AVI, Bildgröße, Anzeigezeit jedes Frames, Frame-Rate, Anzahl der Frames in der AVI usw. eingetragen.

Abb. 2.2: Struktur einer AVI 1.0-Datei
Abb. 2.2: Struktur einer AVI 1.0-Datei
LIST strl  (Stream Header List)

Für jeden Stream in der AVI wird eine LIST strl angelegt. In dem ersten Chunk "strh" (=Stream-Header) in der LIST strl wird der Stream-Typ mit den FourCC-Codes " vids" für Video, "auds" für Audio oder "txt" für Text definiert. Es folgt ein FourCC, das den im Stream zur Datenkompression verwendeten Codec kennzeichnet. Anhand dieses FourCC erkennt das Betriebssystem welche Treiber (Codecs) zur Dekodierung der Streams zu verwenden sind. Sind passende Codecs nicht installiert, kennt das Betriebssystem die FourCC nicht und zeigt eine Fehlermeldung an. Tabelle 1 zeigt eine Aufstellung der wohl am häufigsten verwendeten FourCCs für Video-Codecs. Eine umfassende Liste mit Beschreibung ist bei www.fourcc.org zu finden.

Tabelle 2.1: Aufstellung der am häufigsten verwendeten FourCCs und Video-Codecs
Tabelle 2.1: Aufstellung der am häufigsten verwendeten FourCCs und Video-Codecs

Im Chunk "strf" (Stream Format) werden für den Video-Stream Bildgröße, Farbtiefe und Farbpaletten definiert. Für Audio-Streams im entsprechenden Chunk werden Stream-Format (z.B. WAVE-PCM), Anzahl der Audiokanäle und Sample-Frequenz usw. beschrieben.

LIST movi (Stream-Daten)

Die LIST movi enthält die Video-, Audio- und Text- (Untertitel-) Daten. Die Daten sind in Audio- und Video-Chunks unterteilt. Jeder Chunk beginnt mit einem vier Buchstaben langen Prefix (FourCC) als Identifizierer (ID) für den Datentyp und einer vier Byte langen Größeninformation. So kennzeichnen die FourCCs: xxdc = Video-Chunk, xxwb = Audio-Chunk, xxtx = text. Der hier vorangestellte xx-Platzhalter weist auf den Stream zu dem der Chunk gehört. So wird jeder Chunk identifizierbar. Der FourCC "01wb" markiert beispielsweise einen Chunk als zum Stream 01 gehörig, welcher ein  Audiostream ist.
Die Größe eines Chunks ist im Wesentlichen von der Bildgröße abhängig. Ein Video-Chunk enthält die Daten für ein einzelnes Vollbild (Frame). Ein Audio-Chunk enthält alle Audiodaten für die Zeit in der das dazugehörige Vollbild angezeigt wird. Bei einer Framerate von 25 Bilder/s enthält ein Audio-Chunk also die Audiodaten für 40 ms Ton.

idx1
Der separate Chunk "idx1" ist ein Index und führt alle Chunks in der "LIST movi "auf, welche wiederum alle Audio- und Video-Frames enthält. Die Verwendung von idx1 macht einen einfachen Suchlauf möglich, da nur an dieser Stelle in der AVI-Datei Verweise auf alle Keyframes aufgeführt sind.

Bedingt durch die Tatsache, dass sich das Hauptindex "idx1" am Ende der Datei befindet, kann ein Streaming-Client nicht im Stream navigieren. Daher können AVI-1-Dateien nicht gestreamt werden.

 

2.2. Die Open-DML-Erweiterungen

Die Open-DML-Erweiterung ("AVI-2") ermöglicht AVI-Dateien größer als 1 GB, eine bessere Indexierung und die Möglichkeit der Einbindung von Video-Kompressionsverfahren, bei denen Einzelbilder Bezüge zu vorhergehenden Keyframes haben (z.B. MPEG). Die Formaterweiterungen sehen Änderungen in der Dateistruktur vor:

  • Es können sich nun beliebig viele RIFF-AVI-Lists in einem Container enthalten sein. Die zusätzlichen Extended RIFF-Lists sind dann mit dem Code "RIFF AVIX" im Header gekennzeichnet. Diese Lists dürfen eine Liste des Typs "LIST movi" enthalten. Jede RIFF AVIX darf maximal 2GB groß sein. Wie groß die gesamte AVI-Datei sein darf, ist nur abhängig vom Betriebssystem des abspielenden Computers.
  • Statt einem Index-Chunk, wie "idx1", am Ende des Files, ist eine neue Index-Struktur vorgesehen. Die Indexierung ist hierarchisch angelegt. Die AVI Super Index Chunks "indx" sind immer in den RIFF AVI-Lists zu finden. Sie sind Indexe von Indexen, die sich in den einzelnen "LIST movi"s befinden. Nur diese ixnn-Index-Chunks enthalten Verweise auf die einzelnen Daten-Chunks, Frames oder weitere untergeordnete Indixe.

AVI-2-Dateien sind streamingtauglich, da das Index der Key-Frames im Dateiheader den eigentlichen Multimediadaten vorangestellt ist und somit der Streaming-Client im Stream navigieren kann.

Abb. 2.3: Struktur einer AVI 2
Abb. 2.3: Struktur einer AVI 2

3. QUICKTIME ( MOV, QT), MP4 (MP4)

Abb. 3.1: Logo Quicktime
Abb. 3.1: Logo Quicktime [1]

QuickTime ist nicht nur ein Containerformat, sondern ein komplettes Multimedia-Framework von Apple. Es ist eine eigenständige, das Betriebssystem erweiternde Architektur zum Erstellen, Editieren und Verteilen von Multimedia-Inhalten.  QuickTime kann mit digitalem Video, 3D-Modellen, Standbildern, Panoramen (VR = Virtual Reality), Ton, Musik und Text umgehen. Interaktivität ist möglich. Ursprünglich für den Apple MacIntosh (1991) unter MAC OS entwickelt, ist es auch für Windows verfügbar. Hier steht es in direkter Konkurrenz zu Windows Media, dem Microsoft Multimedia Framework.

1998 entschied sich die ISO (International Organization for Standardization = Internationale Organisation für Normung) dafür das QuickTime-Format als Container-Format für MPEG-4 zu übernehmen. Das MPEG-4 Containerformat heißt offiziell MP4.

Abb. 3.1: Einbindung von QuickTime
Abb. 3.1: Einbindung von QuickTime

Technisch betrachtet ist QuickTime ein direkter Mittler zwischen der Hardware des Computers und den Programmen. Zur Wiedergabe von Quicktime-Dateien stehen der Quicktime-Player und iTunes zu Verfügung. iTunes verfügt auch (begrenzte) Möglichkeiten zum Encodieren und Transcodieren. Mit einem käuflich zu erwerbenden Lizenzschlüssel oder mit dem Erwerb von bestimmten Programmen werden die im QuickTime-Player bereits vorhandenen, zusätzlichen Funktionen zum "QuickTime Pro" freigeschaltet. Mit QuickTime Pro können digitale Filmclips editiert (Copy/Cut/Paste) werden und in verschiedene Formate exportiert bzw. gespeichert werden.

Die Strukturen im QuickTime Movie-Format

Movie-Dateien
Da QuickTime seine Ursprünge im Apple Betriebssystem MAC OS hat, folgen auch die Daten- und Dateistrukturen dessen Konventionen. Unter MAC OS werden Metadaten (" Resource Fork") und Daten (" Data Fork") grundsätzlich getrennt voneinander in zwei Dateien gespeichert. Diesem Schema folgend werden bei QuickTime Movie-Dateien die Beschreibung von den verwendeten Medien (Movie-Datenstruktur) und eigentlichen Mediendaten (von Apple " Sample-Daten" genannt) getrennt gehandhabt.
Es gibt drei Arten von Movie-Dateien:

Abb 3.3: Typen von QuickTime-Dateien
Abb 3.3: Typen von QuickTime-Dateien

Eine Movie-Datei enthält nur die gespeicherte Kopie der Datenstruktur des Films (Resource Fork), die eigentlichen Sample-Daten befinden sich in einer separaten Datei (Data Fork). Diese typische Aufteilung wurde hauptsächlich von älteren QuickTime-Versionen vorgenommen.

In einer Referenz-Movie-Datei befindet sich nur die Referenz auf eine solche Movie-Datenstruktur, die irgendwo anders gespeichert ist.

In den neueren Versionen von QuickTime werden Strukturdaten und Sample-Daten zwar in einer Geschlossenen (Self Contained) Movie-Datei vereint, sind aber trotzdem streng voneinander getrennt. Dieses Zusammenführen von Resourcen und Daten in eine Datei vereinfacht den Austausch der Quicktime-Movie-Dateien über Plattform-Grenzen hinweg.

Tracks
Ein QuickTime-Movie ist in Tracks organisiert. Ein Movie kann mehrere Tracks enthalten. Es gibt keine vorgegebene Begrenzung der Anzahl der Tracks in einer Datei. Jeder Track wird einem Medientyp wie "Video", "Ton" oder "Text" zugeordnet. Ein Track spezifiziert auch den Codec, der eventuell zur Kompression verwendet wurde. Die zu einem Track gehörenden Daten müssen sich nicht zwangsläufig in der gleichen Datei befinden. Über Referenzen können die zum Track gehörenden Sample-Daten (Einzelbilder, Text, ...) aus lokalen Dateien, aus einem Netzwerk oder aus dem Internet geladen werden.
Die besondere Eigenschaft von QuickTime ist die Möglichkeit auch abstrakte Informationen über Masken, Beschneidungen oder Editierbefehle integrieren zu können, machen das QuickTime-Format besonders geeignet um in Verbindung mit Editier-Anwendungen eingesetzt zu werden.

Atome
Datei, Tracks und Sample-Daten sind in einer hierarchischen Datenstruktur, Atome genannt, gegliedert. Atome sind Datenblocke, die entweder Daten oder andere Atome enthalten kann. Alle Atome haben die gleiche Struktur:

Abb. 3.4: Aufbau eines Atoms
Abb. 3.4: Aufbau eines Atoms
Bytes 0-3    Gesamtgröße des Atoms in Bytes: Mit vier Byte ist die Größe eines Atoms auf 4 GByte begrenzt.
Bytes 4-7     Diese Felder beschreiben den Typ und damit das Format der Daten im Atom. Die Kennzeichnung erfolgt über einen vier Buchstaben langen Code ("moov", "trak", "tkhd", ... )
Bytes 8 ...n   Daten oder weitere Atome. Manche Atome haben hier auch Versions-Kennzeichen oder Flags.

 

Abb. 3.5: Container-Atom
Abb. 3.5: Container-Atom



Ein Atom kann ein oder mehrere andere Atome aufnehmen. Atome, die weitere Atome in sich haben, werden Container-Atome oder Parent-(Eltern-) Atome genannt. Ein Atom, das sich in einem anderen Atom befindet, wird als Child- (Kind-) Atom bezeichnet.
So lassen sich beliebig gestaltete, große hierarchische Strukturen aufbauen. Weil ein Atom immer mit seiner Größenangabe beginnt, können die Strukturen sehr schnell durchsucht werden.

 

Abb. 3.5b: Container-Atom "File Type"
Abb. 3.5b: Container-Atom "File Type"

Der grundsätzliche Aufbau einer QuickTime-Datei verwendet ein Container-Atom "File Type" mit der Kennzeichnung "ftyp". Diese Kennzeichnung unterscheidet eine QuickTime-Datei von ähnlich strukturierten MPEG-4- und JPEG-2000-Dateien.
In diesem Container-Atom befinden sich mindestens zwei weitere Parent-Atome.

  • Im "Movie Atom" befinden sich die  Movie-Resource-Daten. Dieses Atom ist mit dem Code "moov" gekennzeichnet. Im Movie-Atom befinden sich weitere Parent-Atome, die die Sample-Daten im "Movie-Sample-Data-Atom" beschreiben.
  • Im "Movie-Data-Atom" mit dem Kennzeichen "mdat" befinden sich die Sample-Daten, also die eigentlichen Video- und Audio-Daten.
Abb. 3.6: Datenstruktur eines Sample-Atoms
Abb. 3.6: Datenstruktur eines Sample-Atoms

 

 

QuickTime speichert Medien-Daten in Samples. Ein Sample ist ein einzelnes Element in einer Folge von nach der Zeit geordneten Daten. Samples werden durchnummeriert in Datenblöcken ("Chunks") separat in den Sample-Atoms gespeichert. Chunks können unterschiedliche Größen haben.

Abb. 3.6: Struktur eines Movie-Atoms
Abb. 3.6: Struktur eines Movie-Atoms

Das Movie-Atom ("moov") dient als ein Container für Informationen, die die Daten eines Film beschreiben. Diese Informationen (oder Meta-Daten) sind mittels einer Reihe von unterschiedlichen Atomen definiert, die es der Wiedergabe-Applikation ermöglicht die Sample-Daten zu interpretieren. Abbildung 3.6 zeigt den beispielhaften Aufbau eines einfachen QuickTime-Films mit nur einem Track. Die dargestellte Struktur umfasst nur einen kleinen Teil der Möglichkeiten, die QuickTime an Features zu bieten hat.
Das Movie Header Atom spezifiziert die Eigenschaften eines ganzen QuickTime-Films. Im Datenfeld des Atoms werden u.a. definiert: Zeitskala (Anzahl der Zeiteinheiten pro Sekunde; bei einem Zeitsystem mit fünfzigstel Sekunden als Zeiteinheit ist die Zeitskala 50), empfohlene Lautstärke, Zeiger auf die nächste Track-ID.
Das Movie Clipping Atom beschreibt die Beschneidung des Bildes und definiert den das Bild umgebenen Rahmen.
Das User Data Atom enthält Informationen zum Film wie Regisseur, Darsteller, Komponist usw. Weiterhin können Informationen zum Wiedergabeformat (Fullscreen) und zur Endloswiedergabe enthalten sein.
Track Atome definieren einen einzelnen Track in einem Film. In einem Film können sich ein Track oder mehrere Tracks befinden. Das im Track Atom befindliche Track Header Atom beschreibt u.a. die Track-ID, die Länge des Tracks, Erstellungsdatum und die Bildgröße in Pixeln.
Ein optionales Edit Atom enthält eine Art Schnittliste über die die Reihenfolge von Teilen der Medien bei der Wiedergabe gesteuert wird.

Die Atome im Media Atom definierenden Medientyp (Video, Audio, ...), die zu verwendende Komponente des Mediahandlers, die die Daten interpretieren soll und beschreiben die Sample-Daten des Tracks.

Die Video/Sound Media Information Atome enthalten trackspezifische Informationen mit denen die entsprechenden Komponenten des Mediahandlers die Mediendaten mappen und der Zeitskala zuordnen können.

Das Sample Table Atom enthält die Informationen um die Medien-Zeit in die Sample-Nummer umzusetzen damit der Speicherort des Sample gefunden werden kann. Die Informationen zur Indexierung der Medien-Samples sind in Tabellen und Listen in den verschiedenen Atomen abgelegt. Das Child-Atom "Sample Description Atom" enthält Informationen um die Samples zu decodieren. Dies kann beispielsweise der verwendete Codec sein.

4. ADVANCED SYSTEMS FORMAT( ASF, WMA, WMV)

Das Advanced Systems Format-Containerformat wurde von Microsoft als Teil des Windows Media Frameworks, Microsoft's Multimedia-Technologieplattform, entwickelt. ASF ist zwar speziell auf Streaming ausgelegt, die Dateien können aber auch lokal abgespielt werden.  Das ASF-Format speichert folgende Elemente in einer Datei: Audio, Video mit mehreren Bitraten, Metadaten (z. B. Name und Ersteller der Datei) sowie Index- und Skriptbefehle (z. B. URLs und Untertitel). Der Dateicontainer unterstützt Dateien mit einer Größe von bis zu 17 Mio. Terabyte.
Durch Verwendung unterschiedlicher Dateierweiterungen lässt sich sicherstellen, dass die Inhalte den entsprechenden kompatiblen Playern zugeordnet werden. Folgende Dateierweiterungen können verwendet werden:

  • WMA für Dateien mit Audiodaten, die mit dem Windows Media Audio-Codec komprimiert wurden, oder 
  • WMV für Dateien mit Audio- und Videodaten, die mit dem Windows Media Audio- und dem Windows Media Video-Codec komprimiert wurden.
  • Mit anderen Codecs komprimierte Inhalte sollten in einer ASF-Datei gespeichert werden.

Struktur einer ASF-Datei
Eine ASF-Datei ist in so genannten "objects" (Objekte) organisiert. Jedes Objekt ist mit einer 128-Bit GUID (Globally Unique Identifier = Global eindeutige Kennzeichnung) Objekte können neben einem Header entweder andere Objekte oder Daten enthalten. In einer ASF-Datei sind die Objekte hierarchisch angeordnet. In der obersten Ebene können drei Objekttypen unterschieden werden: Das Header Object, das Data Object und das Index Object.

Abb. 4.1: Aufbau einer ASF-Datei (*.wmv, *.wma, *.asf)
Abb. 4.1: Aufbau einer ASF-Datei (*.wmv, *.wma, *.asf)

Das Header Object ist obligatorisch und muss am Dateianfang stehen. Es liefert eine definierte Bytesequenz ("Magic Number": 30 26 b2 75) am Anfang der Datei als Kennung und enthält alle Informationen um den Inhalt des Objektes korrekt interpretieren zu können. Das Header Object ist das einzige der drei Objekte der obersten Ebene, das weitere Objekt aufnehmen kann. Einige Objekte müssen im Header Object vorhanden sein, andere sind optional. Die Reihenfolge der Objekte im Header Object ist nicht festgelegt.

 

File Properties Object   obligatorisch   Enthält allgemeine Dateiattribute
Stream Properties Object   obligatorisch   Definiert die spezifischen Eigenschaften eines digitalen Medien Streams und wie der Stream innerhalb des Data Objects zu interpretieren ist.
Header Extension Object   obligatorisch   Erlaubt zusätzliche Funktionen in eine ASF-Datei einzubringen ohne die Rückwärtskompatibilität aufzugeben
Codec List Object   optional   Enthält Informationen über die in der Datei verwendeten Codecs und Formate
Content Description Obj.   optional   Enthält bibliografische Informationen wie Titel, Autor, Copyright, Freigabe usw.
Script Command Object   optional   Enthält Steuerbefehle, die auf der Wiedergabe-Zeitleiste ausgeführt werden können
Marker Object   optional   Enthält gekennzeichnete Einsprungpunkte innerhalb der Datei
weitere   optional    

Das Data Object ist obligatorisch und muss dem Header Object folgen. Es enthält alle Daten-Pakete der Datei. Die Pakete sind nach ihrem Wiedergabezeitpunkt geordnet. Ein Datenpaket kann verschachtelte (interleaved) Daten von mehreren digitalen Strömen enthalten.

Index Objects sind optional, werden aber für einen wahlfreien Suchlauf in der ASF-Datei unbedingt benötigt. Wenn vorhanden, dann stehen Index Objects immer am Ende der AFS-Datei. Es gibt verschiedene Typen von Index Objects. Es können mehrere Index Objects innerhalb einer Datei existieren.
Der Typ "Simple Index Object" enthält direkte 64 Bit Zeiger auf Datenpakete und darin enthaltene Key-Frames. Werden Simple Index Objects in einer ASF-Datei verwendet, muss jeder Video-Stream eine eigene Index Datei zugeordnet bekommen.
Der Typ "Index Object" wird in komplexeren Multistream-Dateien verwendet. Die Indexdaten sind in Blöcke eingeteilt. Jeder Block enthält 32 Bit Offset-Werte (zu einer 64 Bit Basis), die den Startzeitpunkt der Wiedergabe eines Datenpakets relativ zum ersten Datenpaket der Datei definieren. Durch diese Struktur lässt sich eine variable streamspezifische Indexierung vornehmen.

5. MATROSKA (MKV)

Matroska ist ein plattformübergreifendes Open Source Multimedia-Containerformat, das auf der Auszeichnungssprache EBML (Extensible Binary Meta Language), einer Variante vom binären XML, beruht. (Zur Information: Eine Auszeichnungssprache beschreibt die Daten in einer Datei und die Verfahren, wie die Bearbeitung der Daten vorzunehmen ist.) Besondere Schwerpunkte der Entwicklung dieses Formate sind:

  • schnelle Suchfunktion innerhalb der Datei
  • Strukturierung des Contents in Kapitel, dadurch wird eine DVD-ähnliche Menüsteuerung möglich
  • einfach wählbare Untertitel-Streams
  • einfach wählbare Audio-Streams
  • modularer Aufbau zwecks einfacher Erweiterbarkeit
  • Stream-Fähigkeit über das Internet (HTTP- und RTP-Protokolle)
  • die Möglichkeit fremde Containerformate (AVI, MOV, ...) einzubetten. Diese Eigenschaft gab Matroska auch seinen Namen. Wie die russischen Matrjoschka- Puppen ineinander verschachtelbar sind, kann eine Matroska-Datei mehrere, auch unterschiedliche Formate, in einer Datei aufnehmen.

Weil das Matroska-Containerformat lizenzgebühren- und patentfrei gehalten werden soll, sind für den Einsatz mit Matroska eine ganze Reihe von Open Source-Codecs entwickelt worden. Die Qualität dieser Codecs ist hervorragend und übertrifft sogar manch kommerzielle Codecs. Matroska bietet sich daher mittlerweile als eine echte Alternative zu den proprietären Containerformaten AVI, MOV, RM,  usw. an. Aber auch etliche "klassische" Codecs, wie MPEG-2, RealMedia, WMV, MP3, AAC und DTS sind implementiert worden.
Zur Zeit werden im Matroska-Containerformat drei Dateierweiterungen verwendet. Die Endung ".MKV" wird für Multimediadateien (Video- plus Audio-Stream) und für reine Videodateien verwendet. ".MKA" kennzeichnet reine Audiodateien und ".MKS" einen Untertitel-Elementar-Streams.
Die Software um Matroska-Dateien zu erstellen kann auf der Projekt-Homepage www.matroska.org heruntergeladen werden. Software-Player sind dort ebenfalls zu finden. Auch zahlreiche DVD- und Blu-Ray-Player namhafter Hersteller sind in der Lage Matroska-Deteien von optischen Medien wiederzugeben.

Struktur einer MKV-Datei

Abbildung 5.1 zeigt den vereinfachten Aufbau einer Matroska-Datei. Nähere Informationen stehen auf der Projekt-Homepage www.matroska.org zur Verfügung. Eine Matroska-Datei besteht normalerweise aus zwei Einheiten Jede Einheit ist in mehrere Ebenen (Level) und diese wiederum in Elemente unterteilt.

  • Der EBML-Header beschreibt den Inhalt der Datei.
  • Das Segment enthält die Multimediadaten und alle Header, die für eine Wiedergabe notwendig sind. Eine Matroska-Datei sollte möglichst über nur ein Segment verfügen. Dateien mit mehreren Segmenten sind zwar möglich, ein korrektes Abspielen einer solchen Datei ist aber nicht mit allen Player gewährleistet.
Abb. 5.1: Aufbau einer Matroska-Datei
Abb. 5.1: Aufbau einer Matroska-Datei

Der EBML-Header ist dem Datensegment vorangestellt. In jeder Datei darf es nur einen EBML-Header geben. Der Header enthält die Informationen mit welcher EBML-Version die Datei erstellt wurde und um welchen Typ von EBML-Dateien es sich handelt.
Die Segment Information enthält grundlegende Information über die Datei, z.B. Name der Datei, deren eindeutige Identifizierung (ID) und ggf., wenn die die Datei Teil einer Serie von Dateien ist, die ID der nächsten Datei.

Der Seek-Head ist ein Verzeichnis wo sich alle anderen Gruppen, wie Spur-Information, Kapitel, Tags, Cues usw. in der Datei befinden. 

Die Track-Information enthält grundlegende Informationen zu jeder Spur (Track) in der Datei, z.B. ob es eine Video-, Audio- oder Untertitelspur ist, wie die die Auflösung ist und mit welchem Codecs die Content-Daten komprimiert worden sind.

In der Chapter Section (Kapitel-Bereich) sind alle Kapitel, in die der Content strukturiert ist, aufgelistet. Kapitel sind vordefinierte Einsprungpunkte in ein Video- oder Audiotrack.

Der Cluster-Bereich (Cluster = Gruppe, Haufen, Ansammlung) enthält einen oder mehrere Daten-Cluster. Jedes Cluster besteht aus mehreren  Blockgroups (= Gruppen von Blocken). Die Blockgroups bestehen letztlich aus Blöcken, in denen sich die Video- und Audiodaten eines Tracks befinden. Jeder Block eines Video-Tracks enthält genau ein Bild (Frame). Die Position jedes Frames im Wiedergabe-Stream ist mit einem Time Code gekennzeichnet. Die Clustergröße ist bei der Codierung der Datei einstellbar. Ein Cluster sollte aber nicht mehr als für fünf Sekunden Video- oder Audiodaten enthalten oder größer als 5 MByte sein.
Jedes Cluster beginnt mit einem Time Code. Dieser Time Code ist ist normalerweiser der Time Code des ersten Blocks, der wiedergegeben werden soll.
Diese mehrfache Staffelung der Nutzdaten ermöglicht einen sehr schnellen wahlfreien Zugriff auf die einzelnen Kapitel der Multimediadatei und einen flotten Suchlauf.

Die Cueing Data-Abschnitt enthält alle CuePoints. CuePoints beschleunigen den Suchlauf innerhalb der Datei. Normalerweise wird für jeden Key Frame (z.B. alle I-Frames) ein Cuepoint angelegt. Ein Cuepoint enthält den Time Code und die Positionen des Clusters und des Blocks für den Frame, der vom CuePoint markiert wird.

Im Attachment-Abschnitt können Bezüge ("Anhänge") zu anderen Objekten erzeugt werden. Dies können z.B. Bilder (CD-Cover, Filmplakat), Webpages oder Programme (z.B. ein Codec zum Abspielen des Films) sein.

Im Tagging-Abschnitt können Tags (= Etikett, Kennzeichnung) ähnlich den ID3-Tags von MP3-Dateien erstellt werden. Es können Tags allen Tracks und Kapiteln zugeordnet werden. Die Tags können Zusatzinformationen wie Autor, Interpret, Darsteller, Regisseur usw. enthalten.

6. OGG (OGG, OGA, OGV, OGX)

Ogg ist ein freies Open Standard -Containerformat für Multimediadateien. In einer Ogg-Datei können Video-, Audio- und Text-Streams enthalten sein. Das Ogg-Containerformat ist Teil des Ogg-Multimedia-Rahmenwerks. Hierzu gehören ebenfalls eine Reihe von Codecs: Theora (verlustbehafteter Video-Codec), Vorbis (verlustbehafteter Audio-Codec), Speex (Sprachkompressions-Codec) und FLAC (verlustfreier Audio-Codec).
Das Ogg-Containerformat zeichnet sich hauptsächlich durch seine hohe Effizienz (mit einem Daten-Overhead) von ca. 2% aus. Die Struktur der Daten prädestiniert Ogg geradezu für Streaming-Anwendungen. Die Entwicklung des Programm-Paketes wird von der Xiph.Org Foundation koordiniert. Weitere Informationen, wie Spezifikationen, Dokumentation und zum Download, sind auf der Foundation-Homepage http://www.xiph.org zu finden.

Struktur einer Ogg-Datei

Eine Ogg-Datei verwendet ein Bitstream-Format. Das Besondere bei Bitstream-Formaten ist, dass wenn einmal die Decodierung des Streams unterbrochen wurde, nicht noch einmal die Datei neu geladen werden oder die Übertragung neu begonnen werden muss. Die Decodierung kann Mitten im Stream wieder aufgenommen werden. Eine Ogg-Datei besteht aus Datenblöcken, die als Ogg-Seite (Ogg-Page)  bezeichnet werden.

Ogg-Bitstreams

Abb. 6.1 zeigt den Aufbau eines logischen Ogg-Bitstreams. Ein Encoder, z.B. Vorbis, liefert einen paketierten Daten-Stream. Die einzelnen Pakete (Paket_1, ...) des Streams sind in diesem Beispiel recht groß. So wird Paket_1 in fünf Segmente aufgeteilt. Vier Segmente (Seg_1 bis Seg_4) sind je 255 Byte groß und ein kleineres Segment (S_5) mit weniger als 255 Byte.  Paket_2 wurde in vier Segmente geteilt: drei Segmente mit je 255 Byte und ein kleines mit weniger. Aus Paket_3 wurden zwei Segmente mit 255 Byte und ein kleineres.

Abb. 6.1: Aufbau von Ogg-Bitstreams
Abb. 6.1: Aufbau von Ogg-Bitstreams

Der Einkapselungsprozess erzeugt aus mehreren Segmenten eine Ogg-Seite (Page_1, ...) und stellt den Page-Header voran. In diesem Beispiel besteht die Seite Page_1 aus den ersten drei Segmenten des Paket_1. Page_2 enthält die übrigen. Page_3 enthält die ersten drei Segmente von Paket_2. Page_4 enthält den Rest von Paket_3 und alle Segmente von Paket_4.
In dem angeführten Beispiel sind die Seiten sehr klein. Tatsächlich können in einer Seite bis zu 255 Segmente mit jeweils 255 Byte enthalten sein. In einer Ogg-Seite können also bis zu 65.025 Byte an Nutzdaten enthalten sein.
Der so erzeugte logische Bitstream kann nun mit weiteren logischen Bitstreams (z.B. mit einem Video-Stream) zu einem physischen Ogg-Bitstream gemultiplext werden.
Ein physischer Ogg-Bitstream besteht einer Abfolge von aneinandergereihten Ogg-Seiten. Die Größe der einzelnen Seiten kann variieren. Die maximale Größe einer Seite ist 65.307 Bytes.

Aufbau des Ogg-Page Headers

Der Seiten-Header (Page Header) enthält alle Informationen um die logischen Bitstreams aus dem physischen Bitstream zu demultiplexen können, eine Fehlerkorrektur durchzuführen und um Einsprungmarken für den Suchlauf zu markieren. Jede Ogg-Seite ist eine in sich geschlossene Einheit. Der Seiten-Decodierer im Parser des Players kann jede Seite für sich bearbeiten, ohne dass er den kompletten Bitstream benötigt. Abbildung 6.2 zeigt den Aufbau eines Ogg-Page Headers.

Abb 6.2: Aufbau eines Ogg-Headers
Abb 6.2: Aufbau eines Ogg-Headers
Byte 0-3 Jede Ogg-Seite beginnt mit dem vier Byte langen Magic String "OggS". Dieser String dient als Kennung für einen Ogg-Stream und zur Synchronisation.
Byte 4 Es folgt ein ein Byte langes Versions-Kennzeichen. Dieses ist z.Zt. ein Null-Byte.
Byte 5 Das Header Type-Byte besteht aus 8 Flags. Mit diesen werden drei Seitentypen markiert:
1 = Diese Seite ist die Folgeseite der vorhergehenden Seite in diesem logischen Bitstream.
2 = Anfang eines neuen Streams. Diese Seite ist die erste Seite in einem logischen Bitstream.
3 = Ende des Streams. Diese Seite ist die letzte Seite in diesem logischen Bitstream.
Bytes 6-13 Eine Granule Position ist eine Zeitmarkierung in Ogg-Dateien. Codecs können hier ihre individuellen Time Codes einbetten.
Bytes 14-17 Serien Nummer (Serial Number) zur Identifizierung eines individuellen Streams in der Datei.
Bytes 18-21 Durchlaufende Nummerierung der Seiten. So können ggf. fehlende Daten erkannt werden.
Bytes 22-25 Prüfsumme über die komplette Seite
Byte 26 Anzahl der Segmente in dieser Seite. Es wird damit auch angegeben wieviele Bytes sich in der folgenden Segment-Tabelle befinden.
Bytes 27 ff Die Segment-Tabelle enthält 8-Bit-Werte, die angeben, wie lang ein Segment ist. Die Anzahl der Segmente ist im vorangegangenen Page Segment-Feld angegeben. Ein Segment kann zwischen 0 und 255 Byte lang sein.

7. CONTAINERFORMAT DER DVD ( VOB mit IFO)

Abb. 7.1: Verzeichnisstruktur Video-DVD
Abb. 7.1: Verzeichnisstruktur Video-DVD
Die Verzeichnisstruktur von Video-DVDs

Das auf der DVD verwendete UDF-Bridge Format erlaubt es, auf die auf der DVD befindlichen Dateien sowohl unter UDF als auch unter ISO9660 zuzugreifen. Die Verzeichnisstruktur einer DVD zeigt im Root-Verzeichnis zwei Unterverzeichnisse: AUDIO_TS und VIDEO_TS (Abb. 7.1).
Das AUDIO_TS-Verzeichnis ist bei Video-DVDs immer leer, es wird ausschließlich für Audio DVD benutzt. Alle Daten des Filmes befinden sich folglich im Verzeichnis VIDEO_TS.

Dateitypen

Die im VIDEO_TS-Verzeichnis befindlichen Dateien kann man in drei Typen einteilen:

  • VOB-Dateien enthalten die eigentlichen Präsentationsdaten
  • IFO-Dateien sind die dazu gehörigen Steuerdateien
  • BUP-Dateien sind Duplikate (BackUPs) der IFO-Dateien.

Auf jeder DVD kann man zwei Typen von VOBs feststellen:

  • VIDEO_TS.VOB ist relativ klein, meist nur einige MByte groß
  • VTS_xx_x.VOB ( xx und x sind meist fortlaufende Zahlen) können bis maximal 1 GB groß werden. Diese Größenbeschränkung ist durch das UDF-Bridge Format vorgegeben..

Zu jeder VTS_xx_0.VOB gibt es eine VTS_xx_0.IFO

Abb. 7.2: Auszug aus einer VTS_xx_x.VOB (VOBU)
Abb. 7.2: Auszug aus einer VTS_xx_x.VOB (VOBU)

VOB-Dateien
VOB steht für Video OBject. Die so benannten Dateien enthalten die gemultiplexten Datenströme für Video, Audio und Subpictures (Untertitel). Der Videostrom ist immer im MPEG-2 Verfahren komprimiert, während der oder die Ströme für Audio AC-3, PCM, MPEG-2 Multichannel, MPEG-1 Layer 2 oder DTS sein können.

Die Audioströme der meisten DVDs sind heute AC-3, DTS oder MPG-1 L2. PCM ist unkomprimiertes digitales Audio und wird meist von Consumerlevel DVD-Authoringprogrammen und, bei gepressten DVDs, oft auf Musik DVDs eingesetzt, da es keine Qualitätsverluste durch die Artefakte einer eventuellen Kompression aufweist. Die hohen Datenmengen des unkomprimierten Audiosignales lassen natürlich PCM bei langen Filmen oder bei Filmen mit vielen Extras kaum zu.
Die Datenrate des Audiostromes ist abhängig vom eingesetzten Tonverfahren. AC-3 Ströme können zwischen 192kBit/s (2-Kanal Ton) und 448kBit/s (Dolby 5.1) haben. Ist eine DVD mehrsprachig, addieren sich natürlich die Datenraten des Datenstroms jeder Sprache zueinander. Es können sich bis zu 8 verschiedene Audiostreams auf einer DVD befinden. VOBs enthalten meist einen Hauptvideostrom und oftmals mehrere Multiangle (Kamerawinkel-) Nebenvideoströme. Zwischen den Nebenströmen kann man, wenn vorhanden, hin- und herschalten um z.B. den Blickwinkel auf eine Szene zu verändern. Die Datenströme vom Hauptstrom und Nebenströme sind ineinander verschachtelt und werden wie ein einzelner Datenstrom behandelt. Die maximale Datenrate für den Videostream ist 9,8MBit/s.
Subpictures (Untertitel oder kleine Grafiken) sind meist vierfarbige Bitmaps, die in den Videostrom eingeblendet werden. Subpictures sind meistens als eigener Strom codiert. Bis zu 32 Einzelströme sind zulässig.
Die Gesamtdatenrate aus allen Teilströmen (Video, Audio und Subpictures) muss zu jedem Zeitpunkt unter 10,08MBit/s bleiben.

IFO-Dateien

Die IFO-Dateien enthalten NavigationsInFOrmationen. Der Inhalt einer DVD ist unterteilt in Titel und diese jeweils in mehrere Zellen ( Cells). Diese Zellen sind über eine
oder mehrere Programmketten ( PGC = Program Group Chains) miteinander verknüpft. Um ein flüssiges Abspielen der Filmdateien zu gewährleisten, sind Navigationsinformationen in Form von Tabellen oder Listen notwendig. Zu jeder VOB_xx_0-Datei gibt es auf der DVD eine gleichnamige IFO-Datei. In der jeweiligen IFO-Datei sind die exakten Adressen angegeben, wo auf der DVD ein bestimmter Stream (Video, Audio, Untertitel) anfängt, welche Zellen in welcher Reihenfolge zu einer Programmkette gehören und wo z.B. die Einsprungstellen für die Skip-Funktion und den schnellen Suchlauf sind. Ferner sind Informationen zu Steuerfunktionen wie Regionsschutz, Altersfreigabe, Bildformat, Bildauflösung, Kamera/Film-Mode usw. abgespeichert.

Abb. 7.3: Auszug aus einer VIDEO_TS.IFO (VMG Information Management Table und Cell Address Table)
Abb. 7.3: Auszug aus einer VIDEO_TS.IFO (VMG Information Management Table und Cell Address Table)

Videomanager VMG

VIDEO_TS.VOB bildet zusammen mit ihrer Steuerdatei VIDEO_TS.IFO den Videomanager (VMG) und ist die erste Datei, die abgespielt wird. Sie enthält meist den Copyright-Hinweis (der oft nicht übersprungen werden kann) und das (erste) Auswahlmenü (Sprachauswahl, Bildformatwahl …). VIDEO_TS.VOB enthält die eigentlichen Videoobjekte wie die Standbilder der Menüs, Buttons usw. und wird als VMGM_VOBS (Video Objects for VMG Menu) bezeichnet. Die entsprechende Steuerdatei VIDEO_TS.IFO ist die Video Manager Information (VMGI)
Prinzipiell befindet sich im VMG die Kontrollstruktur für die komplette DVD. Weitere Auswahlmenüs können sich jedoch auch in den VTS_xx_0.VOB der Video Titel Sets
(VTS) befinden.

Abb. 7.4: Dateitypen auf einer Video-DVD
Abb. 7.4: Dateitypen auf einer Video-DVD

Video Titel Set VTS

Video Titel Sets (VTS) bestehen aus einer oder mehreren VOB- und einer IFO-Dateien. Auf einer DVD befinden sich, abhängig vom Umfang des Filmes, mehrere VTS. Die Dateinamen der einzelnen VTS sind nach dem Schema VTS_xx_x.VOB und VTS_xx_0.IFO durchnummeriert. ’xx’ kann 01 bis 99 annehmen und ’x’ von 0 bis 9. Es können sich auf einer DVD also maximal 99 Video Titel Sets mit jeweils 10 Unterdateien befinden.
Die VTS_xx_0.VOB-Dateien (VTSM_VOBS) enthalten eventuell weitere Menüs (oft animiert und mit Musik hinterlegt), Trailer o.ä.. Über VTS_xx_0.IFO wird das komplette VTS verwaltet.
VTS_xx_1.VOB, VTS_xx_2.VOB, usw. enthalten den Hauptfilm und das Bonusmaterial. Verschiedene Varianten des Hauptfilms (z.B. Multiangle, Altersfreigabe, ..) sind in einer VOB gespeichert. Über Programmketten (Program Chains = PGC) gesteuert wird aus mehreren einzelnen, unterschiedlichen Filmteilen nacheinander die gewünschte Variante unterbrechungsfrei abgespielt (Seamless Branching).

Zellen und Programmketten

Die kleinste Einheit, bestehend aus Video- ,Audio-, Untertitel- und Navigationsinformation, ist eine VOBU (Video Object Unit). Jede VOBU enthält Daten für ca. 0,4 bis 1 Sekunde Wiedergabezeit. Eine einzelne (Standbild) oder viele (Film) VOBUs bilden eine Zelle. Jede Zelle hat eine eigene Kennziffer (ID). Wie bereits oben beschrieben, sind bei Filmen mit Multiangle-Features oder Altersbegrenzungen verschiedene Varianten des gleichen Filmes in einem Datenstrom (Realtime Data) verschachtelt untergebracht. Welche Variante wiedergegeben werden soll, kann über ein Menü gewählt werden oder ist durch die Konfiguration des Abspielgerätes vorgegeben. Die möglichen Varianten sind in den IFO-Dateien ineiner Tabelle als eine entsprechende Programmkette (PGC = Program Chain) gespeichert.
Die PGC bestimmt über die Reihenfolge der wiederzugebenden Zellen. Über die Tabelle der jeweiligen PGC gesteuert, werden aus dem Datenstrom nur die Daten derjenigen Zellen ausgewertet, die auch zur PGC gehören. So genannte Precommands und Postcommands ermöglichen das Ausführen von Steuerbefehlen vor, bzw. nach dem Abspielen der Zellen. So kann eine Programmkette in mehrere weitere verzweigen oder mehrere PGCs in einer einzigen münden. Durch die Verschachtelung der Zellen der verschiedenen Varianten erreicht man nahtlose, unsichtbare Übergänge ( Seamless Branching ), da die Lasereinheit nicht neu positioniert werden muss.

Abb. 7.5: Struktur des DVD-Datenstromes
Abb. 7.5: Struktur des DVD-Datenstromes

Navigation

Die Navigation auf der DVD wird auf mehreren Datenebenen durchgeführt. Abhängig vom Inhalt und Aufbau der DVD muss schon beim Authoring der DVD festgelegt werden, welche Inhalte wie wiedergegeben werden. In Tabellen werden die Einsprung und Endadressen von Kapiteln, Zellen und VOBUs festgelegt. Manche Kapitel unterliegen Einschränkungen in der Navigation, wie z.B. der Vorspann mit dem Copyright. Um die Navigation für den Benutzer so einfach und übersichtlich wie möglich zu machen, können Zellen gruppenweise zusammengefasst werden. Für eine DVD mit z.B. Musik-Clips lassen sich eine oder mehrere Zellen zu Programmen ( PG = Program) definieren. Programme lassen sich per Zufallsfolge (Random) oder Auswahl (Shuffle) nacheinander abspielen. Sequenzen aus einem oder mehreren Programmen lassen sich zu Kapiteln ( PTT = ParT of Titel) zusammenfassen, die über ein Menü oder Tastendruck (meist über die ’Skip’-Taste) angesprungen werden können.
Für eine Navigation innerhalb einer Zelle dienen die im Datenstrom der VOBUs enthaltenen Navigation Packs (NV_PCK). Jeder Pack besteht aus zwei Päckchen (Packets): der Presentation Control Information (PCI) und der Data Search Information (DSI). Diese Information helfen zu einem nahezu verzögerungsfreien Navigieren, z.B. beim Suchlauf. Durch den großen Pufferspeicher zwischen dem Pickup und dem Decoder gibt es eine starke zeitliche Verzögerung zwischen dem gerade gelesenen und dem angezeigten Signal. In der PCI und DSI sind Echtzeitinformationen enthalten, die der Controller im DVD-Player vor und nach dem Durchlaufen der Zelle durch den Puffer auswertet.

Abb. 7.6:Program Chains (PGS) bei Multiangle und Seamless Branching
Abb. 7.6:Program Chains (PGS) bei Multiangle und Seamless Branching

  

REFERENZEN

Abbildungen

[1] Das Quicktime-Logo ist ein Warenzeichen der Apple Computer Inc.

Rechtshinweis

Sofern auf dieser Seite markenrechtlich geschützte Begriffe, geschützte (Wort- und/oder Bild-) Marken oder geschützte Produktnamen genannt werden, weisen wir ausdrücklich darauf hin, dass die Nennung dieser Marken, Namen und Begriffe hier ausschließlich der redaktionellen Beschreibung bzw. der Identifikation der genannten Produkte und/oder Hersteller bzw. der beschriebenen Technologien dienen.

Alle Rechte an den in diesem Kompendium erwähnten geschützten Marken- und/oder Produktnamen sind Eigentum der jeweiligen Rechteinhaber und werden hiermit ausdrücklich anerkannt. Alle in unseren Artikeln genannten und ggfs. durch Dritte geschützte Marken- und Warenzeichen unterliegen uneingeschränkt den Bestimmungen des jeweils gültigen Kennzeichenrechts sowie den Besitzrechten der jeweiligen eingetragenen Eigentümer.

Die Nennung von Produktnamen, Produkten und/oder der jeweiligen Produkthersteller dient ausschließlich Informationszwecken und stellt keine Werbung dar. InfoTip übernimmt hinsichtlich der Auswahl, Leistung oder Verwendbarkeit dieser Produkte keine Gewähr.

Sollten dennoch wider unserer Absicht Rechte Dritter verletzt werden, so bitten wir um eine Benachrichtigung ohne Kostennote.