50Hz über DVI - fast gelöst (?)

Zitat

Original von solli
Also habe ich mich mal rangemacht, die Ausgabe auf 720x576@50Hz umzustellen. Klappt auch sehr gut - nur leider nicht immer. Die Laufschrift ist mal ruhig, nach 3 Sekunden stottert sie gewaltig, dann gehts wieder. Manchmal rennts eine Minute lang ruckelfrei durch, dann wieder eine Minute recht arges Stottern (auffälliger als das Dauerruckeln im 60Hz-Modus).

Es könnte sein, dass du die 50Hz nicht genau getroffen hast und das so was ähnliches wie Aliasing-Effekte sind.
Ich würde zuerst mal versuchen die Bildfrequez ein wenig zu variieren.

Zitat

Original von solli
Also wenn ich das richtig verstehe, kann es sein, dass ich den LCD über X mit exakt 50Hz ansteuere, der Fernseher aber intern von den 50Hz etwas abweicht?

Der Fernseher sollte sich eigentlich auf das zugeführte Signal synchronisieren und dann mit nach dem Takt laufen.

Es ist eher so, dass das Video mit 50Hz läuft und die Grafikkarte nicht exakt mit den 50Hz des Videos.

Zitat

In welcher Grössenordnung soll ich die Frequenz variieren (müssen es ganzzahlige Frequenzen sein)?

Schon ein minimaler Unterschied (< 1Hz) der beiden Frequenzen kann reichen, dass es zu unschönen Überlagerungen kommen kann. (Bei den FF-Karten wird der Quarzoszillator im Betrieb laufend kalibriert um exakt synchron zum Videomaterial zu sein!)

Zitat

Original von SHF

Der Fernseher sollte sich eigentlich auf das zugeführte Signal synchronisieren und dann mit nach dem Takt laufen.

Es ist eher so, dass das Video mit 50Hz läuft und die Grafikkarte nicht exakt mit den 50Hz des Videos.

Ich wette, daß weder die Karte noch das Video-Signal mit exakt 50Hz daher kommen.

Im Ernst:
Damit so etwas wirklich richtig funktioniert, müßte die Bildfrequenz der Grafikkarte auf die Bildfrequenz des Videosignals aufsynchronisiert werden, wie es z.B. die FF-Karten machen. K.A. ob irgendein Standard-Kartentreiber so etwas kann.

CU
Oliver

Zitat

Originally posted by UFO
Damit so etwas wirklich richtig funktioniert, müßte die Bildfrequenz der Grafikkarte auf die Bildfrequenz des Videosignals aufsynchronisiert werden, wie es z.B. die FF-Karten machen. K.A. ob irgendein Standard-Kartentreiber so etwas kann.

ich kenne keine GraKa, die eine Videotimingaenderung im laufenden Betrieb erlaubt. Das wuerden vermutlich schon die
angeschlossenen Displays gar nicht mitmachen.

Aber man kann das GraKa-Videotiming moeglichst exakt auf 50Hz einstellen. Das klappt z.B. mit einer Radeon IGP9100 recht
gut. Wenn ich zum Debugging das Deinterlacing komplett abschalte, sehe ich, dass ca. alle 70 Sekunden ein Halbbild schneller
vom Stream kommt, als es der Xserver wegen des starren Timings ausgeben kann.
Das laesst sich mit deaktiviertem Deinterlacer besonders gut beobachten, da dann nach dem Halbbildverlust
ca. 70 Sekunden lang die Even und Odd Fields vertauscht wiedergegeben werden. Nach dem
naechsten Halbbildverlust stimmt die Reihenfolge fuer 70 Sekunden wieder.

Wenn das Deinterlacing aktiv ist, bemerkt man diesen alle 70 Sekunden auftretenden Halbbildverlust nicht mehr.

Das Problem von dem 'solli' spricht, hat mit der exakten 50Hz Einstellung vermutlich gar nichts zu tun. Ich hatte vor einiger
Zeit mal die Zeiten im Xserver mitgestoppt, zu denen die Frames von xine ueber diverse Libraries angeliefert werden. Dabei habe ich festgestellt,
dass mit dem 'remote'-Frontend von xineliboutput (ein separater Prozess) die Frames sporadisch ueber laengere Zeit
(etliche Sekunden) nicht mit mit 50Hz im PutImage() des Xservers ankommen. Vielleicht sind Latenzen auf dem Datenpfad zwischen dem xine-internen Frame-Timer
und dem CRT-Controller der GraKa schuld?
Die Effekte waren dann aehnlich denen, wie Solli sie beschreibt.

Beim 'local'-Frontend von xineliboutput (laeuft in eigenem Thread) habe ich dieses Problem noch nicht beobachtet. Die
Wiedergabe ist hier ruckelfrei.

Zitat

Original von sparkie

ich kenne keine GraKa, die eine Videotimingaenderung im laufenden Betrieb erlaubt. Das wuerden vermutlich schon die
angeschlossenen Displays gar nicht mitmachen.

Displays synchronisieren sich immer auf die Frequenz der Karte (im möglichen Rahmen - versteht sich).

Ich kann mir zwei Möglichkeiten vorstellen, dies zu realisieren.

1. Man modifiziert den Oszillator der Grafikkarte, so daß die Frequenz in einem engen Bereich regelbar ist. (So wird es bei den FF-Karten gemacht,)

2. Bei VGA-ähnlichen Karten könnte man während der Austastlücke das Timing anpassen. Wenn man die Zahl der nicht angezeigten Pixel am Zeilenende verändert, wird die Zeile insgesamt kürzer oder länger, und die Bildfrequenz ändert sich entsprechend.

In beiden Fällen müßte man ein paar Bilder puffern und der Pufferfüllstand überwachen. Falls er unter die Minimum-Marke fällt, würde man die Bildfrequenz minimal verringern, beim Übersteigen der Maximum-Marke entsprechend umgekehrt. Sehe keinen Grund, wieso das nicht funktionieren sollte.

CU
Oliver

Zitat

1. Man modifiziert den Oszillator der Grafikkarte, so daß die Frequenz in einem engen Bereich regelbar ist. (So wird es bei den FF-Karten gemacht,)

diese Loesung gefaellt mir sehr gut, insbesondere da sie transparent fuer die Grafikkarte ist.

Zitat

2. Bei VGA-ähnlichen Karten könnte man während der Austastlücke das Timing anpassen. Wenn man die Zahl der nicht angezeigten Pixel am Zeilenende verändert, wird die Zeile insgesamt kürzer oder länger, und die Bildfrequenz ändert sich entsprechend.

da bietet aber keine mir bekannte Grafikkarte ein Interface, welches das zulaesst. Timingaenderungen sind eigentlich immer einem
Reset der kompletten Ausgabe-Einheit (Ramdac, CRT-Controller etc.) gleichzusetzen.

Ich denke die groesste Huerde waere schon mal genommen, das Timing moeglichst nahe auf 50 Hz zu stellen. Die Geschwindigkeit
mit der die Frames dekodiert werden (im Softdekoder) muss dann genau auf *diese* starren 50 Hz der Grafik synchronisiert werden,
und nicht umgekehrt.

Eine einfache Rechnung: Angenommen die Karte zeigt in 70 Sekunden nicht 50Halbbilder/s * 70s == 3500Halbbilder sondern
wegen ungenauer EInstellung nur 3499Halbbilder. Diesen konkreten Wert erreiche ich z.B. mit meiner Testkonfiguration. Die Abweichung vom
Soll betraegt also ca. 0.000285%. Macht pro Stunde einen Nachlauf 0.000285% von 3600s == 1.026s. Eine Abweichung,
mit der man fuer's erste leben kann.

Wenn man moechte koennte man in einem weiteren Schritt diese Abweichung mit deiner Oszillatormethode komplett eliminieren.

Auf diese Weise waere ueber eine VGA-Grafikkarte ein PAL-RGB Ausgang realisierbar, voellig ruckelfrei, da immer synchron
zum Dekoder. Deinterlacer Artefakte fallen komplett weg. Da wie bei der FF gar nicht erst deinterlaced wird. Nicht zu vergessen
der Wegfall der CPU-intensiven Deinterlacer-Arbeit, die mindestens soviel Rechenpower verschlingt wie das Dekodieren der Frames selbst.

Eine Loesung dieser Art fuer Budgetsysteme schwebt mir schon immer vor Augen. Die Ausgabequalitaet wuerde einer FF Karte
in Nichts nachstehen. Die erforderlich CPU Leistung waere relativ gering.

Ich habe hier sowas sogar schon in weiten Teilen am Spielen. Es fehlt noch der Abgleich der Dekodergeschwindigkeit in xine mit
der Framerate der Grafik. Da habe ich das Projekt eingefroren, weil mir HDTV erst mal wichtiger war:)

Der drm-Treiber ist fuer die Dekoder-Synchronisation eigentlich wie geschaffen, da er genau in den
VSYNC Phasen der Grafik einen Interrupt erzeugt.

Zitat

Original von sparkie

diese Loesung gefaellt mir sehr gut, insbesondere da sie transparent fuer die Grafikkarte ist.

da bietet aber keine mir bekannte Grafikkarte ein Interface, welches das zulaesst. Timingaenderungen sind eigentlich immer einem
Reset der kompletten Ausgabe-Einheit (Ramdac, CRT-Controller etc.) gleichzusetzen.

Alles anzeigen

Vor einigen Jahren hatte ich mal mit VGA-Timing gespielt. Iirc konnte man dieses jederzeit ändern.

Außerdem gibt es doch irgend so ein Tool, mit dem man Modelines für X optimieren kann (Korrektur der Bildposition auf dem Monitor). Modelines sind nichts anderes als die VGA-Timing-Register.

K.A. ob sich da bei DVI was geändert hat. Sollte erst mal nur ein Denkanstoß sein...

Zitat

Ich denke die groesste Huerde waere schon mal genommen, das Timing moeglichst nahe auf 50 Hz zu stellen.

Ist ein einmaliger Abgleich. Hier sehe ich nicht so das große Problem.

Zitat

Die Geschwindigkeit
mit der die Frames dekodiert werden (im Softdekoder) muss dann genau auf *diese* starren 50 Hz der Grafik synchronisiert werden,
und nicht umgekehrt.

Das Problem ist die Datenpufferung - übrigens nur im Live-Modus. Denn bei Wiedergabe einer Aufnahme kann die Grafikkarte die Geschwindigkeit ohnehin vorgeben und braucht nicht synchronisiert zu werden.[*]

Folgendes gilt also für den Livemodus:
Ist die Bildfrequenz der Grafikkarte höher, läuft der Puffer leer.
Ist die Bildfrequenz niedriger, kommen Daten schneller herein als sie ausgegeben werden können. Folglich wird irgendwann der Puffer überlaufen.

Umgehen kann man dieses Problem auch, indem man einfach Timeshift verwendet und die Grafikkarte mit etwas zu niedriger Frequenz laufen läßt. Die überschüssigen Daten werden dabei auf der Platte gespeichert. Problem gelöst.

Zitat

Eine einfache Rechnung: Angenommen die Karte zeigt in 70 Sekunden nicht 50Halbbilder/s * 70s == 3500Halbbilder sondern
wegen ungenauer EInstellung nur 3499Halbbilder. Diesen konkreten Wert erreiche ich z.B. mit meiner Testkonfiguration. Die Abweichung vom
Soll betraegt also ca. 0.000285%. Macht pro Stunde einen Nachlauf 0.000285% von 3600s == 1.026s. Eine Abweichung,
mit der man fuer's erste leben kann.

Wenn man moechte koennte man in einem weiteren Schritt diese Abweichung mit deiner Oszillatormethode komplett eliminieren.

Auf diese Weise waere ueber eine VGA-Grafikkarte ein PAL-RGB Ausgang realisierbar, voellig ruckelfrei, da immer synchron
zum Dekoder. Deinterlacer Artefakte fallen komplett weg. Da wie bei der FF gar nicht erst deinterlaced wird. Nicht zu vergessen
der Wegfall der CPU-intensiven Deinterlacer-Arbeit, die mindestens soviel Rechenpower verschlingt wie das Dekodieren der Frames selbst.

Eine Loesung dieser Art fuer Budgetsysteme schwebt mir schon immer vor Augen. Die Ausgabequalitaet wuerde einer FF Karte
in Nichts nachstehen. Die erforderlich CPU Leistung waere relativ gering.

Ich habe hier sowas sogar schon in weiten Teilen am Spielen. Es fehlt noch der Abgleich der Dekodergeschwindigkeit in xine mit
der Framerate der Grafik. Da habe ich das Projekt eingefroren, weil mir HDTV erst mal wichtiger war:)

Der drm-Treiber ist fuer die Dekoder-Synchronisation eigentlich wie geschaffen, da er genau in den
VSYNC Phasen der Grafik einen Interrupt erzeugt.

Alles anzeigen

Sobald HDTV für mich mal interessant wird, werde ich mich damit näher beschäftigen. Bis dahin bin ich mit FF-Karten bestens bedient.

CU
Oliver

[*] Für eine perfekte Ausgabe muß natürlich immer der Datentransfer in den Framebuffer mit dem Bildwechsel synchronisiert werden. Afaik wird auch dies nur von manchen Treibern unterstützt...

Zitat

Außerdem gibt es doch irgend so ein Tool, mit dem man Modelines für X optimieren kann (Korrektur der Bildposition auf dem Monitor).

xvidtune? Bei fast jeder Timingaenderung bricht da kurzzeitig die Synchronisation zum DIsplay komplett weg.

Zitat

[*] Für eine perfekte Ausgabe muß natürlich immer der Datentransfer in den Framebuffer mit dem Bildwechsel synchronisiert werden. Afaik wird auch dies nur von manchen Treibern unterstützt...

Ist bei aelteren, radeon-basierten Karten kein Problem, da diese DoubleBuffer haben. Die meisten Treiber der
Nvidia Serie warten mit dem BitBlit auf den vsync. Man koennte also viele kostenguenstige Grafikkarten fuer unseren Zweck hernehmen.

Zitat

Umgehen kann man dieses Problem auch, indem man einfach Timeshift verwendet und die Grafikkarte mit etwas zu niedriger Frequenz laufen läßt. Die überschüssigen Daten werden dabei auf der Platte gespeichert. Problem gelöst.

genauso habe ich mir das auch vorgestellt. Durch Nachjustieren der Quarzfrequenz auf der GraKa koennte man den Timeshift-Versatz sogar immer optimal klein halten.

Zitat

Original von sparkie

xvidtune? Bei fast jeder Timingaenderung bricht da kurzzeitig die Synchronisation zum DIsplay komplett weg.

Ja, war wohl xvidtune o.ä.

Wobei zu prüfen wäre, ob die Synchronisation auch wegbricht, wenn man
a) nur die Zeilenlänge minimal ändert
b) das ganze in der Austastlücke macht.

Evtl. ist der Holzhammeer, den xvidtune anwendet, etwas zu groß.

Zitat

Ist bei aelteren, radeon-basierten Karten kein Problem, da diese DoubleBuffer haben. Die meisten Treiber der
Nvidia Serie warten mit dem BitBlit auf den vsync. Man koennte also viele kostenguenstige Grafikkarten fuer unseren Zweck hernehmen.

genauso habe ich mir das auch vorgestellt. Durch Nachjustieren der Quarzfrequenz auf der GraKa koennte man den Timeshift-Versatz sogar immer optimal klein halten.

Ja. Btw, eine Schaltung hierzu findet man im Datenblatt der FF-Karte...

CU
Oliver

Zitat

Originally posted by UFO
Sobald HDTV für mich mal interessant wird, werde ich mich damit näher beschäftigen. Bis dahin bin ich mit FF-Karten bestens bedient.

ich dachte zuerst auch, dass mir HDTV (noch) zu wenig Nutzen bringt...

...bis ich den VDR + vdr-xine Plugin auf meinem Thinkpad (1680x1050 LCD) installiert habe. Das Bild ist ein Traum.

Wenn man auf die Pause-Taste geht, hat man praktisch ein Photo auf dem Schirm. Der Unterschied zu SD wird hier besonders deutlich.

Zitat

Ja. Btw, eine Schaltung hierzu findet man im Datenblatt der FF-Karte...

super. Danke fuer den Hinweis!

BTW: leider haben wir uns ewig weit vom Topic entfernt...

'solli' muesste mal naehere Angaben zu seinem System machen. Mit welchen Parametern wird xineliboutput gestartet etc.? Sonst ist eine Diagnose schwer moeglich.

Zitat

xineliboutput wird gestartet mit local=none und remote=37890
vdr-sxfe --video=xv --fullscreen --aspect=auto --tcp

so laeuft aber gerade das remote-Frontend, das bei mir ebenfalls keine guten Ergebnisse im Bezug auf 'Ruckeln' liefert.
Hast du mal getestet mit diesen Eintraegen in der setup.conf:

[...]
xineliboutput.Frontend = sxfe
[...]
xineliboutput.Video.Deinterlace = tvtime
xineliboutput.Video.DeinterlaceOptions = method=Greedy2Frame,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0,use_progressive_frame_flag=1,chroma_filter=0,enabled=1
xineliboutput.Video.Driver = xv
[...]

dabei darf das Plugin nur mit folgenden Parametern gestartet werden (sonst wirkt die setup.conf nicht):

-P\'xineliboutput -p\' \

Kontrolle: es darf nach vdr-Start kein Prozess 'vdr-sxfe' laufen.

Hi,

@ Oliver:

>Ja. Btw, eine Schaltung hierzu findet man im Datenblatt der FF-Karte...

Das klingt interessant...
Finde aber im wiki nichts konkretes.
Kannst du mir einen Link geben?

Was meinst Du:
Könnte man eine Graka in der Art modden, dass man einen schneller-/ langsamer-Pin hätte und so die Takte synchron bekommt?

Grüße
Funzt

Zitat

Original von Funzt
>Ja. Btw, eine Schaltung hierzu findet man im Datenblatt der FF-Karte...

Das klingt interessant...
Finde aber im wiki nichts konkretes.
Kannst du mir einen Link geben?

http://www.linuxdvb.tv/documentation/AV711x_3_1.pdf (Abbildung Seite 26 oben)

Zitat

Was meinst Du:
Könnte man eine Graka in der Art modden, dass man einen schneller-/ langsamer-Pin hätte und so die Takte synchron bekommt?

In der angegeben Schaltung bestimmt das Tastverhältnis zwischen High und Low am CTRL-Eingang die Spannung an den Varicaps und damit die Frequenz.

CU
Oliver

Hi,

danke für de Link.

Grüße
Funzt

Zitat

Originally posted by UFO
In der angegeben Schaltung bestimmt das Tastverhältnis zwischen High und Low am CTRL-Eingang die Spannung an den Varicaps und damit die Frequenz.

inzwischen habe ich die Arbeit an dieser Baustelle wieder aufgenommen. Den Referenz-Takt in der xine-lib leite ich bereits erfolgreich von den 50HZ (Interrupts) der Grafikkarte ab. Dazu habe ich in das DRM Modul meiner Radeon einen ioctl() eingebaut. Der ist kompatibel zu gettimeofday(2). Aber auf Basis der VSYNCs.

Ich teste derzeit noch mit meinem Pundit und integrierter Radeon IGP9100 Chipsatz-Grafik.

Die Idee von Oliver weiter oben, das Timing der Graka dynamisch zu variieren, gefaellt mir sehr gut.

Wenn das klappt, koennte man eine perfekte Interlaced-Ausgabe ueber eine Graka realisieren.

Kennt jemand vielleicht eine Grafikkarte (muss keine Radeon sein), mit einem halbwegs gut zugaenglichen Oszillator, fuer eine Modifikation, wie Oliver sie oben beschreibt?

Oder hat evtl. jemand in diesem Bereich schon experimentiert?

Hi solli =)

Zitat

Original von solli

I... könnte mir die zugehörige xorg.conf (bzw. die 720x576@50Hz-Modeline) zukommen lassen?
Wenn ich mit der falsch generierten Modeline daneben liege - wo könnte sonst noch der Hund begraben liegen?

danke schon mal im Voraus und lg,
Stefan

Benutzt du den CS Treiber von Nvidia ? Dann hast du die Möglichkeit, ohne Modeline auszukommen und den Modus in der xorg.conf mit einzig einem Parameter aufzurufen, und zwar so: WICHTIG: Die Hz Zahl wird mit dem "_" angegeben; eine Modeline brauchst du nicht. So handeln sich Graka und TV / Beamer den 50Hz Modus selbst aus und man trifft ihn wohl am genausten.

...
Section "Screen"
	Identifier	"Screen0"
	Device	"Card0"
	Monitor	"Monitor0"
	DefaultColorDepth 24
	Option "AllowNon60HzDFPModes, NoDFPNativeResolutionCheck"

	SubSection "Display"
		Depth	24
		Modes "1280x720_50"
	EndSubSection
...

Wichtig sind auch noch andere Parameter; schau dir also zuvor mal meine xorg.conf an - hier kannst du sie ansehen / runterladen:

xorg.conf 1280x720_50

Ich benutze eine GF 6200 PCI und steuere so mit dem streamdev-client meinen Beamer an. Die Auflösung kannst du ja manuell noch ändern. Ich muss aber sagen, so richtig zufrieden bin ich aber immer noch nicht mit dem Ruckeln der Laufschrift - ich denke aber mal meine CPU Leistung ist zu gering (1Ghz P3). Unter Windows XP, 50Hz, und nem 2600er XP Athlon gibts dieses Ruckeln der Laufschrift nämlich nicht am LCD TV / Beamer.

Kai

@ sparkie

Hi,

ich habe hier eine Radeon 9200SE liegen u. noch ein paar Nvidia Grafikkarten. Was ein Oszillator bedeutet, habe gar keine Ahnung, aber ich wurde dir und UFO gerne helfen.

Reichen dir eigentlich auch paar Fotos von den Grafikkarten?