Zitat

Originally posted by adenin
Mein Monitor ist ein TV und hat keinen Versatz. (hab ich doch schon 1 bis 5 mal geschreiben)

Ok sorry, das habe ich dann anscheinend überlesen.

Ich würde es sinnvoller finden, nicht deine Dreambox an noch 15 Geräten zu testen, sondern einmal herzugehen und Receiver von Drittherstellern ebenso durchzumessen, wie du die Dreambox durchgemessen hast. Dann können wir endlich sagen, ob andere Receiver das Bild standardmäßig um diese 8 Zeilen verschieben und ob das bei 99% der Geräte so Usus ist, oder das Problem woanders gesucht werden muss. Wenn dieser Versatz nach unten tatsächlich üblich ist, sollte das auch die Dreambox so machen.

Wenn die Messwerte bei anderen Receivern genau die gleichen Ergebnisse liefern wie die Dreambox, kann man das Problem mit deinen Oszi Messwerten nicht beschreiben und muss woanders gesucht werden. Dass es hier Differenzen zu anderen Herstellern gibt, steht ja außer Frage.

Nichts desto trotz noch einmal danke für all deine Bemühungen.

Es ist mir ein Mysterium, warum manche Boxen das Problem anscheinend nicht haben und manche schon, obgleich tmbinc sagt, dass die Werte schon vor dem Release festgesetzt wurden. Woran kann das liegen? Ich glaube am ehesten, dass manche TV Geräte das Bild automatisch wieder dort hinsetzen wo es hinsoll.

Ich denke, dass der Bildversatz eher die Regel ist und die Leute, die nicht hier posten, einfach noch nicht Notiz vom Problem genommen haben, dieses Forum nicht kennen oder es einfach aus Gleichgültigkeit hinnehmen. Bevor ich diesen Thread gestartet habe, hat das Problem ja auch niemanden gejuckt.

Leider hat mir adenin noch immer nicht geantwortet, ob er ebenfalls den Versatz auf einem TV bemerkt. Das wäre sehr aufschlussreich. Bitte. =)

Hier noch die Bilder, einmal mit den originalen Werten (original.jpg) und mit meinen angepassten Werten (modified.jpg).

Die angepassten Werte:

pal_v_start: 0x2f
pal_v_end: 0x26f
pal_h_start: 0x22b
pal_h_end: 0xd23

Für die Kommandozeile:

echo 2f > /proc/stb/video/pal_v_start
echo 26f > /proc/stb/video/pal_v_end
echo 22b > /proc/stb/video/pal_h_start
echo d23 > /proc/stb/video/pal_h_end

Man sollte auch noch erklären, dass der von mir rot eingezeichnete Kreis exakt rund ist. Auf dem linken originalen Bild sieht man, dass das Bild zu breit ist und der ursprüngliche Kreis des Burosch Testbildes in die Breite gezogen ist (flach liegende Ellipse). Auf dem rechten modifizierten Bild ist der Kreis des Testbildes nahezu Rund. Ausgangswerte lieferten adenins Berechnungen. Ich habe das Bild zusätzlich etwas nach links verschoben, da mein Monitor das Bild anscheinend etwas nach rechts verschiebt (je nach Wärme des Panels). Ich weiß nicht, ob es tatsächlich am Monitor liegt, oder ob es generell weiter links sitzen sollte.

Tmbinc, darfst du uns verraten, welche 4 Werte für pal_* in der Tabelle von ATI stehen?

So, ich habe mir das mit der Zeilenfrequenz nun noch einmal reingezogen.

Ich habe aus dem Testbild der Burosch Test DVD einen Transportstrom erzeugt, auf die Festplatte kopiert, den MoviePlayer gestartet und den Transportstrom geladen. Nun habe ich den großen Kreis mittels eines Lineales vermessen und kam zum Ergebnis, dass der Kreis zu breit ist, also eine Ellipse darstellt.

Nun habe ich die Werte von adenins Berechnung (Vertikaler Bildversatz) genommen und anschließend noch einmal gemessen. Das Kreis ist nun bis auf einen halben Millimeter exakt rund. Das Bild ist also mit den Standard h Werten eindeutig zu breit.

Nachtrag: Das Bild ist mit adenins Werten auch etwas schärfer!

Achso, warte mal. Mir dämmert etwas.

PAL hat ja 625 Zeilen (davon 576 aktive für die Bildinformation). Das MPEG Bild hat ja nur diese 576 Zeilen (Pixel). Natürlich musst du, um dem analogen PAL Standard zu entsprechen, das Bild in einer zeitversetzten Zeile beginnen lassen (dass es unbedingt 23 sein muss, konnte ich noch nirgends finden, ich denke aber, das stimmt schon so), da die Zeilen darüber mit Metainformation befüllt werden können bzw dafür vorgesehen sind.

ATI wird mit den empfohlenen Werten davon ausgegangen sein, dass man das ohnehin macht. Du hast das - meine Vermutung - falsch interpretiert und demnach angepasst. Die 6 Zeilen, die nun zu hoch sind, kommen meinen Optimalwerten ja sehr nahe (ich habe momentan +8 Zeilen). Ich denke des Rätsels Lösung ist nicht mehr fern.

Hi tmbinc,

es freut mich wirklich sehr, dass sich hier nun auch die Experten und Entwickler einklinken. So soll ein sein! So kommen wir wesentlich früher zu einem Ergebnis und müssen nicht weiter spekulieren. Danke hierfür!

Ok, das mit der Zeilenfrequenz war Blödsinn, vergesst was ich geschrieben habe.

Warum du auf Grund des 1:1-Scalings den empfohlenen Wert von ATI auf 21 (0x15) verringert hast, kann ich - auf mein Verständnis bezogen - nicht ganz nachvollziehen.

Wenn du Zeile 1 des MPEG Bildes auf Zeile 23 des CVBS Bildes verschiebst und du, wie oben geschrieben, das Bild bei Zeile 21 starten lässt, müsste das Bild auf dem Oszi ja bei Zeile 44 beginnen (21 + 23), oder verstehe ich hier etwas falsch? Warum hast du die Zeile eigentlich verschoben?

Ich glaube das Oszi täuscht uns hier. Das Oszi zeigt uns an, wo der Bildinhalt (also das was wir tatsächlich sehen) beginnt. Da die Kameras und Filmabtaster jedoch ein Underscan zur eigentlichen PAL Auflösung erzeugen (sieht man sehr schön auf professionellen Monitoren mit Underscan Funktion), beginnt der tatsächliche Bildinhalt (auch wenn der Schwarz ist) ein paar Zeilen früher/höher). Das würde auch diese Phantomsignale erklären, die ja zu früh/hoch ausgegeben werden. Das ist nur eine Vermutung, würde aber das Problem erklären.

Irgendwie ist hier ein Hund im System. Mein Vorschlag wäre, die Empfehlungen von ATI zu übernehmen, einen Fix anzubieten und mal zu schauen, was er bewirkt.

Ich habe mir noch einmal die Zeilenfrequenz angesehen:

Die Werte für h sind dezimal ja 3371 und 538.

3371 - 538 / 4 = 708,25

Das aktive Bild von PAL soll jedoch 702 Spalten groß sein. Sehen wir mal wie wir das optimieren können.
Um auf 702 zu kommen wäre der richtige Ansatz

702 * 4 = 2808

Somit müssen wir sehen, wieviel wir wegnehmen müssen.

3371 - 538 = 2833
2833 - 2808 = 25
25 / 2 = 12,5

Wir müssen also die Werte links um 12 und rechts um 13 - oder umgekehrt - verringern.

3371 - 13 = 3358
538 - 12 = 526

Die Werte wären somit folgende.

pal_h_start: 0x20e
pal_h_end: 0xd1e

Ich werde das heute Abend mal verifizieren und testen.

Danke Leute.

Das waren nun immerhin Bestätigungen von vier Leuten. Hätte ich bloß ein Messgerät.

Adenin, versuche doch bitte mal die beiden CVBS Kanäle im CVBS und RGB Modus zu vergleichen. Eventuell gibt es da die Unterschiede. Eventuell auch mal die R und G Kanäle anhängen.

An euch vier: Habt ihr mit den Werten schon herumexperimentiert und die Idealwerte herauskristallisiert? Die Entwickler benötigen, soviel ich hier mitbekommen habe, eigentlich nur mehr Werte um diese standardmäßig implementieren zu können.

Ich kann die Werte auf meinem Monitor leider schlecht kalibrieren, da bei wärmer werdenden Panel das Bild etwas verrutscht (ungefähr 1 bis 2 Pixel). Dieses Verrutschen steht aber in keiner Relation zum Bildversatz den die Box produziert, der ist im Vergleich enorm.

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?

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?

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?

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?

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.

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

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.

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

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

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

Ich werde dies ebenfalls direkt bei DMM kundtun.

Zitat

Original von adenin
Ich mach heute abend von der DM500, DM600, Dm7020Si und DM7025 ein paar Fotos von der Austastlücke.

Danke!

Natürlich sollte das Bild standardmäßig mittig sein, aber ein Plugin hierfür wäre bestimmt kein Fehler (z.B. für schlecht kalibrierte TV Geräte).

Und was sagt dein Oszi bei anderen Receivern? Sind die Werte da ungefähr gleich?

Hm, ich habe nun einige Bekannte mit einer dm7025 befragt und sie gebeten mir die Werte durchzusagen. Die Standardwerte für die Bildposition sind eigentlich überall gleich. Eigenartig ist, dass manche das Problem nicht haben, sprich dass das Bild mittig sitzt. Da dürften wirklich die TV Geräte eingreifen und das korrigieren. Bilder von alten 4:3 Röhrenmonitoren sind ohnehin keine Vergleichsreferenzen.

Wurscht, wir wissen, dass das Bild falsch sitzt. Das bestätigt auch das Oszi.

Ein Plugin hierfür wäre echt nicht schlecht. Wenn schon die Möglichkeit besteht, das Bild zu verschieben, sollte das auch über das Menü zugängig gemacht werden!
Also liebe Burschen und Mädel bei DMM, bitte implementieren.