Seminar Multimediadatenformate WS02/03 Daniel M

1
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Ogg Vorbis audio codec
• by Xiph.org

2
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• General purpose audio codec
• Komplett patent- und abgabenfrei
• Offener Standard
• Hoch flexibel
• kodiert von 8kHZ Telefonie bis 192kHz digitalen
  Master
• Unterstützt bis zu 255 diskrete Kanäle

3
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Geschichte und Motivation
• Mp3 beruht auf statischen psychoakustischen
  Modell
• Modell entwickelt vom Frauenhofer-Institut mit
  langwierigen Tests
• September 1998 Frauenhoffer erhebt nun Gebühren
  für die Benutzung des Modells, nachdem sich
  mp3 als Standard etabliert hat
• Unzufrieden mit dieser Situation und angetrieben
  von dem Gedanken, daß alle
  Internetstandards offen sein sollten, bildet
  sich xiph.org
• Xiph.org beschließt einen komplett offenen und
  abgabenfreien audio codec zu entwickeln,
  der so gut ist, daß er sich als Standard
  etablieren kann und in der Lage ist, mit
  jedem anderen audio codec, egal ob offen oder
  kommerziell, zu konkurrieren

4
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Technische Details und Designziele
• Standardmäßig variable Bitrate
• Komplexer perzeptueller, Psychoakustik
  ausnutzender encoder
• Rechnerisch einfacher decoder
• Braucht wenig Rechenleistung, dafür etwas mehr
  Speicher
• Basiert auf einer Modifizierten Diskreten
  Kosinustransformation
• Kein statisches Wahrscheinlichkeitsmodell (wie
  z.B. mp3)
• Modell, auch sämtliche Codetabellen, werden im
  stream header mit übertragen
• Packets können beliebige Größe haben

5
Seminar Multimediadatenformate WS02/03 Daniel
Müller
Grundlegender Aufbau des Audio-Bitstreams
Identification Header
Setup Header
Comment Header
Audio Packet
Audio Packet
Wichtig Packets haben keine vorgeschriebenen
Größen. Lediglich ihre Reihenfolge ist
vorgeschrieben. Nach den drei Headern in
angegebener Reihenfolge, können in einem Ogg
Vorbis I stream nur noch Audio Packets folgen.
6
Seminar Multimediadatenformate WS02/03 Daniel
Müller
Identification Header Enthält allgemeine
Informationen zum Bitstream, wie Version und
einfachste Audio-Charakteristika (Anzahl der
Kanäle, Samplingrate, etc.). Comment
Header Enthält User-Kommentare (tags) und
einen Bereich für einen vendor string, wo der
encoder die Möglichkeit erhält, sich
einzutragen. Setup Header Enthält extensive
Information zum decoder setup. Unter anderem sind
hier das akustische Modell, Huffman- und
Vektorquantisierungstabellen gespeichert. Hinzu
kommen noch über 100 Einträge zum fine-tuning
des decoders.
7
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Decoder-Aufbau
• Decoder ist essentiell eine Aneinanderreihung
  von Instanzen von Components
• Jede Instanz hat eine spezifische Aufgabe in der
  decode pipeline
• Eine vollständige decoder Konfiguration
  beschreibt sowohl die Zusammensetzung der
  Components zu einer pipeline als auch alle
  Component spezifischen Konfigurationen

8
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Components im Überblick I
• Modes geben an, in welchem Modus kodiert
  wurde, dienen als top-level
  Konfigurationen für alle weiteren spezifischen
  Konfigurationen der components, die am
  aktuellen Frame arbeiten.
• Mappings geben Gruppierungen von Vektoren zum
  gemeinsamen Dekodieren an. Sie definieren
  auch, welche Vektoren mit welchen Floor- und
  Residue-Instanzen dekodiert
  werden sollen.

9
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Components im Überblick II
• Floors sind Instanzen, die in der Lage sind, die
  niedrig aufgelösten floor Vektoren zu
  dekodieren. Greift auf eines oder mehrere
  codebooks zu.
• Residues sind Instanzen, die in der Lage sind,
  die hoch aufgelösten residue Vektoren
  (Rest-Vektoren) zu dekodieren. Greift auf eines
  oder mehrere codebooks zu.
• Codebooks sind Instanzen, die Entropie- und
  Vektorquantisierungskodierung für die
  floors und residues bereitstellen. Sie enthalten
  unter anderem auch die Huffman- Tabellen.

10
(No Transcript)
11
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Mode-Instanz
• Definiert einen generellen top-level Modus mit
  dem der aktuelle Frame kodiert wurde
• Dieser Modus hat Einfluß auf die gesamte
  Component spezifische Konfiguration für
  diesen Frame
• Enthält eine Größeneinstellung für den Frame,
  den window Typ, den
  Transformationstyp (bei Vorbis I immer 0, MDCT)
  und einen Index, der angibt, welche
  mapping Instanz benutzt werden soll.

12
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Mapping-Instanz
• Gruppiert einzelne Vektoren zu submaps
• Für jede dieser submaps wird angegeben, mit
  welchen floors und residue Instanzen sie
  zu dekodieren sind
• Ein Beispiel
• Ein modernes 5.1 Sound-System benutzt die
  ersten 5 Kanäle für normales Audio
  (wofür das volle Spektrum von floor und residues
  benutzt wird), der 6. Kanal ist aber ein
  nur-Bass Kanal. Er wird durch die submaps
  aufgezeigt und mit den
  entsprechenden, passenden floors und residues
  kodiert und dekodiert. Diese speziellen floors
  und residues verbessern die Qualität und
  Verringern den Speicherbedarf

13
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Floor-Instanz
• Kodiert/dekodiert eine grob aufgelöste
  Repräsentation eines PCM Vektors
• Wird im allgemeinen benutzt als Weißungsfilter
• Eine Kodierung kann in 2 Arten vorhanden sein
• Art 0 ist so gut wie veraltet
• Art 1 ist eine punktweise Definition der
  Wellenkurve auf einer dB Skala zu einer
  lineraren Frequenz Skala
• Die Werte, die ein floor dekodiert sind
  entropiekodiert, es werden also mehrere
  Referenzen in die codebooks benötigt

14
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Residue-Instanz
• Kodiert/dekodiert die feinen Strukturen einer
  Audio-Kurve
• Dies geschieht nachdem die floor-Werte abgezogen
  wurden
• Es wird zwischen 3 spezifischen Packalgorithmen
  ausgewählt
• Die Details zur Konfiguration des jew.
  Algorithmus werden gegeben
• Die residue Informationen sind entropie- und
  vq-kodiert, es werden also auch
  Referenzen auf mehrere codebooks benötigt

15
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Codebook-Instanz
• Konfiguriert die Entropie- und VQ-Algorithmen
• Bietet einen abstrahierten Zugriff auf Entropie-
  und VQ-Algorithmen
• Konfiguriert die Huffman-Codes
• Bietet abstrahierten Zugriff auf die
  Huffman-Tabelle

16
Seminar Multimediadatenformate WS02/03 Daniel
Müller
Der Dekodierungs-Prozeß im Überblick Für jedes
Packet wird folgender Prozeß ausgeführt 1.
Packet Typ dekodieren 2. Packet Modus
dekodieren 3. window Form dekodieren 4. floor
dekodieren 5. residue in residue Vektoren
dekodieren 6. inverse Kopplung der residue
Vektoren (stereo) 7. Erstellen der floor Kurve
aus den floor Daten 8. Berechnen des Produktes
aus floor und residue, Ergebnis ist ein audio
Spektrum Vektor 9. Anwenden der iMDCT, Ergebnis
sind PCM Daten (aber noch nicht ganz fertig) 10.
Überlappen der PCM Daten aus dem vorherigen
window mit den Daten aus dem
aktuellen window 11. Zwischenspeichern der
rechten Hälfte des frames, für die nächste
Überlappung 12. Rückgabe der fertigen PCM Daten
an das Ausgabeberät
17
Seminar Multimediadatenformate WS02/03 Daniel
Müller
Der Dekodierungs-Prozeß im Detail 3. window
Form dekodieren Hier wird die genaue Form des
window bestimmt, mit dem in Schritt 10 die
Überlappung der PCM Daten durchgeführt wird
Bei gleich großen windows gibt es keinen weiteren
Aufwand
Bei verschieden großen windows muß das vorherige
window schneller abfallen. Realisiert wird dies
durch Anwenden einer Hang-Funktion mit
18
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Der Dekodierungs-Prozeß im Detail
• 4. und 5. floor und residue dekodieren
• Für jeden Kanal gilt es einen floor Vektor zu
  dekodieren.
• Nachdem alle floors dekodiert wurden (in diesem
  Frame), beginnt der Dekoder mit der
  Dekodierung der residues.
• Da die residues im Anschluß gekoppelt werden
  (Schritt 6) gilt hier nicht, daß es für
  jeden Kanal auch einen residue Vektor geben wird.

19
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Der Dekodierungs-Prozeß im Detail
• 6. und 7. residue Kopplung und Berechnug der
  floor Kurve
• Zur Kopplung der residue Vektoren Vektoren gibt
  es zwei Verfahren
• channel interleaving und square polar mapping
• Mit einer Kombination aus beidem läßt sich ein
  echtes lossless stereo generieren
  (Standard stereo mode in Vorbis I)
• Durch Anwenden der beiden Verfahren beim encode
  läßt sich Bitrate sparen
• Nach der Kopplung wird die floor Kurve aus den
  floor Werten berechnet

20
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Der Dekodierungs-Prozeß im Detail
• 8. und 9. floor/residue Multiplikation und iMDCT
• Die floor/residue Multiplikation ist rechnerisch
  einfach und wird für jeden Kanal
  Element für Element durchgeführt
• Anmerkung 32bit Integer sind hier zu wenig
  (wählt man eine Nur-Integer
  Implementierung, was möglich ist), will man die
  volle Auflösung behalten.
• Auf das Ergebnis der Multiplikation wird die
  iMDCT angewendet, das Resultat sind bekannte
  PCM Daten, die aber noch überlappt werden müssen
  (Eigenschaft der MDCT)

21
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Der Dekodierungs-Prozeß im Detail
• 10., 11. und 12. Überlappen, Zwischenspeichern
  und Rückgabe
• Die Daten aus der iMDCT werden jetzt wie in
  Schritt 3 beschrieben überlappt
• Der ¼ Punkt des aktuellen windows wird an den ¾
  Punkt des vorherigen windows angelegt
• Die Daten zwischen der Mitte der vorherigen und
  des aktuellen Frames sind jetzt bereit
  zur Rückgabe
• Der rechte Teil wird zwischengespeichert für den
  nächsten Frame
• Anmerkung Die Daten des ersten Frames werden
  nicht zurückgegeben, sie dienen dazu, den
  decoder vorzubereiten

22
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Transport eines vorbis Bitstreams
• Die Spezifikation des vorbis Bitstreams sieht
  keinerlei Transport oder Fehlerkorrektur vor
• Im Netzwerk ist es möglich, Protokolle zu
  verwenden die an sich schon framing und
  packet sync anbieten (wie UDP, streaming)
• Will man einen vorbis stream aber transportieren
  (sei es als Datei oder über TCP), wird
  der vorbis stream im allgemeinen in einen Ogg
  transport stream verpackt (daher der Name Ogg
  Vorbis)

23
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Designziele für Ogg transport stream
• Echtes streaming, kein seeking benutzen, um den
  verpacketen bitstream zu generieren
• Nicht mehr als 1-2 der bitstream Bandbreite als
  overhead
• Es soll jederzeit möglich sein, die absolute
  Position im bitstream zu bestimmen
• Limitiertes Editieren soll durch Mechanismen zum
  einfachen Konkatenieren
  erleichtert werden
• Fehlererkennung, recapture after error,
  direkter random access auf die verpackten
  Daten soll möglich sein

24
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Aufbau eines Ogg streams
• Sämtliche Ogg codecs benutzen rohe, gepackte
  Daten (packets), Bits gepackt in
  Bytes.
• Diese gepackten packets haben keine ordnende
  Struktur, sie erscheinen wie ein Strom aus
  zufälligen Bits
• Das Ogg stream Format bietet framing/sync,
  Recover after error, landmarks beim
  Suchen und genug Information, die packets wieder
  zu extrahieren (ohne decode)
• Ein Ogg stream besteht aus mehreren logischen
  streams, die zu einem physikalischen stream
  zusammengesetzt werden
• Wird ein vorbis stream in einen Ogg stream
  verpackt, wird nur ein logischer stream
  erzeugt, der nicht nicht multiplexed ist
  (degenerate stream)

25
(No Transcript)
26
(No Transcript)
27
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Die Felder eines Ogg Headers
• capture pattern Dies markiert den Beginn einer
  jeden Page, dient auch zum Synchronisieren
  und zum Erholen von Fehlern im stream
• stream_structure_version Versionsnummer der
  Streamstruktur, immer 0
• header_type_flag 0x01 gesetzt neues Packet
  nicht gesetzt fortgesetztes Packet
• 0x02 gesetzt nicht erste Page nicht
  gesetzt erste Page im stream
• 0x04 gesetzt nicht letzte Page nicht
  gesetzt letzte Page im stream
• absolute granule position In unserem Fall gibt
  dieses Feld die Position in PCM samples an, die
  mit dem letzten vollständigen Packet in dieser
  Page errreicht wird
• stream serial number Die Seriennummer des
  logischen streams, wichtig in einem Ogg stream
  in dem mehrere logische streams zu einem
  physikalischen stream zusammengefaßt wurden
• page count Nummer der Page, wird benutzt zum
  Überprüfen, ob eine Page verloren wurde
• page checksum CRC Prüfsumme über die Page
• page_segments Anzahl der Einträge in der
  segment_table
• segment_table lacing values der einzelnen
  Segmente (deren Länge, geht von 0 bis 255)

28
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Einbettung der vorbis Daten in den Ogg stream
• Das erste vorbis Packet (ID) wird direkt in die
  erste Page gepackt (immer 58 Bytes)
• Die erste Page wird mit den header_type_flags
  auf beginning of stream gesetzt
• Die nächsten zwei Packets (Comment, Setup)
  werden auf die nächsten Pages verteilt, die
  letzte dieser Pages endet aber mit dem
  Setup-Packet, die folgenden audio Packets
  beginnen in einer neuen Page
• Die folgenden audio Packets werden in ihrer
  Reiehnfolge in den Ogg stream gepackt, die
  letzte Page mit end of stream markiert
• Die absolute granual position ist in den ersten
  Pages 0, in audio Pages ist es das PCM Offset
  des letzten kompletten Packets

29
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Beispiele
• Mp3 erstellt mit Cdex v1.50 beta 7 (LAME 1.30,
  engine 3.92)
• Ogg erstellt mit Cdex v1.50 beta 7 (libVorbis
  20020717)
• Low 96 kbit bei mp3, quality 2 bei ogg
• Medium128 kbit bei mp3, quality 5 bei ogg
• High 256 kbit bei mp3, quality 8 bei ogg

30
Seminar Multimediadatenformate WS02/03 Daniel
Müller

• Quellen
• www.xiph.org
• c't 23/2000
• c't 01/2001