Dreamboard

Sehr schön! Somit hat man das nun auch bewiesen und belegt.
Nochmals besten Dank!

Ich werde dies ebenfalls direkt bei DMM kundtun.

Ich habe nun noch einmal das Thema RGB und CVBS aufgegriffen.

Wenn ich die Werte 2f/26f für die vertikale Lage wähle, sitzt das Bild bei RGB schön mittig. Schalte ich auf CVBS um, wandert das Bild um 2 Zeilen nach unten und sitzt diese 2 Zeilen zu tief.
Wenn ich die Werte 2d/26d für die vertikale Lage wähle, sitzt das bild bei CVBS schön mittig, bei RGB jedoch 2 Zeilen zu hoch.
Das Bild sitzt aber mit beiden oben genannten Varianten weit exakter als mit der Standardeinstellung.

Jetzt stellt sich die Frage, welcher Modus als Referenz herangezogen werden kann. Warum die beiden Modi 2 Zeilen untereinander verschoben sind, kann ich mir auch nicht erklären.

Adenin, was auch noch sehr sehr interessant wäre, wären diese Oszillator Anzeigen/Werte von anderen Receivern, die das Bild standardmäßig mittig ausgeben. Ist es eigenlich so, dass das Bild bei Zeile 23 und nicht bei Zeile 15 beginnen soll? Meines Wissens befindet sich in Zeile 23 immer die PAL Plus Kennung. Der Wert ist also somit "magisch". :]

Quoted

Originally posted by tmbinc
Also, das Problem ist, dass intern erstmal YUV erzeugt wird, und dass dann im Ausgabepfad einmal nach CVBS und einmal nach RGB gewandelt wird - *nach* allem Scaling etc.

Interessant, interessant. Ist zwar Offtopic, aber hat man somit eigentlich die möglichkeit YUV über Scart auszugeben? Wenn ich mir einen Scart > YUV Adapter zusammenlöte wäre das doch ein schöner Qualitätssprung.

Quoted

Originally posted by tmbinc
Dabei hat CVBS eine Latenzzeit durch den Kammfilter, scheinbar von zwei Zeilen. Ich werd nochmal einmal schauen, ob es möglich ist, RGB entsprechend zu verzögern, Solange nehmt bitte erstmal CVBS als referenz.

Ahaaaa. Wenn das ginge, ist das natürlich der Hammer! Dann würde ich auch vorschlagen, wir einigen uns nun auf CVBS als Referenz und du hämmerst uns einen Treiber mit verzögerter RGB Ausgabe runter. Danach hätte sich das Thema CVBS vs RGB ja erledigt.

Quoted

Originally posted by tmbinc
Könnt ihr euch auf pal_*_{start,end}-Werte einigen? Die vertikale Einheit sind einfach Zeilen, die Horizontale waren irgendwie 4*Farbträgerfrequenz. Ich kann das gerne in die Treiber entsprechend einbauen. Ich bräuchte nur Werte, die erwiesenermaßen korrekter als die aktuellen sind.

Einigen ist gut. Wenn es stimmt, was adenin sagt, dann sind es bei CVBS 8 Zeilen nach unten (pal_v_start: 2f, pal_v_end: 26f) und sollte auch so konfiguriert werden. Ein Oszi ist tausendmal aussagekräftiger als jeder Referenzmonitor.
Ich kann nur soviel sagen, dass bei CVBS Ausgabe bei mir die Werte pal_v_start: 2d, pal_v_end: 26d (das wären 6 Zeilen nach unten) und bei RGB Ausgabe die Werte pal_v_start: 2f, pal_v_end 26f (8 Zeilen nach unten) mittig sitzen. Das kann aber an meinem Plasma liegen.
Die h Werte kann ich schlecht beurteilen, da es mein Plasma anscheinend mag, das Bild bei wärmerem Panel etwas nach links zu verschieben. Ich denke aber, dass die Standardwerte gut zum Usus passen.

Quoted

Originally posted by Rafiki
ITU-R BT.470-5

Was sagt diese ITU Norm? Man muss sich dort registrieren um das Dokument zu erhalten.

Quoted

Originally posted by adenin
Hallo tmbinc,
ich werde heute Abend die Werte für die richtigen Zeilenpositionen und Zeilendauer ausprobieren. Das Hauptproblem liegt aber im Verhalten des jeweiligen Monitors. Ist doch toll, das man es über die Parameter korregieren kann.

Ich finde es auch toll, dass man das parametrieren kann. Das sollte man unbedingt beibehalten.
Über exakte Werte anhand deines Oszis würden wir uns alle freuen. :]
Könntest du auch noch einen Kanal der RGB Ausgabe testen? Das wäre auch noch interessant zu sehen, wie sich RGB genau verhält und wo der Bildbeginn sitzt und ob es tatsächlich 2 Zeilen sind.

Quoted

Originally posted by Nico 77
ja geht, muss im Image aber mit 'config.av.yuvenabled = ConfigBoolean(default=true)' aktiviert werden in '/usr/lib/enigma2/python/Components/AVSwitch.py'.

Danke! Coole Sache.
Und auf welchen Pins wird dieses Signal ausgegeben? An den RGB Pins? Welcher Pin ist dann die Luminanz (Y) und welche beiden die Chrominanz (UV)?

So, ich habe nun auch den Komponenten Modus getestet und leider keine signifikanten Verbesserungen der Bildqualität auf meinem TV feststellen können, eher im Gegenteil.

Interessant ist jedoch, dass das Bild über YPbPr mit den Standardwerten (pal_v_start: 27, pal_v_end: 267) mittig sitzt.

Sehr eigenartig. Warum sitzt das Bild dann auf meinem TV mit anderen Receivern deutlich tiefer? Mit anderen meine ich immerhin 4 Receiver unterschiedlicher Hersteller.

Könntest du das Bild eines anderen Receivers ebenso mit dem Oszi ausmessen? Sind die Werte bei diesen gleich?

Was wären das für Testsignale? Was mir da spontan einfällt ist der Teletext, den man ja im Menü auf intern und extern schalten kann. Mit der Einstellung extern wird der Teletext des DVB Signales im analogen Signal an den TV mitübertragen. Eventuell sitzt bei Zeile 15 der Teletext?

Quoted

Originally posted by adenin
Ich hab erstmal aber einen anderen "Bug" entdeckt.
es bleiben "Rückstände" des Videotextsignals der vorherigen Sender in der Austastlücke.

Ha! Jetzt weiß ich warum bei Sendern ohne Teletext der Teletext des zuvor betrachteten Senders erscheint.

Führt dieses Phantomsignal (was auch immer das ist - weiß wer was das ist?) eventuell dazu, dass moderne Bildschirme annehmen, dass bereits hier das Bild beginnt und so das Bild versetzt darstellen?

Ich werd' daraus nicht schlau. Wenn das Problem mit dem Bildversatz nicht am TV liegt, warum ist das Bild dann derart verschoben? Kann mir das jemand erklären?

Um die Dreambox als Übeltäter zu disqualifizieren, wäre wohl der Weisheit letzter Schluss, einen anderen oder besser mehrere andere Receiver mit dem Oszi auszumessen und die Werte mit der Dreambox zu vergleichen.

Ich glaube ja anhand meiner Erfahrungen mit anderen Receivern der letzten Woche noch immer, dass die Dreambox schuld ist. Warum sonst wäre das Bild nur mit der Dreambox verschoben.

Adenin, hast du andere Receiver die du mal ausmessen könntest?

Ok, die zwei Zeilen machen das Kraut nicht fett, womit ich auch sehr gut leben kann. Da ist halt mein Monitor schuld. Wenn es keine Auswirkungen auf andere Geräte hat, wäre mir der Fix mit dem Delay jedoch nicht unrecht.

Womit ich jedoch nicht leben kann ist der generelle Versatz. Bist du hier anhand deiner Messungen schon weitergekommen? Was wären denn nun die Idealwerte? Warum ist der Versatz mit dem Oszi nicht erklärbar? Den Versatz siehst du doch auch, oder?