Vertikaler Bildversatz

    Dummerweise ist meine Knipskiste im Eimer, also hab ich's mal mit meinem Handy probiert (lasst die Finger vom HTC-P3300 wenn ihr Fotos machen wollt). Werd mir morgen erst mal 'nen neuen besorgen.


    Hier aber trotztem ein Versuch.
    Auf dem Foto ist der Beginn des ersten Halbbildes zu sehen.
    Ergebnis: das Bild beginnt mit dem original pal_v_start 8 Zeilen zu früh.
    [Edit ON]
    Nachträglich muss ich sagen (nach dem ich das weiter untersucht habe), das diese Aussage totaler Schwachsinn ist, weil das was da zu sehen ist, nicht der Bildinhalt ist, sondern Testsignale, die in der Austastlücke mitgesendet werden.
    Das Bild beginnt tätsächlich doch mit den originalen Parametern ab Zeile 23.
    beste Grüße
    adenin

    [Edit OFF]

    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". :]

    Das Bild sollte immer in Zeile 23 (in der zweiten Hälfte davon) beginnen (steht doch auch in Foto :winking_face: ).
    Das Foto ist im CVBS_Modus entstanden.

    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.


    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.


    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.

    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.


    beste Grüße
    adenin

    Einmal editiert, zuletzt von adenin ()

    Zitat

    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. :smiling_face:


    Zitat

    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. :smiling_face: 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.


    Zitat

    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. :winking_face: 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.


    Zitat

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


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


    Zitat

    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.

    Einmal editiert, zuletzt von dandjo ()

    Zitat

    Original von dandjo


    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. :smiling_face:


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

    Zitat

    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)?

    Einmal editiert, zuletzt von dandjo ()

    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.

    Ich hab mir das mit den Zeilen nochmal genau angesehen.
    Meine erste Aussage, das das Bild mit den original Parametern bei Zeile 15 beginnt ist falsch. Es beginnt tatsächlich bei Zeile 23, wie es auch sein soll. Was da ab Zeile 15 drin ist, sind irgendwelche Testsignale.
    Es liegt also eindeutig am Monitor, das das Bild verschoben ist.


    beste Grüße
    adenin

    Einmal editiert, zuletzt von adenin ()

    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?

    Zitat

    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?

    Zitat

    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?

    Nein, auf keinen Fall.


    Bei meinem Monitor gibt es keinen Unterschied zwischen CVBS, RGB und S-Video in der Bildposition.

    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?

    Einmal editiert, zuletzt von dandjo ()

    Es muss am Monitor liegen, weil für die Syncronisation das gleiche Signal, nähmlich das CVBS Signal verwendet wird. Im RGB Modus werden nur die drei Farbinformationen dann nicht aus dem CVBS-Signal genommen, sondern aus drei Extrasignalen. Aber wie ich schon zeigte CVBS und RGB sind synchron, so das der Versatz in deinem Monitor zustande kommen muss. Bei mir gibt es keinen unterschiedlichen Versatz zwischen den Modi.

    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?