Dieser Bastel-Thread:) soll sich um die exakte Synchronisation des Bildrefresh auf dem
Display mit der Framerate des decodierten MPEG Datenstromes drehen. Diese Synchronisation ist u.a.
fuer den optimalen Betrieb eines Displays (z.B.LCD-TV Roehren-TV, Computermonitor) ueber
den VGA/DVI Anschluss einer Grafikkarte im VDR wichtig.
Problem 1: exaktes Videotiming
Im Forum wurde schon einiges darueber philosophiert, warum Filmwiedergabe ueber Grafikkarten
und deren VGA/DVI Anschluss oft nicht absolut fluessig (d.h. ruckelfrei) ablaeuft.
Als Hauptgrund wird meist angefuehrt, dass die Grafikkarte mit starrem Videotiming laeuft,
das sich nicht einfach mit der Framerate des decodierten Bildmaterials synchronisieren laesst.
Das ist zwar grundsaetzlich richtig, aber bei entsprechender Konfiguration des Videotimings
der GraKa ist dieser Effekt IMHO eigentlich vernachlaessigbar. Dies soll im weiteren
erklaert werden.
Der MPEG Videostream von Sender liefert die PAL-Halbbilder mit exakt 50Hz, deswegen wird im
weiteren ein 50Hz-faehiges Display vorausgesetzt. Diese Eigenschaft haben roehrenbasierte
Geraete immer, LCD- und Plasmageraete offenbar nur in Ausnahmefaellen.
Jetzt kommt es also drauf an, dass die Grafikkarte moeglichst genau auf diese 50Hz
programmiert ist, da es sonst in gewissen Zeitabstaenden zu verdoppelten/weggelassenen
Halbbildern kommt.
Folgender Zusammenhang besteht zwischen tatsaechlicher Refreshrate der Grafikkarte (F)
und der Zeit zwischen den unerwuenschten Halbbild-Spruengen (T_SKIP). Es ist nichts anderes
als die Formel fuer die Periodendauer einer Schwebung zwischen zwei Frequenzen:
T_SKIP = 1 / (50 - F)
Beispiel:
Eine Grafikkarte laeuft mit 49.99Hz Refreshrate. Dann bekommen wir
T_SKIP = 1 / (50Hz - 49.99Hz) = 100s
Das heisst bei 49.99Hz Refreshrate muessen 100 Sekunden vergehen, bis ein einziges Halbbild
zum Zweck der Resynchronisierung uebersprungen/hinzugefuegt werden muss. Das ist vielleicht
nicht perfekt, aber dieses 'Problem' wird man unter normalen Umstaenden mit blossem Auge
kaum wahrnehmen.
Der nVidia CS X-Server scheint in diesem Punkt die Nase vorne zu haben. Der
Vertikalrefresh laesst sich hier tatsaechlich in 0.01Hz Schritten konfigurieren.
Im Anhang ein kleines Programm, das die Refreshrate fuer Radeon Karten bei laufendem
X-Server anzeigt. Es benutzt hierzu das DRM Kernelmodul ueber die zugehoerige
DRM Library (Direct Rendering Manager). Tests vorsichtshalber aber nicht auf Produktivsystem
machen.
Problem 2: Bildrefresh exakt in den VBLANK Phasen
Ein weiteres Problem entsteht, wenn der Inhalt der Framebuffer waehrend der Uebertragung
zum Display veraendert wird. Um dies zu vermeiden, wird der Framebuffer-Update am besten
nur in den VBLANK Phasen des Videosignales vorgenommen.
Loesung:
Beim nVidia X-Server gibt es hierfuer bekanntlich die 'XVideoTextureSyncToVBlank' Option. Diese
Funktion wird hier in Hardware ausgefuehrt - natuerlich die beste Variante.
Im ATI Radeon DDX habe ich nichts Vergleichbares gefunden. Auch im Inet scheint sich niemand
dafuer zu interessieren. Deswegen habe ich einen kleinen Patch mit genau dieser Funktion
geschrieben. Er ist urspruenglich fuer das ATI Radeon DDX in X.Org 7.[12] gedacht, kann aber
sinngemaess leicht auf andere Grafikhardware angepasst werden. Das DRM Modul (optional)
gibt es fuer einige GraKas und die Putimage Routinen in den verschiedenen X-Servern sind sich
meist recht aehnlich.
Der Patch ist im Anhang.
Ich habe ueber '#defines' steuerbar verschiedene Optionen eingebaut. Wahlweise kann die
Synchronisation ueber BusyWait, das direkt auf die Hardwareregister der Radeon geht, laufen.
Alternativ ueber einen blockierenden ioctl() des DRM Treibers. Dieser bekommt seine Interrupts
genau in den VBLANK Phasen und eignet sich gut fuer unsere Zwecke.
Uebrigens liegt die Systemlast bei der BusyWait Version erstaunlicherweise nicht wesentlich
hoeher, als bei der ioctl() Version.
Weitere Optionen sind diverse Debugmoeglichkeiten, z.B. Timestamps wenn Frames wegen ungenauer
Refresh-Einstellung uebersprungen werden muessen. Optional wird die Rate, mit der die Frames vom
MPEG-Decoder/Deinterlacer geliefert werden, ausgegeben.
===
Mit dem Patch habe ich nun fluessige PAL-RGB Wiedergabe (interlaced) ueber eine IGP 9100 (Radeon)
und dem VGA to RGB Adapter an einem Roehren-TV.
Es funktioniert aber genauso gut mit progressiven 50Hz ueber VGA/DVI an einem Computermonitor.
Nur ein geeignetes LCD-TV, das z.B. native 1366x768@50Hz versteht, konnte ich fuer den Test
noch nicht finden.
Gibt's sowas ueberhaupt?? 
