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

neptunvasja:

danke fuer die Mithilfe. Ich versuche jetzt doch erst die Software-Variante. Vielleicht gelingt es doch, on the fly die Vertikaltimings der Graka umzuschalten, ohne dass sichtbare Stoerungen auftreten.

Ich habe jetzt immerhin schon zwei 50Hz Modelines. Die eine ist ein paar 1/1000stel ueber die andere unterhalb der exakten 50Hz. Ich werde versuchen zwischen diesen beiden Timings hin- und herzuschalten, dass sich im Mittel exakt 50Hz ergeben. D.h. der Timeshiftbuffer immer auf minimaler Groesse gehalten wird.

Zitat

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

Man muss nur an die beiden Pins des Quarzes und an Masse (evtl. muss man noch zwei Kondensatoren runterlöten), das sollte eigentlich immer machbar sein.

verfolge das sehr interessiert

bin mal gespannt ob ihr das mit den 50hz hinbekommt, haette auch gerne ruckelfreie laufschriften bei ntv

Zitat

bin mal gespannt ob ihr das mit den 50hz hinbekommt, haette auch gerne ruckelfreie laufschriften bei ntv

kleiner Zwischenbericht:

ich bin jetzt soweit, dass kurz bevor die DoubleBuffer in der GraKa umgeschalten werden, im Xserver kontrolliert wird, ob fuer die kommenden Fields die schnelle oder langsame 50Hz Modeline programmiert werden soll.

Das funktioniert schon super d.h. ich habe keinen einzigen Halbbildverlust mehr, da im Mittel tatsaechlich exakt 50HZ gefahren werden! Eine erste Zwischenetappe ist also erreicht.

Aber:
Es ist IMHO nicht moeglich, zwischen beiden Modelines hin und herzuschalten ohne minimale (aber sichtbare) Stoerung auf dem Roehren-TV. Das Bild zuckt dabei kurz nach oben, und laeuft bis zum naechsten Modeline-Umschalten stabil weiter.

Ist ja auch klar: die Vertikalsteuerung der Ablenkelektronik wird ja schlagartig mit (minimal) geaendertem Vertikaltiming konfrontiert.

Fazit:
Auch wenn die rein softwareseitige Umschaltung zwischen beiden 50HZ Timings grundsaetzlich funktioniert, muessen wir wohl doch die Oszillator-Methode von Oliver nehmen. Hier kann man die Timingaenderung so langsam vornehmen, dass der Betrachter es nicht bemerkt.

Nachfolgend noch meine aktuellen Patches, einer fuer das Radeon-DRM Kernel Modul. Der andere fuer das Radeon Xserver DDX Modul

so, eine weitere Idee:

1. das Timing der GraKa lasse ich unveraendert (ist also bei ca. 50.01HZ)
2. den Basistakt, den ich xine-lib gebe, habe ich jetzt testweise mal mit den VBLANKs der Grafikkarte synchronisiert. Patch siehe Anhang. Auf diese Weise driftet die Zeitbasis von xine nicht mehr gegen dieVBLANK- Synchronisation der GraKa.

Fuer das Abspielen von Aufzeichnungen (bzw. Timeshift) liefert dieses Verfahren bislang die besten Ergebnisse. Waehrend meiner Tests traten ueberhaupt keine sichtbaren Stoerungen in Bild oder Ton mehr auf.

Live-TV habe ich noch nicht damit getestet.

Fuer produktiven Einsatz ist es jedoch noch nicht geeignet. Z.B. muesste noch dafuer gesorgt werden, dass einmalig bei der Erst-Initialisierung die XvShmPutImage() Calls in die Mitte 2er VBLANKs fallen. Das ergibt dann die beste Stoersicherheit bei Schwankungen.

Zitat

Original von sparkie

kleiner Zwischenbericht:

ich bin jetzt soweit, dass kurz bevor die DoubleBuffer in der GraKa umgeschalten werden, im Xserver kontrolliert wird, ob fuer die kommenden Fields die schnelle oder langsame 50Hz Modeline programmiert werden soll.

Das funktioniert schon super d.h. ich habe keinen einzigen Halbbildverlust mehr, da im Mittel tatsaechlich exakt 50HZ gefahren werden! Eine erste Zwischenetappe ist also erreicht.

Aber:
Es ist IMHO nicht moeglich, zwischen beiden Modelines hin und herzuschalten ohne minimale (aber sichtbare) Stoerung auf dem Roehren-TV. Das Bild zuckt dabei kurz nach oben, und laeuft bis zum naechsten Modeline-Umschalten stabil weiter.

Ist ja auch klar: die Vertikalsteuerung der Ablenkelektronik wird ja schlagartig mit (minimal) geaendertem Vertikaltiming konfrontiert.

Alles anzeigen

Hm, irgendwie bezweifle ich, daß ein TV da so empfindlich ist. Evtl. wird der Synchronimpuls bei der Umschaltung abgeschaltet? Sollte man sich mal mit einem Oszilloskop ansehen.

Die Umschaltung passiert ganz sicher während der vertikalen Austastlücke?

CU
Oliver

Zitat

Originally posted by UFO
Hm, irgendwie bezweifle ich, daß ein TV da so empfindlich ist. Evtl. wird der Synchronimpuls bei der Umschaltung abgeschaltet? Sollte man sich mal mit einem Oszilloskop ansehen.

also beim '50Hz-Umschaltverfahren' benutze ich zwei '50Hz' Modelines, die sich genau um die Anzahl 2er vertikaler Zeilen unterscheiden. Dabei ist die eine Modeline minimal schneller als 50Hz (ca. 50.01Hz) , die andere langsamer (ca. 49.99Hz).

Ich weiss beim Umschalten durch meinen DRM ioctl() genau, wie lange die letzte Austastluecke entfernt war. So kann ich testweise die Registerprogrammierung (nur ein Zugriff) ueber den gesamten Bereich (von Austastluecke zu Austastluecke) wandern lassen. Die kurze Stoerung sieht, egal wann ich den Zugriff mache, immer gleich aus:

dabei springt das Bild ein paar Zeilen (vielleicht 4) nach oben und wandert dann sofort in gleichmaessiger Bewegung an die urspruengliche Lage zurueck. Der Vorgang dauert vielleicht 0.2 Sekunden. Es gibt praktisch keine Zufaelligkeiten. Der Ablauf ist immer gleich.

Es ist, als wenn die Ablenk-Elektronik auf den Bild-Frequenzsprung von ca 0.02Hz eben so reagiert.

Ich habe schon alle moeglichen Modeline-Varianten durchgespielt, die 2 vertikalen Zeilen auf die Luecke selbst oder auf den (unsichtbaren) Bereich davor oder danach zu legen. Macht alles keinen Unterschied.

Dabei ist aber eine Beobachtung sehr interessant: Die Stoerung tritt ausschliesslich beim Uebergang 49.99 -> 50.01Hz auf. Also wenn der Abstand der Vertikalsynchronpulse verkuerzt wird.

Die umgekehrte Richtung ist vollkommen stoerfrei! Was will uns das besagen?

Wir sind so nahe dran! Wenn es klappen wuerde, waere das sagenhaft, da dann endlich auch bei Grafikkarten - Budgetsystemen die leidigen (De)Interlace Probleme vom Tisch waeren.
Zudem idled mein 2Ghz Celeron, wenn er nur dekodieren muss, mit ca. 80% vor sich hin. Es duerften sich also auch sehr viel langsamere Prozessoren fuer das Verfahren eignen.

Ich werde bei Gelegenheit mal versuchen mir den Signalverlauf mit meinem betagten HW-204 Hameg anzuschauen.

Hi,

@ sparkie:

Klasse, was für "Grundlagenforschung" du hier betreibst!!!

...hast du diesen Zeilensprung auch auf anderen Monitoren (ev. über DVI?) ... vielleicht ist das Verhalten da ein wenig anders?

Grüße
Funzt

Zitat

Originally posted by Funzt

Klasse, was für "Grundlagenforschung" du hier betreibst!!!

oh danke. Was mich nur immer wieder verwundert, dass das nicht schon laengst jemand gemacht hat:)

Wenn man nur einen Bruchteil des Aufwandes, den man bislang fuer die FF-Hardware Mods investiert hat, in die Grafikkarten-Variante gesteckt haette, dann wuerde es heute sicher schon eine perfekte Interlaced-RGB-PAL Loesung fuer Budget-Grafikkarten-Systeme geben. Zum Bruchteil der Kosten eines FF basierten VDRs. Und dazu noch alles Open-Source, also ohne obskure FF-Firmware.

Zitat

...hast du diesen Zeilensprung auch auf anderen Monitoren (ev. über DVI?) ... vielleicht ist das Verhalten da ein wenig anders?

da muss ich noch einiges testen. Ich wollte erst mal ausschliessen, dass ich irgendeinen dummen Fehler gemacht habe. Ich werde bei der Gelegenheit auch andere Roehren-TVs unter die Lupe nehmen.

Dummerweise muss ich aber ab und zu auch was fuer meinen echten Job tun:D
Deshalb komm' ich vermutlich erst am Wochenende dazu...

so - der Durchbruch ist geschafft!

den Inhalt dieses Posts habe ich mal in einen neuen Thread verschoben, da es mit dem hier behandelten Thema nicht mehr so ganz viel zu tun hat:

neuer Thread:
RGB/PAL ueber VGA mit variabler Framerate

Das klingt alles super interessant. Habe mal fürs Wochenende angesetzt eine ati graka in die activy einzubauen und das zu testen. Betrifft das eigentlich nur DVI oder auch VGA? Also wird jetzt praktisch mehr mals pro Sekunde die Ausgabe Frequenz an den Fernseher geändert wenn ich das so richtig sehe. Kanns denn nicht sein, dass manche TVs damit Probleme bekommen?

Zitat

Originally posted by dortje
Betrifft das eigentlich nur DVI oder auch VGA?

Es betrifft in erster Linie RGB ueber VGA mit einem speziellen Kabel.

Betrieb ueber DVI-I ist auch moeglich , da hier die VGA Signale zur Verfuegung stehen. Meine aktuellen Tests mache ich mit IGP9100 Radeon-Chipsatzgrafik.

In diesem Post sind kompatible Karten aufgefuehrt.

Zitat

Also wird jetzt praktisch mehr mals pro Sekunde die Ausgabe Frequenz an den Fernseher geändert wenn ich das so richtig sehe. Kanns denn nicht sein, dass manche TVs damit Probleme bekommen?

Im Prinzip erfolgt die Kontrolle sogar 50 x in der Sekunde. Die Frequenz Korrekturen sind dabei aber so klein, dass sie leicht innerhalb der Spezifikationen liegen. EIne FF-Karte macht es uebrigens genauso.

Hi sparkie,

KLASSE, danke und Hut ab!
Mann - es gibt hier im Forum wirklich fähige Leute !!!

Grüße
Funzt

Hi Funzt,

danke, danke

ich denke wir sollten in diesem Thread

[patch] RGB/PAL ueber VGA mit variabler Framerate

weitermachen - um das Thema nicht endgueltig zu verfehlen:)

-sparkie

Hallo,

Zitat

Original von sparkie
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.

Alles anzeigen

Bedeutet das, dass die Verwendung von vdr-sxfe (das meinst du doch mit 'remote' frontend, oder?) nicht empfehlenswert ist?

Gruß,
Hendrik

Hallo henfri

Zitat

Originally posted by henfri
Bedeutet das, dass die Verwendung von vdr-sxfe (das meinst du doch mit 'remote' frontend, oder?) nicht empfehlenswert ist?

die Aussage stammt vom April letzten Jahres. Es hat sich seit da in der kompletten Software jede Menge geaendert. Es war auch nur eine persoenliche Erfahrung mit meinem ganz speziellen Equipment, deren Ursache ich damals nicht weiter nachgegangen bin.

Daraus kann man sicher keine allgemeingueltigen Empfehlungen ableiten.

- sparkie