[patch] RGB/PAL ueber VGA mit variabler Framerate

Hi Matthias,

Zitat

Originally posted by Hitman47
Ich habe folgende Website entdeckt: No more tears
Ich konnte es auch aus dem git-repository kompilieren und installieren.
Dabei sind dann auch die Mikroruckler weg, die bei mir mit Xv-Overlay auftreten.

Mit diesem Fund hast du genau ins Schwarze getroffen! Ich habe leider immer nur mit demselben Testmaterial gearbeitet. Ich konnte aber inzwischen die von dir bereits hier

Zitat

das Bild und die dazugehörige Bewegung gut aus. Am Bildschirmrand treten aber Verzerrungen auf, die bei
Kameraschwenks immer etwas irritieren. Das Bild müsste wohl verkleinert werden.

bemerkten Probleme reproduzieren. Den Grund dafuer konnte ich jetzt auch herausfinden:

In allen bis heute veroeffentlichen Versionen des Treibers 'xf86-video-ati' befindet sich ein Scaler Bug. Dieser betrifft aber nur den 'Overlay Adapter'. Der Bug ist vermutlich bislang nur deswegen niemand aufgefallen, da die dadurch auftetende vertikale Verschiebung der Scanlines im Framebuffer minimal ist. Mit aktiviertem Deinterlacer hat man keine Chance, den Fehler zu bemerken.

Da wir in unserem System nicht mehr deinterlacen, machen sich die Ueberschreiber der Even/Odd Fields sofort in den von dir erkannten Verzerrungen bemerkbar. Der Bug tritt aber nur bei bestimmten Senderaufloesungen z.B. 480x576 in Erscheinung. Darum habe ich es bislang nicht bemerkt.

Dieser Xserver Bug sollte sich aber fixen lassen. Andererseits ist es jetzt gar nicht mehr unbedingt noetig. Deine Erfahrung

Zitat

Aber guter Dinge bin ich trotzdem, denn der Bildfluss ist genial; wie man es nun einmal von einer "normalen" TV-Umgebung gewohnt ist.

kann ich teilen. Der in Version 6.9.0 von 'xf86-video-ati' erstmalig eingefuehrte 'Textured Adapter', der alternativ zum 'Overlay Adapter' eingesetzt werden kann, hat diesen Bug nicht!

Zitat

Der VBI muss aber trotzdem noch getrimmt werden, da z.Bl Laufleisten zeitweise zu zittern beginnen.
Das würde dein Patch wohl beheben. Wenn es aber von offizieller Seite her gemacht wird und das von R100-R500-Chips ist das ja auch nicht schlecht, nicht wahr?

durch den VDR sind wir wohl eine der wenigen mit der speziellen Anforderung, das VGA Signal mit einem externen Signal (Stream) zu synchronisieren. Ich weiss nicht, ob/wann wir da jemals einen Upstream-Support erhalten. Aber in einer speziellen LowCost Budget VDR Distribution koennte man das Erfordernis entsprechend beruecksichtigen.

Zitat

Einsetzen kann ich diese Methode trotzdem nicht, da auf den hochbittigen Sendern ein breiter, vertikaler Streifen mit Datenmüll angezeigt wird und es ist erkennbar, dass etwa drei vertikale Segmente dargestellt werden, die aber nicht Synchron arbeiten -> Tearing

richtig. Konnte ich auch sehen. Der 'Textured Adapter' hat in dieser Version noch keine Tearing Protection. Leider komme ich erst am Wochenende dazu, den Tearing Patch, der das Problem behebt, zu testen.

Zitat

(EE) RADEON(0): drm: could not allocate surface for front buffer!
Die Meldung tritt auch auf der Kopie deines Systems auf. Ist das bei dir genauso?

ja, vermutlich ein Problem in der DRM Library. Ich konnte bislang keine negativen Folgen sehen und bin dem deswegen nicht weiter nachgegangen.

Fuer das Wochenende habe ich geplant, ein LowCost Budget Referenzsystem mit Pentium 800MHz, TT-S1401, und Radeon 9600SE zu bauen. Wenn hier alle Tests erfolgreich abgeschlossen sind, kann ich dir gerne wieder einen Software-Update (fuer den Pundit) zukommen lassen.

Ich werde dann mal versuchen hier im Forum eine umfassende Hardware/Software-Beschreibung dieses Referenzsystems zu posten, um den Nachbau zu erleichtern.

- sparkie

anbei ein Update der Patches/Tools rund um das Thema. Neu ist:

- Portierung auf Debian Lenny mit Kernel 2.6.24
- Upgrade des xserver-xorg-video-ati auf Version 6.9.0 + letzte Patches (z.B. experimental texture tearing fix etc.)
- Implementierung noch feinerer 50Hz PAL Timing Justierschritte
- explizites Einschalten der VBLANK Interrupts (ist ab Kernel 2.6.24 erforderlich)
- ein paar kleine Tools

Ich verwende 2 verschiedene diskless Hardware-Testumgebungen, jedoch mit dem gleichen Softwarestand:

System 1:
Prozessor: celeron 2,0GHz
Speicher: 512MB
Grafik: integrierte Radeon 9100 IGP
Budget: TT-S1401

System 2:
Prozessor: Pentium III (Coppermine) 800MHz
Speicher: 512MB
Grafik: AGP Radeon 9200 SE (RV280)
Budget: TT-S1401

Die interlaced PAL-Wiedergabe ist auf beiden Systemen absolut gleitend und ohne Fieldverluste. Selbst die Rechenleistung des kleineren Systems reicht also fuer das Verfahren aus.

Versuchsweise verwende ich jetzt den Textured- statt den Overlay- XV-Adapter. Die Tearfree Acceleration fuer den xserver-xorg-video-ati Treiber, die seit dem 16. Juli als Patch erhaeltlich ist (siehe auch hier) kann mich in diesem fruehen Entwicklungsstadium aber noch nicht ueberzeugen. Dennoch habe ich diesen Patch, der noch zusaetzliche Aenderungen von mir enthaelt, mal in den Anhang gestellt.

Vielmehr lassen sich inzwischen die variablen 50Hz Timings der VGA-Grafik derart exakt einstellen, dass man sie bedingt sogar als Tearing-Fix missbrauchen kann:)

Fuer ein Produktivsystem ist noch folgendes zu implementieren:

- Erkennung der initial field parity
- Tearfree Acceleration fuer Textured XV-Adapter (durch Grafik-Hardware)
- schnellerer Regel-Algorithmus fuer die Erkennung der variablen 50Hz Framerate
- umfangreicheres + besseres Toolset

matthias:
mit dem 'intron.c' aus dem Toolset solltest du die VBLANK Interrupts aktivieren koennen.

so, wieder ein entscheidendes Problem geloest. Dank der Mithilfe der Radeon-Entwickler (siehe auch dieser Post) konnte ich das von mir oben beschriebene Problem bzgl. 'Scaler Bug' im Radeon-Xserver fixen.

Dieser Patch

diff -ru xserver-xorg-video-ati-6.9.0.org/src/radeon_video.c xserver-xorg-video-ati-6.9.0/src/radeon_video.c
--- xserver-xorg-video-ati-6.9.0.org/src/radeon_video.c 2008-05-28 22:35:06.000000000 +0200
+++ xserver-xorg-video-ati-6.9.0/src/radeon_video.c     2008-07-28 22:27:45.000000000 +0200
@@ -2859,7 +2899,7 @@
     OUTREG(RADEON_OV0_P23_V_ACCUM_INIT, p23_v_accum_init);
     OUTREG(RADEON_OV0_P23_H_ACCUM_INIT, p23_h_accum_init);


-   scale_cntl = RADEON_SCALER_ADAPTIVE_DEINT | RADEON_SCALER_DOUBLE_BUFFER
+   scale_cntl = RADEON_SCALER_VERT_PICK_NEAREST | RADEON_SCALER_ADAPTIVE_DEINT | RADEON_SCALER_DOUBLE_BUFFER
         | RADEON_SCALER_ENABLE | RADEON_SCALER_SMART_SWITCH | (0x7f<<16) | scaler_src;
    switch(id){
         case FOURCC_UYVY:

loest also das Problem. Bezueglich der Wiedergabequalitaet sind im Moment keine weiteren Probleme offen. Ich weiss nicht, was man da noch verbessern koennte.

matthias:
damit ist auch in den von dir beobachteten Problemfaellen die Wiedergabe absolut gleitend (und jetzt eben sogar mit dem Overlay XV Adapter).
Dieser ist im Moment zu bevorzugen, da er double buffers einsetzt. Und somit im Gegensatz zum textured Adapter keinerlei 'tearing' Probleme hat (siehe oben).
Falls du noch mal testen willst muss ich dir allerdings das komplette 'radeon_video.c' geben, da ich dort noch was anderes gefixt habe.

weitere Diskussionen zum Thema gibt es inzwischen auch auf der vdr- ML:

[vdr] RGB/PAL over VGA at variable frame rate

und auf der xorg-driver-ati- ML:

Problem with persistent scaling/shifting in RADEONDisplayVideo()
(Dieses Problem ist bereits gefixt. EIn herzliches Dankeschoen an die Radeon-Entwickler, insbes. an Roland Scheidegger fuer den entscheidenden Hinweis)

Damit ist mit dem hier vorgestellten Verfahren auf Radeons bereits eingeschraenkter Produktivbetrieb moeglich. Die Bildqualitaet des interlaced PAL am VGA-Port ist einfach sagenhaft.

Zur Vollendung fehlen jetzt nur noch ein paar Fleissaufgaben. Weitere Patches poste ich wieder hier. Mal schauen, wie weit ich am Wochenende komme...:)

Zitat

Fuer ein Produktivsystem ist noch folgendes zu implementieren:

- Erkennung der initial field parity

auch das letzte, mir bekannte Problem mit dem Radeon-Chipsatz ist jetzt geloest. Siehe auch hier:

How to get current field polarity of interlaced video output?

die naechsten Tage gibt's wieder 'nen aktualisierten all-inclusive Patch:)

Hitman47:

Zitat

Hoffentlich komme ich heute noch zum Testen.

am besten du wartest meinen naechsten Patch noch ab. Ich habe alles noch deutlich robuster gemacht. Z.B. hinsichtlich der Streuung der Quarzfrequenzen verschiedener Hardware. Es sind dann auch alle mir bislang bekannten Probleme gefixt. Ich hoffe ich schaffe es bis heute abend. Muss heute naemlich noch paar andere Dinge != VDR erledigen;)

8N1:

Zitat

funzt dein Patch auch mit 'nem Mobility-Chipsatz ( konkret: X700 Mob.) ?

konkret getestet habe ich bislang nur mit Radeons wie 7000, 9200SE, 9250, 9600SE, IGP-9100.
Aber es sollte mit jedem Radeon Chipsatz funktionieren, der von xf86-video-ati bzw. xserver-xorg-video-ati unterstuetzt wird. Und das sind mittlerweile eine ganze Menge. Siehe auch 'man radeon' oder ganz aktuell:

wget -q 'http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=blob;h=03622a0c4af391e5f3ef4bd8b8f810eb2d1eff59;hb=1f3eee3682f3598a303c9c3accfbe01b245cacf9;f=man/radeon.man' -O -|nroff -man|less

Am besten erst VGA/SCART ohne alle Patches testen. Wenn das geht, sollte der Patch auch funzen.

Ich muss mal irgendwo die Doku konzentriert zusammenfassen. Als Kabel verwende ich derzeit dieses (also ich glaube, einfacher geht es nun wirklich nicht mehr:)):

VGA                                                SCART


     1 -O------------------------------------------O- 15 R
     2 -O------------------------------------------O- 11 G
     3 -O------------------------------------------O-  7 B


     6 -O---------------------------------------+--O- 13 R Gnd
     7 -O---------------------------------------+--O-  9 G Gnd
     8 -O---------------------------------------+--O-  5 B Gnd
    10 -O---------------------------------------+--O- 17   Gnd
                                                +--O- 14   Gnd
                                                +--O- 18   Gnd
               ------
     9 -O-----|  75R |-----------------------------O- 16
               ------
-VS 14 -O-----------------------+
                                |
                             | /
               ------        |C
-HS 13 -O-----| 680R |-----B-|     BC 547 B
               ------        |E
                             | \
                                |       ------
                                +------| 680R |----O- 20 -CS
                                        ------
  shell-O------------------------------------------O- 21 shell

Zitat

Originally posted by 8N1
Danke für die Infos. Wenn die neue FP für's Notebook kommt greif ich es mal an.

alles klar. Ausserdem: das Kabel schon mal vorab zu bauen ist ja nie verkehrt.

leider habe ich es letztes Wochenende nicht mehr geschafft, einen aktuellen Patch rauszugeben. Mir fallen leider immer wieder neue Optimierungen ein, die ich noch reinpacken moechte:)

Mitterweile verliere ich absichtlich ein Field, naemlich wenn ich zu Beginn einer Wiedergabe auf eine andere Fieldparity synchronisieren muss. Naja dadurch konnte ich immerhin einen weiteren Patch in der xine-lib einsparen:D

Ausserdem habe ich anfaenglich den Programmier- und Testaufwand fuer die Synchronisation etwas unterschaetzt. Es soll ja auch auf anderen Maschinen (nicht nur auf meiner) problemlos laufen.
Aber es sieht alles schon sehr gut aus.

Die naechsten Tage gibt's aber in jedem Fall was... auch wenn ich dann vielleicht noch nicht alle Ideen reingepackt habe.

Zitat

Originally posted by SHF
du scheinst eines der Hauptprobleme bei der Wiedergabe von Live-TV am Computer gelöst zu haben!

oh - danke:) Naja, auf einem gewissen, von uns allen so geliebten proprietaeren "sog. Betriebssystem", laeuft sowas ja schon laenger. Umso mehr hat es mich immer geaergert, dass Live-TV und MPEG2 Dekodierung ueber Grafikkarten auf Linux ziemlich vernachlaessigt wird.
Dabei ist die Dekodierung gar nicht so das Problem. Da reichen auch kleine Prozessoren. Das beste Beispiel hierfuer sind die SMTs. Also warum ueberhaupt den nicht vorhandenen GPU Spezifikationen der Grafikkarten hinterherlaufen, wenn alleine die Interlaced-Ausgabe schon die meisten Probleme behebt?

Zitat

[*]Wie sieht es mit anderen Programmen unter X aus, laufen die dann auch noch oder läuft X dann nur noch in Kombination mit einem gepatchten Xine-Player?

mein aktueller Patch, der kurz vor dem Release steht:) geht nur noch gegen das Xserver-DDX xf86-video-ati und das Radeon-DRM Modul. Im Xserver wird dabei nur die XV-Putimage Funktion angefasst. D.h. volle Kompatibilitaet des Xservers bleibt erhalten.

Zitat

[*]Wie sind die Chancen, das sich auch andere Grafikkarten benutzen lassen? Konkret die von Nvidia, könnte es mit den Closedsource-Treiber klappen (an ein paar Stellen kommt man ja doch dran)?
Wenn ich es richtig verstanden habe ist es wohl am wichtigsten den Grafiktreiber einen Vsync-Interrupt zu entlocken. Meine GF2 scheint den schon von sich aus zu liefern (laut Interruptcounter).

die Frage ist halt, inwieweit man sich in den proprietaeren nVidia-Treiber einklinken kann. Vielleicht ein Binaer-Patch? Oder vielleicht ist das Nouveau Projekt eine bessere Grundlage?

Ich habe absichtlich keine radeon-spezifischen Features verwendet, damit der Port auf andere Hardware moeglichst einfach wird.

Konkret habe ich vor einiger Zeit mit xf86-video-intel (allerdings mit GM965/GL960 - ist gerad' nix anderes griffbereit) angefangen. Leider funktioniert dort der XV-Putimage() offenbar im Interlaced Mode nicht richtig. Bin dem aber nicht weiter nachgegangen.

Im Moment kann ich mich mangels Urlaub nicht um alle Baustellen intensiv genug kuemmern. Auch eine Portierung auf DirectFB waere schliesslich sehr interessant. Teilweise habe ich schon damit angefangen. Aber vielleicht hat ja auch sonst noch jemand Lust dazu?

Da alle hardwarespezifischen Probleme fuer die Radeons geloest sind, bleibe ich jetzt erst mal bei denen. AUsserdem sind die inzwischen recht guenstig (ab 8EUR mit Porto), da braucht man gar nicht immer unbedingt die Onboard-Grafik bemuehen. Die Radeons gibt's ab 15EUR ja sogar fuer PCIe - und solche Slots hat man als typischer VDR-User (bis jetzt) eh meistens frei:)

Zudem gibt es die meisten Radeons auch im Low-Profile Format. Zusammen mit einer Low-Profile Budget kann man also kleine Gehaeuse niedriger Bauhoehe einsetzen.

Hi Funzt

Zitat

Originally posted by Funzt
Wenn ich es richtig verstanden habe, dann ist deine Arbeit hier auf eine Ausgabe von 576i ausgelegt.

naja, die Arbeit befasst grundsaetzlich erst einmal nur mit der Regelung des VGA Videotimings durch ein externes Signal. Dass man dadurch unter gewissen Umstaenden (eben genau nur bei 576i) das Deinterlacen einsparen kann, ist sozusagen nur ein 'Abfallprodukt'.

Zitat

Könnte man, bei Ausgabe über xineliboutput, PAL von 576i auf 1080i ohne Qualitätseinbußen wandeln
(ohne Deinterlacing) und so quasi SDTV und HDTV ausschließlich über 1080i ausgeben?

ohne entsprechenden Graka SUpport sehe ich da keine Chance. Selbst bei meiner einfachen SCART Loesung hatte ich schon jede Menge Probleme zu bewaeltigen, damit vertikal keinerlei Skalierung stattfindet. Sonst wuerden sich die Even/Odd Fields gegenseitig ueberschreiben. Vorallem stoesst man hier auf Bugs die sonst niemandem auffallen, weil sonst keiner diesen Modus benutzt:)

-sparkie

Zitat

aber 576i über HDMI sollte doch gehen, oder?

richtig. Jetzt muessten wir nur noch eine entsprechende GraKa finden, die hier gut genug dokumentiert ist:) Ich habe da im Moment nicht so den Ueberblick.

so, ich haenge ohne grossen Kommentar mal meine aktuellen Patches hier an. Ich habe alles nochmal komplett ueberarbeitet. Die Regelung arbeitet jetzt wie eine echte PLL, aber halt in Software:)

die Referenzfrequenz auf die gelockt wird, ist die Framerate des DVB Streams. Der VCO ist die Fieldrate, die die VGA produziert.

Das Regelverhalten gefaellt mir schon sehr gut. Die Utility 'drift_control.c' arbeitet standalone (also ohne VDR - nur mit dem gepatchten Xserver und DRM Modul). Damit habe ich das ganze debuggt.
Witzig ist, wenn man mit dem Tool 'trim.c' Stoerungen simuliert und beobachtet wie die Regelung das in moeglichst kurzer Zeit wieder ausgleicht.

Die Fieldparity wird jetzt korrekt erkannt. Die Korrektur der Fieldparity muesste eigentlich in der Xine-Library erfolgen, damit keine sichtbaren Stoerungen auftreten (ist aber wenn ueberhaupt nur einmal beim Start). Damit ich die xine-lib im Moment nicht zu patchen brauche, mache ich diese Korrektur auch gleich im Xserver.

Fuer reine Wiedergabe (ohne gesteckte DVB Karte) liefert der Patch bereits optimale Ergebnisse.

Es ist aber noch ein Problem aufgetreten: Wenn im Rechner eine SAT Karte steckt (egal ob mit oder ohne SAT Kabel), reissen die DVB Treiber sporadisch fuer ueber 21ms die CPU an sich. Ich weiss nicht, was die da wieder programmiert haben. Aber fuer ein Produktivsystem , das auch Aufnehmen kann, reicht das noch nicht.

Durch die Loggings der genauen Zeitmessungen bekomme ich diese Probleme jetzt endlich schwarz auf weiss geliefert. Bei solchen Bugs in den Treibern wundert mich die ganze Ruckelei ueber die sich die Leute bei Budgetloesungen oft beschweren gar nicht mehr:)