DirectShow und Synchronisation
Wer professionell einen HTPC betreiben will, muss sich über die unterschiedliche Funktionsweise von Stream- (Push-Verfahren) und Dateiwiedergabe (Pull-Verfahren) im Klaren sein und wissen, wie man Wiedergabe und Ausgabe entsprechend synchronisiert.
DirectShow[Bearbeiten]
Die Audio/Video-Verarbeitung ist im DVBViewer über DirectShow realisiert. Es handelt sich dabei um ein komponentenbasiertes Multimedia-Framework von Microsoft. Die Komponenten werden Filter genannt und man unterscheidet folgende Filtertypen:
Source (e.g. DVB Source))
Transform (e.g. MPEG-2/H.264 Dekoder)
Sink/Renderer (e.g. Video Mixing Renderer)
Zusammengestöpselte Filter werden Graph genannt.
Synchronisation im DirectShow-Graph[Bearbeiten]
Beim Aufbau eines Filtergraphen durch den DVBViewer wird eine Referenzuhr festgelegt. Zu dieser Uhr synchronisieren sich sämtliche Filter. Damit ist gewährleistet, dass Audio und Video mit der richtigen Geschwindigkeit und synchron zueinander verarbeitet und ausgegeben werden. Klingt einfach, ist es aber nicht.
Synchronisation bei Dateiwiedergabe[Bearbeiten]
Beim Erstellen eines Videos werden Zeitstempel generiert anhand welcher Audio und Video synchron zueinander Wieder- bzw. Ausgegeben werden können. Dazu wird natürlich meist eine andere Uhr für die Zeitstempelgenerierung verwendet als bei der Ausgabe, was aber bei der Dateiwiedergabe keine Rolle spielt, weil die Wiedergabe mit einer anderen Uhr dann lediglich etwas schneller oder langsamer erfolgt, die Daten können variabel schnell aus der Datei gelesen werden. Vorteilhaft wäre, wenn es für die Audio- und Video-Ausgabe eine gemeinsame Uhr oder zumindest zueinander synchrone Uhren geben würde, was im PC-Bereich aber nicht der Fall ist. Auf Grund der Komponentenbasiertheit findet man in einem PC viele Uhren, die keinen Bezug zueinander haben. Meist wird in einem DirectShow-Filter-Graph die hochpräzise Uhr der Soundkarte zur Synchronisation herangezogen, welche aber keinen Bezug zur Uhr in der Grafikkarte hat, welche zuständig für die Videoausgabe ist. Es kommt zu einem Phänomen, das als Mikroruckeln bezeichnet wird, da die Zeitstempel der Videobilder, wie sie im DirectShow-Graph anhand der Soundkarten-Uhr generiert wurden, nicht synchron mit den VSYNC-Signalen (welche die Grafikkarte veranlassen, das Bild am Anzeigegerät zu aktualisieren) laufen, für die meisten nicht wahrnehmbar, bei Videoenthusiasten aber ein hochsensibles Thema. Ganz schlimm wird es, wenn die Bildrate des Anzeigegerätes (Hz) nicht mit der des abzuspielenden Videos (fps) übereinstimmt bzw. kein Vielfaches davon ist.
ReClock-Ansatz[Bearbeiten]
ReClock verfolgt den Ansatz, dass das menschliche Auge sehr viel empfänglicher für Fehler ist als das Gehör. ReClock ersetzt den Audio-Renderer im DirectShow-Graph und stellt eine zur Audio-Clock alternative Zeitbasis zur Verfügung, welche mit der Grafikkarte synchronisiert ist. Somit ist sichergestellt, dass die Wiedergabe bzw. Verarbeitung im DirectShow-Graph synchron mit der Videoausgabe in der Grafikkarte erfolgt. Für eine zum Video synchrone Audioausgabe passt ReClock den Audio-Pitch bzw. die Audiogeschwindigkeit adaptiv an. Diese Anpassungen sind aber sehr gering und für das menschliche Gehör nicht wahrnehmbar.
Problem Bitstream Audio-Ausgabe über S/P-DIF[Bearbeiten]
Frequenzanpassungen können nur auf Audiorohdaten angewendet werden (PCM), nicht aber auf komprimierte Datenströme (e.g. bei AC3/DTS-Ausgabe über S/P-DIF). Dieses Problem versucht ReClock mit einem Drop/Repeat-Algorithmus zu lösen. Das heißt je nachdem, ob Audio zu schnell oder zu langsam im Vergleich zum Video ist, werden AC3-Frames entweder verworfen oder dupliziert, um die Synchronität zu wahren. Die dadruch entstehenden Audioartifakte sind aber deutlich wahrnehmbar.
Synchronisation in einer Streamingumgebung (DVB)[Bearbeiten]
Erzeuger/Verbraucher-Prinzip (Producer/Consumer)[Bearbeiten]
Anders als bei der Dateiwiedergabe ist man in einer Streamingumgebung wie DVB auf die Streamgeschwindigkeit angewiesen. D.h. der Dekoder (Empfänger im Haushalt bzw. Consumer) synchronisiert sich optimalerweise auf die Rate, mit der der Enkoder (Sendeanstalt bzw. Producer) die Daten erzeugt hat. Verarbeitet der Dekoder die Daten schneller, als sie der Enkoder erzeugt, kommt es im Dekoder zu Buffer-Underruns, dem Dekoder gehen also die Daten immer wieder aus. Erzeugt der Enkoder die Daten schneller als sie der Dekoder verarbeitet, kommt es im Dekoder zu Buffer-Overflows. Die Puffer im Dekoder laufen voll woraufhin Daten verworfen werden. Beide Phänomene resultieren in wahrnehmbaren Audioaussetzern oder Bildrucklern.
DVB-Clock[Bearbeiten]
Es sollte mittlerweile klar sein, dass ReClock in einer Streamingumgebung keinen Sinn macht, da in diesem Fall auch die Uhr der Grafikkarte nicht weiterhilft. Man benötigt eine Zeitbasis, die synchron zur Ersteller-Uhr ist, damit es zu keinen Underruns oder Overflows kommen kann.
DVBViewer-Entwickler Griga hat sich intensiv mit dem Synchronisationsproblem in einer Streamingumgebung auseinandergesetzt. Das Ergebnis ist eine Referenzzeit, welche die Uhr des Enkoders auf Dekoderseite abbildet. Diese kann anhand der über DVB übermittelten PCR-Werte (Presentation Clock Reference) rekonstruiert werden. So sind Producer und Consumer optimal synchronisiert.
Video-Scheduling und Audio Rate-Matching[Bearbeiten]
Die Video- bzw. Bildausgabe wird nun anhand der DVB-Clock geschedult, welche nicht synchron zur Uhr der Grafikkarte für die Videoausgabe läuft.
Ein weiteres Problem hat man bei Audio, wie schon bei der Dateiwiedergabe mit ReClock. Die Audio-Samples werden weiterhin mit der Soundkarten-Uhr ausgegeben. Diese kann nicht zur DVB-Clock synchronisiert werden. Audio wird also höchstwahrscheinlich etwas schneller oder langsamer im Vergleich zum Video ausgegeben und es kommt zu Buffer-Underruns bzw. Overflows im Audio-Renderer. Aus diesem Grund wird Rate-Matching angewendet. Anhand des Puffervöllegrads im Audio-Renderer wird die Audio-Frequenz entsprechend angepasst, damit dieser konstant bleibt.
Der DirectSound Audio Renderer verwendet für die Frequenzanpassung die Audio-Hardware (Soundkarte). Ob man die Arbeitsweise dieses Mechanismus wahrnehmen kann, hängt von der Qualität der verbauten Audio-Hardware ab. On-Board Audio-Lösungen können die Frequenz meist nur in 150 Hz Schritten anpassen, was etwas grob ist und dazu führt, dass zum einen recht oft nach oben und unten korrigiert wird, und man zum anderen Änderungen dieser Höhe akkustisch wahrnehmen kann (allerdings nur, wenn ein konstanter Piepton ausgegeben wird, sonst ist die Wahrnehmbarkeit weniger gegeben). Der DirectSound Audio-Renderer versucht in 75 Hz Schritten zu regeln. Hochwertigere Soundkarten sollten dazu in der Lage sein (e.g. ASUS Xonar DX). Da ist dann eine Änderung selbst bei einem konstanten Piepton kaum bis gar nicht auszumachen. Sehr realitätsnah ist dieser Test auch nicht, da man beim täglichen Fernsehn kaum auf einen konstanten Piepton treffen wird.
Da auch hier eine Frequenzanpassung durchgeführt wird, funktioniert diese Methode bei komprimierten Datenströmen (e.g. AC3-Ausgabe über S/P-DIF oder HDMI) nicht. Video und Audio werden also zwangsläufig auseinanderlaufen. Die Clock-Drifts sind aber so gering, dass man das erst nach etlichen Stunden merken würde.
GothSync - Alternativer Synchronisationsansatz[Bearbeiten]
GothSync ist in der Lage, die Bildwiederholrate des Anzeigegeräts über die Grafikkarte feinzutunen, sprich, die Wiedergabe wird nicht an die Ausgabe gekoppelt, sondern die Ausgabe an die Wiedergabe. Somit könnte man theoretisch die Ausgabegeschwindigkeit mit der DVB-Clock synchronisieren. GothSync verwendet das PowerStrip-API, was eine sehr feine Anpassung der Bildwiederholrate ermöglicht. Dass Problem dieser Methode ist, dass aktuelle Grafikchips nicht mehr unterstützt werden. Sie stellt also mehr eine Demonstration dar, wie es gehen könnte.
