Der "VBV" (Video Buffering Verifier)
	(Overflow- / Underflow - Probleme)

 
Im Rahmen des EDV-TIPP schauen wir uns heute einmal den VBV Buffer an. Vielen Dank in diesem Zusammenhang an Andreas Riel, der mit leicht verständlichen Erklärungen die Grundlage für diesen Tipp geliefert hat.

Der Weg vom Encoder über den eigentlichen Übertragungsweg (DVD/CD oder Funk bzw. Kabel) bis hin zum Decoder geht immer über irgendwelche Puffer (Buffer).

Abb 1: Übertragungsweg

 
Bei der klassischen DVD haben wir da z.B.

• Track Buffer

• Compressed Data Buffer

• Audio Buffer

• VBV Buffer

• Subpicture Buffer

• VBI Buffer

• PSI Buffer

• Host-Access Buffer

• Frame Buffer

• etc. etc.

Wir wollen hier nicht die Normvorschrift wiedergeben und uns auch nicht mit den ganzen Buffern im Detail beschäftigen, wir möchten jedoch versuchen, den unserer Meinung nach wichtigen VBV mit einfachen Worten so zu erklären, dass möglichst viele User verstehen, was sie dort eigentlich einstellen und was sie ggf. zur Verbesserung ihres Bildes oder Tones tun können.

Das Füllen des VBV kann man sich am Beispiel einer Talsperre ganz gut vorstellen. 

Die benötigt erst einmal eine Zeit, bis sie gefüllt ist. Dann aber kann man mit ihr die Menge des abfließenden Wassers regulieren. Im Sommer läuft weniger hinein, aber gleich viel ab und der Wasserstand sinkt. Im Winter läuft mehr hinein und der Wasserpegel steigt bei gleicher Entnahmemenge. 

Nun haben wir bei der DVD oder der SVCD einen MPEG-Stream, der meist mit einer variablen Bitrate arbeitet. Und diese variable Bitrate muss an den konstanten Datenstrom der Übertragung angepasst werden. In umgekehrter Richtung, also von der CD zum Bild, muss der konstante Datenstrom der Übertragung  an die variable Bitrate der Bildausgabe angepasst werden.

In diversen Foren wird immer wieder über den VBV-Buffer diskutiert und doch wird er leider oft nicht wirklich verstanden, falsch interpretiert oder eben gar nicht beachtet. 

VBV steht für "Video Buffering Verifier", also ein Puffer für den Videodatenstrom. Die Daten werden also nicht nur "gepuffert", sondern auch verifiziert. Der VBV übernimmt für den folgenden Decoder also eine nicht zu verachtende organisatorische Vorarbeit.

Dem VBV-Buffer (Video Buffering Verifier) wird leider unserer Meinung zu wenig Bedeutung beigemessen, obwohl er für viele Schwierigkeiten und Probleme verantwortlich ist. Bei vielen Forenfragen ist z.B. von einem Einfrieren des Bildes, von Bild und Ton und ähnlichen Erscheinungen die Rede. Bei genauer Betrachtung sind solche Erscheinungen oft von einem falsch eingestellten VBV-Buffer abhängig.

Um den Buffer in seiner Funktion zu verstehen, muss man sich das gesamte Konzept der Bildausgabe vor Augen führen. 

Abb 2: Bildausgabe

 
Vereinfacht dargestellt werden Daten, in diesem Fall Bilddaten, von der CD gelesen, dann logisch verarbeitet und zum Schluss über eine Ausgabeschnittstelle, zum Beispiel die Grafikkarte oder den Scartanschluss, an einen Bildschirm oder Fernseher ausgegeben. Dies alles geschieht mit einer durch Vorschriften und Standards geregelten Geschwindigkeit. 

Nun wissen wir aus den Kapiteln zuvor, dass Ihr DVD-Standalone-Player, sofern er SVCD-fähig ist, z.B. eine SVCD mit 2-facher Geschwindigkeit abspielen und dabei den Datenstrom mit einer Geschwindigkeit von 2.788,8 kBit pro Sekunde lesen kann.

Wir wissen aber auch, dass ein MPEG-Datenstrom nicht immer ein kontinuierlicher Strom ist. So kann es z.B. sein, dass bei sehr schnellen Bewegungen mehr Daten anfallen als bei langsamen Bewegungen.

Und um diesen Ausgleich - wenn Sie so wollen - um das Ausnivellieren des Datenstroms - geht es bei dem VBV. Ziel ist es also, eine möglichst gute Bildqualität zu erzeugen.

Prinzipiell kann man sich das so vorstellen, dass der Datenstrom von der CD oder DVD mit einer bestimmten Geschwindigkeit (sagen wir mal X1) ausgelesen wird. Hierbei steht die X1 für die Datenrate, die genau in diesem Moment für die Szene und für dieses Bild von der CD kommt. 

Da eine Sequenz von Bildern aus I-, P- und B-Frames zusammengesetzt ist, diese jedoch je nach Bildtyp (I, P oder B) unterschiedlich groß sind, müssen diese Bilder in einen harmonischen, gleichmäßigen Datenstrom umgewandelt werden. 

Wichtig ist in diesem Zusammenhang noch zu wissen, dass ein I-Frame nur sich selber benötigt, um dargestellt zu werden. Ein P-Frame jedoch vorwärts referenziert wird und ein B-Frame vor- und rückwärtige Bildinformationen braucht. 

Somit kann ein B-Frame erst dann angezeigt werden, wenn der Decoder die Information des nachfolgenden I- oder P-Frames besitzt. 

Dies setzt voraus, dass die einzelnen Frames umorganisiert werden müssen.

Erinnern Sie sich noch an eine klassische GOP-Struktur? Z.B.: IBBPBBPBBPBBP (vergl Dateiformate)

Der Decoder müsste beispielsweise mit der Bildberechnung eines B-Frames bis zum Eintreffen des P-Frames warten und wäre dann erst in der Lage, die Bildsequenz "BBP" auszugeben. 

Durch ein umorganisieren der Frames B B P ergibt sich die Reihenfolge P B B, die dann über den Buffer zwischengespeichert und an den Decoder ausgegeben wird. Somit ist der Decoder in der Lage, die eintreffenden B-Frames zu berechnen und am Schluss den P-Frames für die neuen B-Frames zu behalten. 

Durch diese Pufferfunktion ist es möglich, dem Decoder die jeweilige Bildinformation "schlagartig" zu geben.
 

Abb 3: Bufferausgabe

Wenn das Bild dann im Decoder umgerechnet wird (so werden aus den Fragmenten der P- und B-Frames ja wieder kpl. Bilder), werden diese dann auf dem Fernseher ausgegeben.

Schauen wir uns im nächsten Schritt einmal die Größe eines solchen Buffers an:

Die Größe des Video stream VBV buffers ist z.B. für die SVCD in der IEC 62107 mit 1.835.008 (Bits) / 8 (Bits/Byte) / 1024 (Bits/KBit) = 224 KByte definiert.

Nach der ISO/IEC 13818-2; Annex C berechnet sich der VBV nach folgender Formel:

B = 16 * 1024 * vbv_buffer_size

"B" ist dabei in Bit angegeben und wie in der Norm definiert 1.835.008 Bit groß. (Die IEC 13818-2 schreibt dazu "were B is the minimum VBV buffer size in bits required to decode the sequence.")

Nun wissen wir, 1 Kbit sind 1024 bit. Also sind 16 Kbit = 16 * 1024 bit = 16.384 bit

Damit wissen wir auch, wie groß ein Speichersegment des VBV buffers ist, nämlich 16 Kb. Und nicht  - wie es durch viele Newsgroups immer wieder fälschlich geistert - 16 KB (also KByte). Nein, es sind nur 16 Kbit!

Teilt man nun die Größe des VBV von 1.835.008 Bit (= 224 KByte) durch 16.384 bit, so kommt man auf die korrespondierende Anzahl von Speicher-Segmenten. Also 112 in unserem Beispiel.

Daraus ergibt sich somit für eine SVCD folgende Formel:

Lassen Sie uns nach so viel Theorie einmal die Praxis ansehen.

Ein Blick auf die Einstellparameter von AVI2MPG2 zeigt uns, dass dort die Größe Kb angeben ist. Was ist das aber nun? "B" als Ergebnis der obigen Formel oder die Variable "vbv_buffer_size" als Teil der Formel?

112 Kb (wie oben angegeben) sind erst einmal 112 bit * 1024 bit/Kbit = 114.688 bit = 14 KByte. Doch da scheint etwas nicht zu stimmen, wie jeder selbst nachprüfen kann.

Nun steht die Information über die Groesse des VBV-Buffers im "sequenz header" eines Streams. Schaut man sich einen beliebigen Stream, der mit der o.a. Einstellung erzeugt wurde, mit geeigneten Werkzeugen (vergl. Offeryn.de) an, so sehen wir folgendes Bild:

Die 112 meinen also die 112 bit in der Variablen vbv_buffer_size. Die Bezeichnung 112 Kb in AVI2MPG2 ist schlicht falsch!

TMPGEnc (z.B. die Version Beta 12j) hingegen definiert den VBV als "VBV buffer size" in KByte

und meint damit nicht die Variable vbv_buffer_size der o.a. Formel, sondern vielmehr direkt "B".

Kontrollieren können wir das wieder mit den bereits bekannten Werkzeugen.

224 bei TMPGEnc einzustellen ist also etwas anderes, als 224 bei AVI2MPG2 einzustellen! 

224 KByte bei TMPGEnc sind also 112 bit bei AVI2MPG2.

Bei einer Veränderung der Größe des Buffers sollte aber eine Zahl eingehalten werden, die durch 16 zu teilen ist - siehe oben.

Bei dieser Gelegenheit noch den Hinweis auf andere VBV buffer - Größen:

Es gibt ja nun nicht nur bei einer SVCD einen VBV. Auch die DVD oder die VCD kennt den VBV buffer. Lassen Sie es uns also etwas globaler betrachten.

Wir nehmen dazu die ITU-T H.262 bzw. die ISO/IEC 13818-2 zu Hilfe. In Tabelle E-22 bis E-25 finden wir die verschiedenen "MPEG-Main profile", auf die wir uns hier einmal beschränken wollen (vergl: Dateiformate / Komprimierung).

Die Profil- und die Levelbezeichnungen finden Sie übrigens auch in unserem bereits bekannten TMPGEnc wieder:

Was sagen uns denn nun solche Zahlen? Was passiert da überhaupt?

In den Picture-Headern gibt es ein Feld vbv_delay. Das regelt die Zeitverzögerung zwischen Bereitstellung der Daten im VBV und dem Start der Dekodierung. Ist dieses Feld auf 0xFFFF, so werden Daten in den Buffer geschoben und zwar, sobald Pufferplatz frei ist. Dabei wird die maximale Bitrate, wie sie im sequence header steht zugrundgelegt. Sobald der Puffer das erste Mal voll ist, beginnt die Dekodierung.

Wir wollen uns hier nicht mit den einzelnen Delay-Schritten, wie z.B. startup_delay oder end_to_end_delay beschäftigen - das wird dann doch etwas komplex.

Hier sehen Sie aber einmal das typische Auf und Ab in einem solchen Buffer:

Abb 4: VBV-Verlauf

Erst wenn der gesamte Buffer gefüllt ist, wird das erste Bild vom Buffer freigegeben und der Decoder und damit der Film läuft los. 

Es dauert um so länger, je größer der VBV ist und je langsamer dieser gefüllt wird. 

Wenn vom Decoder auf Dauer ein größerer Datenstrom verlangt wird als über die CD nachgelesen werden kann (vbv_delay falsch oder zu niedrige Muxrate), so leert sich der Buffer soweit, bis er schlussendlich leer ist. Damit hört der Datenstrom zum Ausgabegerät auf und das Bild friert ein. Erst wenn nun der Buffer wieder gefüllt ist, wird das Bild ausgegeben. Dieser Zustand wird auch als buffer underflow bezeichnet. 

Umgekehrt ist es möglich, dass in einer Filmsequenz die Daten schneller von der CD geliefert werden, als sie dekodiert werden können (vbv_delay falsch oder zu hohe Muxrate). Oder aber, wenn ein kpl. Bild nicht in den Puffer passt (Encoder hat VBV_size z.B. falsch errechnet). Hier kann es dann zu einem Datenverlust kommen, der sich in springenden Bildern (einzelne Bilder werden einfach herausgelassen) bemerkbar macht. Dies führt dann zum sog. buffer overflow.

Auf einigen Playern kann es dadurch zu einem asynchronen Ablauf von Bild und Ton kommen. Hier ist dann die Firmware des jeweiliger Herstellers gefragt. Normalerweise ist dies aber heute kein Problem mehr bei den neueren Playern.

Betrachten wir im nächsten Schritt einmal das reibungslose Funktionieren des Buffers im Betrieb. 

Wenn also der Buffer bis zum Maximum gefüllt ist, werden die einzelnen Frames in der richtigen Reihenfolge freigegeben. Zuerst natürlich das I-Frame. Da das I-Frame in der Regel das Bild ist, welches den meisten Speicher braucht, wird somit schlagartig ein größerer Speicherbereich frei, der wiederum die Möglichkeit gibt, Daten von der CD in den Buffer nachzulesen. Parallel dazu werden Stück für Stück die nach dem I-Frame stehenden Frames (P und B Frames) aus dem Buffer gelesen. Hierdurch ergibt sich ein stetes Auf und Ab der gespeicherten Menge Bilddaten im Buffer. 

Aus diesem Umstand ergibt sich die Möglichkeit, über einen kurzen Zeitraum einen "schnelleren" Datenstrom auszugeben, als er von der CD (z.B. 75 Sektoren oder 150 Sektoren pro Sekunde ) physikalisch nachgelesen werden kann. 

Hierdurch erklärt sich das Überschreiten der durch den Player vorgegebenen max. Transfergeschwindigkeit. 

So ist es je nach Filmsequenz möglich, Filmszenen mit 3000 kbps oder mehr zu generieren, obwohl z.B. bei der SVCD ein max. Datenrate (Video+Audio+Muxingrate+etc.) von nur 2.788,8 kbps erlaubt ist. Es entstehen dadurch sogenannte "peaks", bei denen der Film kurzeitig eine deutlich höhere Datenrate haben kann.

Die damit erreichte Überhöhung schafft es in vielen Fällen, ein Verblocken zu verhindern bzw. zu minimieren.

Der Zeitpunkt an dem der Buffer ausgelesen wird, ist noch von einem weiteren Faktor abhängig, nämlich der Art des zu DEcodierenden GOPs. 

Wir erinnern uns, dass es die verschiedenen GOP Größen und Strukturen 1/5/2/1 ( I P B B P B B P etc.) über 1/12/1/1 ( I P B P B P B etc.) bis hin zu 1/14/0/1 ( I P P P P P P etc.) gibt. 

Die Art mit der nun diese GOPs DEcodiert werden, beeinflusst die Möglichkeit, wie schnell die einzelnen Frames aus dem Buffer wieder ausgelesen werden können. Bei einer Struktur von 1/5/2/1 können die B-Frames erst dann ausgelesen werden, wenn das nachfolgende P oder I Frame im Buffer vorhanden ist, da ja das B-Frame zum DEcodieren ein vor – oder nachfolgendes I oder P Frame als Referenzframe braucht.

Das bedeutet, in diesem Fall befinden sich im Buffer relativ viele Bilder, die nicht ausgelesen werden können, da ja das letzte Referenzbild nicht vorhanden ist. 

Damit vergibt man bis zu einem gewissen Grad die Möglichkeit, den Bildern mehr Datenrate zuzugestehen, da ja alle Frames im Buffer gehalten werden müssen. Durch diesen Umstand lässt sich erkennen, das es durchaus sinnvoll ist, den Buffer möglichst groß zu gestalten und bei einem kleinen Buffer die Zahl der B-Frames im Buffer zu reduzieren.

Sie sehen daraus, dass zum einen die Größe des Buffers und zum anderen die Anzahl der B-Frames (also die GOP-Einstellung) bedeutsam sind.

 
Schauen wir uns einmal eine Filmsequenz mit einem geeigneten Werkzeug an.

Wir nutzen dazu "MpegRepair" von Pixeltools, das mir netterweise von Dick Kors von Pixeltools in einer eingeschränkten Version für Testzwecke überlassen wurde:

Denkbar ist auch das Programm "MPEG-Analyser" von Bernhard Schuur. Die Demoversion reproduziert jedoch nur vorgefertigte Ergebnisse und ist für einfache Versuche nicht nutzbar. Vermutlich muss man erst 3000,- US$ auf den Tisch legen, um etwas mehr als einen Einblick auf eine Website zu bekommen.

Pixeltools war da etwas hilfsbereiter! 

Wer Alternativen sucht, wird sicher unter http://www.mpeg.org/MPEG/companies.html im Bereich "Test Equipments, Stream Analyzers and Test Streams" fündig. ;-)

Für einen einfachen Test habe ich 132 Frames einer Bundestagsdebatte mit Gregor Gysi genommen und sie mit verschiedenen TMPGEnc-Einstellungen zu einem SVCD-MPEG-Stream umgewandelt.

Nun sind Bundestagsdebatten, zumal es um Haushaltsfragen geht, nicht sehr aufregend. Weder vom Inhalt noch von der Dynamik im Videostream.

Im ersten Anlauf habe ich den VBV bewusst mit 48 KByte zu klein gehalten.

Das Ergebnis sieht so aus:

Abb 5: VBV 48K

Der buffer overflow ist vorprogrammiert, da die einzelnen Bilder nicht kpl. in den VBV passen.

Um nun den ganzen Stream nicht erneut kpl. durch den TMPGEnc schicken zu müssen, könnten Sie den VBV mittels TMPGEnc Ver 12 (ab Version 12a ist die Funktion meines Wissens nicht mehr vorhanden) optimieren:

Das Ergebnis sieht dabei so aus:

Abb 6: VBV 68K

 
Während bei einem VBV von 48 KByte die einzelnen Bilder nicht in den VBV hineinpassen, können Sie nun sehen, dass der Film mit dem automatisch neu generierten VBV von 86 KByte hinkommt.

Ein buffer overflow wird somit vermutlich nicht auftreten!

Schaut man sich den so erzeugten Stream jedoch genauer an, so fallen am Anfang des Streams zwei "System Header" auf.

Abb 7: System Header doppelt

Offensichtlich wird bei der Aktion an den vorhandenen Header einfach ein neuer Header angehängt:

Abb 8: System-Header Inhalt

Ob das bei allen Applikationen einwandfrei läuft, darf bezweifelt werden. Vermutlich finden wir deshalb diesen Menüpunkt bei den neueren TMPGEnc-Versionen nicht mehr.

In einigen Newsgroups kann man immer wieder lesen, dass es eine Alternative sei, den Stream einfach zu demultiplexen und dann wieder zu multiplexen. 

Wir machen das auch wieder mit TMPGEnc:

Das Ergebnis sieht nun so aus:

Abb 9: VBV 48 K

 
Das war wohl nichts. Es gibt keine Veränderungen zum Ausgangsstream hinsichtlich der VBV-Werte im "sequenz header".

Auch die Verwendung von AVI2MPEG2 (bbMPEG V1.24 beta 18) hat uns nicht weitergebracht. Auch hier blieb die 48 KByte-VBV-Grenze im "sequenz header" erhalten!
 

Offensichtlich sollte man doch von vornherein die richtige VBV-Buffergröße auswählen.

Nachdem wir im obigen Beispiel das "overflow"-Problem beleuchtet haben, lassen Sie uns noch einmal das "underflow"-Problem beleuchten, wie es z.B. beim "Muxen" auftreten kann.

Vielleicht haben Sie schon einmal die nachfolgende Fehlermeldung von bbMPEG gesehen:

Multiplexing file d:\test.mpg
video PTS (59272.37ms) underflow at pack 6627 by 0.97ms
video DTS (59522.62ms) underflow at pack 6671 by 44.05ms
video PTS (59555.98ms) underflow at pack 6678 by 57.35ms
video PTS (59606.03ms) underflow at pack 6680 by 20.63ms
video DTS (59639.40ms) underflow at pack 6682 by 0.60ms
etc, etc.

 
Schauen wir uns nochmals die MPEG-Entstehung an:

Der Ausgang eines MPEG-Encoders liefert (mind.) zwei Datenströme. Einen Video- und Audio-Bitstrom, die Elementary Streams (ES) genannt werden. Die Aufgabe des Packetizers und des Multiplexers ist es nun, diese beiden Informationsströme und auch weitere Zusatzinformationen zu einem einzigen " Program Stream" (PS) oder in einem sep. Schritt zu einem "Transport Stream" (TS) zusammenzufassen.

Abb 10: ES / PES / PS

Damit Bild und Ton synchron bleiben, werden zusätzlich Maßnahmen zur Takt(re)generierung im Decoder und zur Synchronisierung von Video und Audio (Lippensynchronität) getroffen. 

Mit PES (Packetised Elementary Stream) werden Video-, Audio- oder auch andere Typen von Datenströmen nach dem "Packetizer" bezeichnet. 

Zum Zwecke der Übertragung werden solche Video- bzw. Audio-Ströme übrigens in Pakete zerlegt und in diesem Fall (nach dem Packetizer) mit einem PES-Header versehen. 

Der Aufbau eines solchen Paketes soll uns hier nicht weiter interessieren. Wichtig ist jedoch die Information, dass neben den Bild- und Ton-Daten dort noch verschiedene Header Informationen und sogenannte "Time Stamps" - also Zeitstempel vorhanden sind.

Die Notwendigkeit von "Zeitstempeln" (Time Stamps) im Datenstrom ergibt sich daraus, dass ein Videodekoder einen B-Frame vom vorigen I-Frame und den folgenden P-Frames rekonstruieren muss, die Reihenfolge, in der er sie anzeigt, jedoch anders ist. Wir sprachen weiter oben schon über dieses Problem.

Nun gibt es zwei Arten von Time Stamps: Zuerst haben wir da einmal den "Decode Time Stamp" (DTS), der anzeigt, wann der Frame zu dekodieren ist, und dann den "Presentation Time Stamp" (PTS), der vorgibt, wann der Frame anzuzeigen ist.

Zur einwandfreien Funktion benötigen die Zeitstempel (Time Stamps) noch eine Referenz-Uhr (Referenz Clock), die "System Clock Reference" (SCR).

Vereinfacht kann die SCR als die Zeit angesehen werden, die notwendig ist, die Daten z.B. von einer CD zu lesen.

Eine fehlerhafte Verwaltung dieser Zeitstempel führt unmittelbar zu Synchronisationsfehlern bei Bild und Ton. Doch schauen wir im Detail:


Jedes Paket mit MPEG-Daten hat nun einen SCR - Zeitstempel. Dies ist im Prinzip die Zeit, die die System-Uhr benötigt, um ein Datenpaket zu lesen. Normalerweise schaltet der Decoder den Systemtaktgeber an wenn er anfängt die Daten des MPEG-Streams zu lesen. Wenn Sie so wollen, fangen wir bei (fast) "Null" an und zählen mit jedem Paket nach oben weiter.

Abb 11: Packet-Strukur

Wenn nun die "System Clock Reference" (SCR) die Größe der DTS-Zeitmarke erreicht hat (Decode Time Stamp), gibt es eine Information an den Decoder mit dem Decodieren des Frames zu beginnen. Einen Augenblick später werden dann das Bild und der Ton -gesteuert über den "Presentation Time Stamp" (PTS)- ausgegeben.

Brent Beyeler (der Autor von bbMPEG) hat einmal ein schönes Beispiel gebraucht:

Wenn die SCR für ein Datenpaket bei den Videodaten 100 ms beträgt, dann ist das die Zeit, die benötigt wird, die Daten von der Festplatte oder der CD zu lesen, nachdem man auf die Taste Play gedrückt hat.

Sagen wir mal DTS/PTS sind 200/280ms. Dann sind die Daten nach 200 ms decodiert und 80 ms später werden sie zur Anzeige gebacht.

Zwischenzeitlich werden die Daten im Buffer gehalten (siehe oben).

Die "underflows" treten nun also auf, wenn die Video-Datenrate größer als die "Muxing-Rate" ist. Machen wir es wieder mit einem Beispiel: 

Die "Muxing-Rate" beträgt z.B. 1.000.000 bits/sec. Das bedeutet, dass der Decoder über den VBV 1.000.000 bits/sec aus dem Datenfile auslesen kann. Und die Video-Datenrate beträgt nun z.B. 2.000.000 bits/sec, also dass 2.000.000 bits benötigt werden, um eine Sekunde Film zu zeigen, dann haben wir ein Problem. Denn dann kann das File nicht schnell genug ausgelesen werden, um eine Sekunde Video ohne Unterbrechung auszugeben. Der VBV läuft leer.

In diesem Fall zeigen uns die DTS/PTS-Zeitstempel, dass das Video zu einem Zeitpunkt decodiert und angezeigt werden soll, zu dem es noch gar nicht aus dem File ausgelesen wurde. SCR und DTS/PTS passen also nicht mehr zusammen. Es tritt der gefürchtete "underflow"-Error auf.

 
Je nach Decoder kann das nun ein Problem sein oder auch nicht. Besonders PC-basierte Decoder kümmern sich an dieser Stelle recht wenig um die SCR und produzieren keine "underflows". Sie lesen einfach frei von der Festplatte oder der superschnellen CD weg - was das Zeug hält. Oft verlieren Sie aber beim "Spulen" den Überblick und reagieren mit Asynchronität zwischen Bild und Ton.

 
Schauen wir uns unsere o.a. Bundestagsdebatte einmal hinsichtlich ihrer Datenrate (Bitrate) an:

Abb 12: Datenrate

Sie besteht im Kern aus drei Szenen. 

Im ersten Teil der Abgeordnete Gysi, in der Mitte ein schneller Blick ins Parlament mit klatschenden Abgeordneten und dann wieder Herr Gysi.

In der Grafik können wir in der Mitte deutlich einen Anstieg der Datenrate erkennen. Da änderte sich das Bild, wurde bedingt durch den Schwenk und die stärkere Bewegung im Bild unruhiger und nur eine höhere Datenrate konnte eine Artefakt-Bildung (Blockbildung) verhindern. Das hat der Encoder aufgrund der Vorgaben vollautomatisch und richtig gemacht.

Solange Sie hinsichtlich der Datenrate innerhalb der Grenzen der SVCD-Spezifikation bleiben, wird vermutlich auch kein "underflow"-Fehler auftreten. Gehen Sie jedoch bei Ihren Einstellungen darüber hinaus und die Video-Datenrate wird größer als die "Muxing-Rate", so haben Sie ein Problem. Das Problem kann aber auch dann auftreten, wenn sich der Encoder nicht an die Vorgaben hält und ganz wild irgendwelche Spitzen (peaks) produziert.

Der "Muxer" hat nun an der Stelle eigentlich drei Möglichkeiten:

• Er erzeugt eine Fehlermeldung und hört auf.
• Er ignoriert das Problem vollkommen und überlässt es dem Player damit fertig zu werden.
• Er kann aber auch einzelne Datenblöcke weglassen. Bei einem Video können das z.B. ganze Bilder sein, die da unterschlagen werden. Nun gehört aber zu jedem Bild auch ein Stück Ton und dadurch wird die Sache etwas komplex und wird deshalb von sehr wenigen "Muxern" nur wirklich beherrscht.

Fragen Sie mich bitte nicht, welches Programm welche Strategie verfolgt. Ich habe das nicht weiter untersucht. Vermutlich werden aber die meisten Systeme das Datenraten-Problem einfach ignorieren und der arme Player kann sehen, wie er fertig wird.

Dieser kann dann nur noch durch "ruckeln" und Asynchronität von Audio und Video reagieren. Die Newsgroups sind voll von Anfragen nach solchen Problemstellungen.

Wenn Sie nun die Datenrate aus irgendwelchen Gründen erhöhen wollen (oder Ihr Encoder nicht sauber arbeitet), müssen Sie auch die Muxrate steigern um "underflow"-Fehler zu vermeiden. 

bbMPEG (meiner Meinung eines der besten Programme zum Muxen von PS-Streams) z.B. macht folgende normgerechte Vorgabe: 3528 für VCD und 6972 für SVCD.

Was verbirgt sich hinter diesen Zahlen:

Bei einer VCD haben wir eine feste Muxrate von 176.400 Byte/s und bei SVCD max. 348.600 Byte/s. 'Maximal' deshalb, weil bei der SVCD ja eine variable Datenrate erlaubt ist. 

Wenn Sie wissen wollen, wo diese Zahlen herkommen, sei Ihnen mein Tipp zum Thema "max. Datenrate" empfohlen.

Nun werden die Datenraten (Bitrate) aber sehr oft in Einheiten von 50 Bytes angegeben, weil in den entsprechenden Feldern des Headers recht wenig Platz ist.

Aus diesem Grund bekommen wir bei der VCD 176.400 Byte/s / 50 = 3528 und bei der SVCD = 6972 heraus.

Wer mit diesen Einstellungen z.B. einer SVCD nicht hinkommt, kann ja mal anstelle der 6972 in das Feld der "Forced mux rate" eine "0" eingeben.

bbMPEG wird dann die notwendige Muxrate automatisch selbst bestimmen. Doch denken Sie daran, dass Sie damit ggf. den SVCD-Standard verlassen und eine XSVCD herstellen, wenn Sie die zulässige Datenrate überschreiten.

Ob die von Ihrem Player abgespielt werden kann, hängt dort von der Geschwindigkeit des eingebauten Laufwerks aber auch von der jeweiligen Firmware ab.

Lassen wir nun wieder etwas Praxis folgen:

Für die folgenden Schritte nutze ich die Tools von Brent Beyeler, downloadbar über http://members.cox.net/beyeler/bbmpeg.html .

Der erste Schritt ist das "De-Multiplexen" (demuxen) eines fertigen - mit TMPGEnc - erstellten Files. Mein File heißt übrigens "strip_48.mpg"

Wir nehmen dazu bbDMUX und rufen das Programm im DOS-Modus wie folgt auf:

• bbdmux strip_48.mpg

Sie können das Programm auch so aufrufen.

• bbdmux strip_48.mpg > inhalt.txt

Dann wird die Bildschirmausgabe in die Datei "Inhalt.txt" umgeleitet.

Als Ergebnis sehen etwa u.a. folgender Inhalt:

Wir wissen damit, dass sich in unserem MPEG-File ein Video-, ein Audio und ein Padding-Stream befinden und zwar kennen wir auch die jeweilige "ID" dazu.

Padding bezeichnet übrigens ungenutzte Füllbytes, um Zellen aufzufüllen oder Datenstrukturen auf bestimmte Vielfache von Bytes auszurichten. Bei einer SVCD muss z.B. eine Bildsequenz (GOP) genau mit einem vollen Sektor starten. Das bedeutet, dass ggf. Füllbytes zwischen die Sequenzen zu schreiben sind, die überhaupt keine Bildinformationen enthalten.

Auf den Paddingstream können wir jedoch in diesem Zusammenhang verzichten. Wir interessieren uns ja nur für den reinen Video- und den Audio-Stream.

Mit den DOS-Befehlen:

• bbdmux strip_48.mpg 0xe0 video.m2v
• bbdmux strip_48.mpg 0xc0 audio.m2a

isolieren wir die jeweiligen Dateien zu einem sep. Videofile mit dem Namen "Video.m2v" und einer Audio-Datei als "audio.m2a" (oder besser: "audio.mpa". Dann finden Sie die Datei gleich problemloser wieder).

Im nächsten Schritt starten wir AVI2MPG2:

Klicken auf "Start Encoding" ohne ein File geladen zu haben und bekommen danach folgendes Bild:

Nun klicken wir auf Settings und wählen im nächsten Bild die Karteikarte "Input and output files":

Dort laden Sie die einzelnen Segmente und definieren das Ausgangsfile, den "MPEG Program Stream".

Unter der Karteikarte "Program Stream Settings" wählen wir als "Program stream type" das SVCD-Format:

Mit einem Klick auf OK kommen wir wieder zur Ausgangsmaske zurück:

Mit einem Klick auf "Start" können Sie nun den Multiplexvorgang starten.

Das Ergebnis ist ein normgerecht gemultiplexter SVCD-MPEG-Stream.

Dem aufmerksamen Leser wird bei der Betrachtung der Packet-Struktur in Abb. 11 aufgefallen sein, dass TMPGEnc nicht die max. mögliche Muxrate von 348.600 Byte/s ausgenutzt hat. Das Programm hat hier nur 286.500 Byte/s genutzt. Ist ja OK - wenn´s ausreicht. 
 

 
Abb. 13: Packet structure bbMPEG

bbMPEG hingegen nimmt die eingestellten 348.600 Byte/s. Wer also einen optimalen Stream haben möchte, kann so z.B. TMPGEnc (dem ja jedwede Einstellung zu diesem Thema fehlt) und bbMPEG gut kombinieren.

Lässt man bbMPEG die Möglichkeit, die Muxrate selbst zu wählen (mit der Einstellung "0" - siehe oben), so beschließt das Programm, 336.350 Byte/s als Muxrate optimal seien (nur in diesem Beispiel). Es ist damit deutlich über dem TMPGEnc (286.500 Byte/s) - aber noch innerhalb der SVCD-Spezifikation.

bbMPEG befreit Sie durch das Muxen übrigens auch von dem doppelten Header, wie er in Abb. 7 aufgetaucht ist.

Um also den VBV-Eintrag im "sequenz header" zu ändern, können Sie ruhig TMPGEnc beta 12 nehmen - Sie müssen nur zusätzlich noch das File neu "muxen".

 
Eines muss aber an dieser Stelle nochmals klargestellt werden, weil es in den Newsgroups und verschiedenen Boards immer wieder hochkommt. 

Sie verändern durch neues Muxen nicht die Bildqualität im eigentlichen Sinne. Die wird ausschließlich durch die Qualität des vorgeschalteten Encoders bestimmt. Das Muxen macht ja nichts anderes als getrennte Dateien in eine Datei mischen. Die jeweiligen Bilder sind also bereits codiert. 

Sie haben durch nachträgliches Muxen aber evtl. die Möglichkeit, Synchronisationsfehler zwischen Bild und Ton und Ruckler in den Griff zu bekommen.

Wenn Ihr Film also hin und wieder ins Stocken gerät, wissen Sie zukünftig an welchen Schrauben Sie u.a. drehen können.

PS: Sollte das nicht helfen, so gibt es noch ein paar andere Möglichkeiten woran das "Ruckeln" liegen kann. "Gandalf_der_Graue" hat die Möglichkeiten im DVDBoard einmal zusammengefasst.