@TripleDES: Das Sagem-Flimmern is back
-
- Interessierter
- Beiträge: 36
- Registriert: Montag 17. September 2001, 00:00
@TripleDES: Das Sagem-Flimmern is back
Ich habe gerade das frische alexW-Image geflashed
(das von ca. 23.30 UHR - Sonntag 24.02.).
Und siehe da - das Sagem Farbflimmern ist zurueck
alexW sagt, dass sei experimenteller Code von Dir, der
noch nicht im CVS ist.
...
(das von ca. 23.30 UHR - Sonntag 24.02.).
Und siehe da - das Sagem Farbflimmern ist zurueck
alexW sagt, dass sei experimenteller Code von Dir, der
noch nicht im CVS ist.
...
-
- Neugieriger
- Beiträge: 3
- Registriert: Freitag 4. Januar 2002, 12:21
-
- Einsteiger
- Beiträge: 140
- Registriert: Montag 14. Januar 2002, 23:14
sacht mal, hab Ihr nicht gelesen? Das steht Doch genauso auf seiner Seite.
Zap-Bug gefixed, aber es könnte noch Propleme geben...
:
Zap-Bug gefixed, aber es könnte noch Propleme geben...
:
skullmonkeyENX Update. Umschaltbug ist nun behoben und es wird wesentlich schneller gesynct. Der Dank geht dafuer an TripleDES :)
Achtung: Wer eine Box mit Farbflimmer-Probleme hat, hat sie mit diesen Treibern momentan wieder. In dem Falle bitte noch warten.
-
- Senior Member
- Beiträge: 85
- Registriert: Samstag 21. Juli 2001, 00:00
-
- Interessierter
- Beiträge: 36
- Registriert: Montag 17. September 2001, 00:00
Scherzkeks.skullmonkey911 hat geschrieben:sacht mal, hab Ihr nicht gelesen? Das steht Doch genauso auf seiner Seite.Achtung: Wer eine Box mit Farbflimmer-Probleme hat, hat sie mit diesen Treibern momentan wieder. In dem Falle bitte noch warten.
Das steht IIRC erst im Readme, seit ich alexW gemeldet habe, dass es nicht mehr geht
(zumindest stand es nicht im Readme, als ich das Update gemacht habe.
-
- Developer
- Beiträge: 631
- Registriert: Donnerstag 24. Januar 2002, 12:21
-
- Einsteiger
- Beiträge: 140
- Registriert: Montag 14. Januar 2002, 23:14
-
- Senior Member
- Beiträge: 1544
- Registriert: Freitag 12. Oktober 2001, 00:00
-
- Interessierter
- Beiträge: 36
- Registriert: Montag 17. September 2001, 00:00
-
- Senior Member
- Beiträge: 1544
- Registriert: Freitag 12. Oktober 2001, 00:00
-
- Developer
- Beiträge: 821
- Registriert: Freitag 20. Juli 2001, 00:00
ok, nochmal für alle:
der farbflimmer bug muss mal GEFIXT werden. ein work around hat keine chance ins CVS zu kommen, weil es DA PROBLEME gibt, die nicht sofort offentsichtlich sind (PCR läuft aus dem lot und wird nicht mehr eingefangen, folge ist sync-verlust oder kompletter avia-crash).
die pcr-recovery muss sich mal jemand ansehen, der das auch fixen will. einfach nur den multiplier da veränder is nicht. das fixt zwar das farbflimmer, aber nicht das problem.
ok folgendes problem:
wir haben einen quarz, der mit 27Mhz läuft. mit diesen 27Mhz wird die lokale PCR (ein timestamp) hochgezählt, der für die synchronisation verantwortlich ist.
Im stream selbst gibts dann referenzen (DTS, PTS) auf die PCR.
allerdings läuft nicht jeder quarz genau. und wenn jetzt bei jemandem, z.b. durch wärme, das teil nen bisschen langsamer läuft, läuft der halt voll aus dem lot. die folge wäre, dass sich immer mehr daten in den queues sammeln, weil der avia ja denkt, es wäre noch nicht so weit die anzuzeigen. der sender ist allerdings schon der meinung, und schmeisst die daten mit den PTS-werten raus, die für den avia noch in weiter ferne liegen.
aus diesem grund wird immer mal wieder ein aktueller PCR-wert mitgesendet. die soft ist nun dafür verantwortlich, einmal den PCR wert in den GTX/eNX zu schreiben, und dann dafür zu sorgen, dass der gleich schnell läuft. dafür kann man die speed vom quarz leicht anpassen. man kann die spannung etwas vergrössern und verkleinern (-32768..32767). Man muss also die PCR-differenz zwischen empfangenem (stream) PCR und lokaler "quarz" pcr errechnen, und dann die output voltage vom PWM (pulse width modulation) dementsprechend anpassen (also diesen wert von -32k bis +32k setzen), in der hoffnung, der quarz wird jetzt schnell/langsamer so dass die PCR wieder erreicht wird.
man muss der vorgegebenen pcr also folgen, und so ein algorithmus sollte sich quasi "einpendeln", so dass im grunde nur noch minimale änderungen notwendig sind.
so, das problem ist nun aber noch folgendes:
damit alles wirklich syncron läuft, hängt der PAL-encoder (saa7206 ääh 7126 .. warum heissen die nur alle so ähnlich ebenfalls an diesem quarz. der palencoder macht ja das gesamte timing für den video-output. Wenn diese 27mhz also zu stark "springen" (und bei der aktuellen methode im gen-dmx springt der doch ziemlich stark , dann läuft das pal-encoding nicht mehr sauber ab, die folge ist das farbflimmern.
KANN DAS MAL JEMAND FIXEN
der farbflimmer bug muss mal GEFIXT werden. ein work around hat keine chance ins CVS zu kommen, weil es DA PROBLEME gibt, die nicht sofort offentsichtlich sind (PCR läuft aus dem lot und wird nicht mehr eingefangen, folge ist sync-verlust oder kompletter avia-crash).
die pcr-recovery muss sich mal jemand ansehen, der das auch fixen will. einfach nur den multiplier da veränder is nicht. das fixt zwar das farbflimmer, aber nicht das problem.
ok folgendes problem:
wir haben einen quarz, der mit 27Mhz läuft. mit diesen 27Mhz wird die lokale PCR (ein timestamp) hochgezählt, der für die synchronisation verantwortlich ist.
Im stream selbst gibts dann referenzen (DTS, PTS) auf die PCR.
allerdings läuft nicht jeder quarz genau. und wenn jetzt bei jemandem, z.b. durch wärme, das teil nen bisschen langsamer läuft, läuft der halt voll aus dem lot. die folge wäre, dass sich immer mehr daten in den queues sammeln, weil der avia ja denkt, es wäre noch nicht so weit die anzuzeigen. der sender ist allerdings schon der meinung, und schmeisst die daten mit den PTS-werten raus, die für den avia noch in weiter ferne liegen.
aus diesem grund wird immer mal wieder ein aktueller PCR-wert mitgesendet. die soft ist nun dafür verantwortlich, einmal den PCR wert in den GTX/eNX zu schreiben, und dann dafür zu sorgen, dass der gleich schnell läuft. dafür kann man die speed vom quarz leicht anpassen. man kann die spannung etwas vergrössern und verkleinern (-32768..32767). Man muss also die PCR-differenz zwischen empfangenem (stream) PCR und lokaler "quarz" pcr errechnen, und dann die output voltage vom PWM (pulse width modulation) dementsprechend anpassen (also diesen wert von -32k bis +32k setzen), in der hoffnung, der quarz wird jetzt schnell/langsamer so dass die PCR wieder erreicht wird.
man muss der vorgegebenen pcr also folgen, und so ein algorithmus sollte sich quasi "einpendeln", so dass im grunde nur noch minimale änderungen notwendig sind.
so, das problem ist nun aber noch folgendes:
damit alles wirklich syncron läuft, hängt der PAL-encoder (saa7206 ääh 7126 .. warum heissen die nur alle so ähnlich ebenfalls an diesem quarz. der palencoder macht ja das gesamte timing für den video-output. Wenn diese 27mhz also zu stark "springen" (und bei der aktuellen methode im gen-dmx springt der doch ziemlich stark , dann läuft das pal-encoding nicht mehr sauber ab, die folge ist das farbflimmern.
KANN DAS MAL JEMAND FIXEN
-
- Developer
- Beiträge: 631
- Registriert: Donnerstag 24. Januar 2002, 12:21
Danke tmbinc fuer die ausfuehrliche Erklaerung :)
Hat dieser Bug irgendwas mit http://tuxbox.berlios.de/forum/viewtopic.php?p=26191 zu tun?
bye alexW
Hat dieser Bug irgendwas mit http://tuxbox.berlios.de/forum/viewtopic.php?p=26191 zu tun?
bye alexW
-
- Senior Member
- Beiträge: 1544
- Registriert: Freitag 12. Oktober 2001, 00:00
Für alle, die das zucken im 1.6er alexW betrifft gibts da, netterweise von alexW kompiliert, den Fix.
http://www.chatlogin.com/dbox2/chkdesig ... type=Tools
http://www.chatlogin.com/dbox2/chkdesig ... type=Tools
tmbinc hat geschrieben:KANN DAS MAL JEMAND FIXEN