vormals hat sich dieser Beitrag hier befunden. Vielen Dank an alle, fuer die dort eingebrachten Ideen.
Da es mit dem urspruenglichen Thema nicht mehr so ganz viel zu tun hat, habe ich jetzt einen neuen Thread aufgemacht.
Aufgabe
Entwicklung eines Budgetkarten basierten VDRs mit VGA-Grafik-Ausgabe und RGB/PAL Ausgang in FF-Qualitaet.
Problem
die mir bislang bekannten Grafikkartensysteme arbeiten mit festem Videotiming, das nicht mit dem Stream synchronisiert ist. Dies fuehrt zwangslaeufig zu Frame/Field- verlusten, die sich stoerend bemerkbar machen (z.B. durch sporadisches Ruckeln)
Durch Software-Deinterlacing kann man dieses Problem weitgehend kaschieren, jedoch auf Kosten schlechterer Bildqualitaet bei Darstellung von Interlaced-Material und bei deutlich hoeherer Rechenlast.
Loesung
Grafikkarten sind grundsaetzlich nicht fuer variable Frameraten konzipiert. Man kann sich nur mit Hardware- oder Software Tricks behelfen. Wie es jetzt aussieht, reicht bereits eine reine Softwareloesung aus.
Ich habe den Radeon-DRM Treiber so modifizieren koennen, dass im erforderlichen Rahmen beliebige, von 50Hz leicht abweichende Timings am VGA-Port meiner Test-Radeon (IGP9100) ausgegeben werden. Genau so, wie eine FF Karte das auch macht. Durch ein neues Verfahren konnte ich inzwischen die sichtbaren Stoerungen am Roehren-TV aus meinem letzten Versuch (siehe hier) komplett eliminieren.
Dabei habe ich versucht die Zahl der Eingriffe ins System zu minimieren. Letztlich brauche ich im Moment nur noch 2 sehr ueberschaubare Patches in xine-lib und im Radeon DRM-kernel Modul. Der Xserver muss derzeit nicht mehr angefasst werden.
Grundsaetzlich funktioniert es so, dass die xine-lib, wenn sie einen PutImage() an den Server absetzt, nebenbei noch kontrolliert ob die Framerate des Xservers zu erhoehen/erniedrigen ist.
Auf diese Weise kann die xine-lib ihre PutImage() Calls immer wieder genau in die Mitte zwischen zwei Blanking-Intervallen driften lassen. Sollte die Framerate vom Stream Schwankungen unterworfen sein, ist das kein Problem da das Videotiming des Xservers sofort nachgefuehrt wird. Es gehen so bei gleichzeitig maximaler Stoersicherheit ueberhaupt keine Fields mehr verloren.
Da jetzt erstmalig auch unter Verwendung der xine-lib nicht mehr deinterlaced werden muss, fallen auch alle damit verbundenen Nachteile weg. Insbesondere wird der Prozessor dadurch deutlich entlastet. Mein betagter 2Ghz Celeron (400MHz 128KB Socket 478 CPU) langweilt sich inzwischen mit 80% idle bei SD Wiedergabe.
Ich konnte meine 1/2h Fussball-Testaufzeichung, die ich jetzt schon in und auswendig kenne:) ohne einen einzigen Field-Verlust anschauen. Bei bester interlaced PAL Qualitaet an einem Roehren-TV.
Das ganze ist natuerlich noch experimentell. Ich muss das Coding noch aufraeumen und an manchen Stellen allgemeiner formulieren. Weiterhin muss bei der Initialisierung noch eine Erkennung fuer das initiale Even/Odd Field eingebaut werden.
Dennoch glaube ich, darf man sich langsam vom Vorurteil verabschieden, eine Grafikkarte koenne angeblich keine echte interlaced 50Hz RGB/PAL Ausgabe mit variabler Framerate
Somit sind jetzt erstmalig Budget-Systeme auf Grafikkartenbasis auch mit geringer Prozessorleistung moeglich. Ohne dabei auf RGB PAL in FF-Qualitaet verzichten zu muessen.
Bei Gelegenheit werde ich alles mal besser dokumentieren und in die linuxtv.org ML einkippen. Wer sich vorab dafuer interessiert, im Anhang sind die aktuellen Patches.
viel Spass
[EDIT] ##############################################################
UPDATE VOM 10.08.2008:
EINE AKTUELLE VERSION DES PATCHES IST AB JETZT IMMER HIER ZU FINDEN
http://lowbyte.de/vga-sync-fields/
############################################################## [/EDIT]