Vertikaler Bildversatz

    720 werden nicht auf 64µs gestreckt. 720 ist der aktive Bereich. Üblicherweise wird ein TV Bild mit 13,5MHz gesampled (oversampling mal vernachlässigt). Das ergibt bei dem bei uns üblichen B/G Standard (50Hz) 864 Pixel / Zeile, wovon 720 aktiv sind (CCIR, ITU...). Und genauso soll es auch wieder zusammengestellt werden. Das im digitalen Kanal die Austastlücke und front/back porch nicht mitübertragen wird ist klar. Daher 720.


    Wenn die Dreambox nur 702 aktive Pixel vom Eingangsstream bewertet, was durchaus sinnvoll sein kann wenn die Sender nicht den ganzen Bereich ausnützen, dann sollen auch diese 702 Pixel im 864 Pixel langen analogen Gesamtausgangssignal, 702/864 der Zeile einnehmen. Also genau 52µs. Dann braucht nicht gescaled werden und alles ist optimal, was ja mein Anliegen ist.


    Falsch wäre es diese 702 nun auf (die genormten) 720 oder irgendeinen anderen Wert im Ausgangssignal aufzublasen (oder zu shrinken weil das TV fälschlicherweise overscan macht). Denn dann hat man eben Scalierungsfehler. Auch wenn diese, wie tmbinc schon anmerkte, aufgrund des mehrfach oversamplings nicht mehr gar so grauslich aussehen wie früher. Aber schöner ist's doch ohne scaling :winking_face:

    Einmal editiert, zuletzt von Rafiki ()

    Berücksichtigst du bei deiner Überlegung auch die Aspektverzerrung? Die 720 Pixel sind ja gestaucht, sprich schmäler als hoch. Meiner Ansicht nach ist die horizontale Austastlücke mit vorderer und hinterer Schwarzschulter sehr wohl in diesen 720 Pixel vorhanden, oder ist das komplett falsch angedacht?


    Wenn ich deinen Gedankengang nun folge, dann müssten die 52 µs des analogen Signales (also ohne Austastlücke) mit 720 Pixel abgetastet werden um bei 64 µs auf 864 Pixel zu kommen, richtig?


    Wenn ich also so weiterdenke und das DVB-S Signal mit deinen 720x576 Pixel (im Optimalfall) hernehme und wieder auf die 52 µs analog wandle, passt alles. Die Berechnungen auf Seite 11 (Vertikaler Bildversatz) verdeutlichen aber, dass 702 Pixel auf die 52 µs gelegt werden und 720 auf die 64 µs.


    Wenn die Dreambox das wirklich falsch macht, machen es zig andere Markenhersteller auch falsch, was ich nicht ganz glauben kann.

    Zitat

    Original von dandjo
    Berücksichtigst du bei deiner Überlegung auch die Aspektverzerrung? Die 720 Pixel sind ja gestaucht, sprich schmäler als hoch. Meiner Ansicht nach ist die horizontale Austastlücke mit vorderer und hinterer Schwarzschulter sehr wohl in diesen 720 Pixel vorhanden, oder ist das komplett falsch angedacht?


    Bei 'Square Pixel' wären es 944 Pixel / Zeile bei 768 aktiven. Die Austastlücken werden ziemlich sicher nicht mitübertragen, wäre ja ein gewaltige Verschwendung.


    Zitat

    Wenn ich deinen Gedankengang nun folge, dann müssten die 52 µs des analogen Signales (also ohne Austastlücke) mit 720 Pixel abgetastet werden um bei 64 µs auf 864 Pixel zu kommen, richtig?


    Sorry, ich muß hier editieren - da passt was nicht zusammen. Wenn 864Pixel 64µs sind (laut CCIR 601), dann sind 720 aktive Pixel 53,3µs. Wahrscheinlich hat man bei der Festlegung der 720 schon etwas Reserve eingerechnet (aktiv im Analogen sind ja 52µs) weil eine so exakte Synchronisierung und Stabilität vor einigen Jahren noch nicht möglich war und man auf analogen TVs die exakt eingestellt sind und dann ev. um 0,5µs wegdriften, nicht einen störenden Balken auf der Seite haben wollte.


    Zitat

    Wenn ich also so weiterdenke und das DVB-S Signal mit deinen 720x576 Pixel (im Optimalfall) hernehme und wieder auf die 52 µs analog wandle, passt alles. Die Berechnungen auf Seite 11 (Vertikaler Bildversatz) verdeutlichen aber, dass 702 Pixel auf die 52 µs gelegt werden und 720 auf die 64 µs.


    Wenn 720 Pixel 64µs wären, dann wären 702 Pixel 62,4µs. So kann das nicht stimmen. Also 864 Pixel sind 64us, 720 Pixel sind 53,3333us und 702Pixel sind 52us.


    Zitat

    Wenn die Dreambox das wirklich falsch macht, machen es zig andere Markenhersteller auch falsch, was ich nicht ganz glauben kann.


    Ich glaub auch nicht, daß die Box das sooo falsch macht. Ich kann jetzt nicht die ganzen Berechnungen hier nachvollziehen, aber ich denke da liegt irgendwo ein Denkfehler oder Rechenfehler drinnen. Möglicherweise ist es aber auch so, daß ev. die Sender nicht immer (Programmabhängig?) die ganzen 720x576 auch wirklich ausnützen. Das ist jetzt aber nur eine Vermutung von mir. Das müßte man mal verifizieren, wenn man wirklich alle 720 Pixel vom Sender auch ausgibt und zwar innerhalb von 53,333333us. Dann könnte man das auch nachmessen und von anderen Effekten (overscan des TVs) auseinander halten.


    Ich sehe gerade, in der ITU-R BT.656-5 stehen auch die hier gesuchten Werte drinnen -
    Field blanking from Line 624 to 22 (inklusive) und 311-335. Macht zusammen 49 Zeilen --> insgesamt 576 aktive. Erste aktive ist demnach 23 und 336.

    Einmal editiert, zuletzt von Rafiki ()

    Zitat

    Originally posted by Rafiki
    Bei 'Square Pixel' wären es 944 Pixel / Zeile bei 768 aktiven. Die Austastlücken werden ziemlich sicher nicht mitübertragen, wäre ja ein gewaltige Verschwendung.


    Ok, überzeugt.


    Zitat

    Originally posted by Rafiki
    Sorry, ich muß hier editieren - da passt was nicht zusammen. Wenn 864Pixel 64µs sind (laut CCIR 601), dann sind 720 aktive Pixel 53,3µs. Wahrscheinlich hat man bei der Festlegung der 720 schon etwas Reserve eingerechnet (aktiv im Analogen sind ja 52µs) weil eine so exakte Synchronisierung und Stabilität vor einigen Jahren noch nicht möglich war und man auf analogen TVs die exakt eingestellt sind und dann ev. um 0,5µs wegdriften, nicht einen störenden Balken auf der Seite haben wollte.


    ...


    Wenn 720 Pixel 64µs wären, dann wären 702 Pixel 62,4µs. So kann das nicht stimmen. Also 864 Pixel sind 64us, 720 Pixel sind 53,3333us und 702Pixel sind 52us.


    Dann stimmt die Ausgabe. Wenn du dir anschaust, wie ein standardkonformes MPEG2 PAL daherkommt (wie z.B. vom ORF).
    Siehe http://www.dream-multimedia-tv…ent.php?attachmentid=1718
    Dieses MPEG2 enthält 702 aktive Pixel bei einer breite von 720 Pixel. Manche Sendeanstalten belegen die ganzen 720 Pixel, was meines Wissens jedoch nicht konform ist.


    Zitat

    Originally posted by Rafiki
    Ich glaub auch nicht, daß die Box das sooo falsch macht. Ich kann jetzt nicht die ganzen Berechnungen hier nachvollziehen, aber ich denke da liegt irgendwo ein Denkfehler oder Rechenfehler drinnen. Möglicherweise ist es aber auch so, daß ev. die Sender nicht immer (Programmabhängig?) die ganzen 720x576 auch wirklich ausnützen. Das ist jetzt aber nur eine Vermutung von mir.


    Tun sie auch nicht. Man sieht in 98% der Fälle einem MPEG2 Transportstrom links und rechts immer diese schmalen Balken, die je nach Bildinhalt sogar innerhalb der Sendungen selbst variieren. Das liegt einfach daran, wie die Kameras und die Chips das optische Bild abgreifen.


    Zitat

    Originally posted by Rafiki
    Das müßte man mal verifizieren, wenn man wirklich alle 720 Pixel vom Sender auch ausgibt und zwar innerhalb von 53,333333us. Dann könnte man das auch nachmessen und von anderen Effekten (overscan des TVs) auseinander halten.


    Mit den schmalen Balken links und rechts erhält man ja die 52 µs im analog gewandelten Signal wenn man die 720 Pixel auf die 53,333333 µs legt.


    Wenn wir von den ursprünglichen Werten 21a und d2b für pal_h_start und pal_h_end ausgehen, sind das horizontal 2833 Werte gewesen. Nehmen wir also weiter an, dass der Prozessor mit 53 MHz taktet kommen wir auf folgendes.


    Code
    2833 / 53 Mhz = 53,4528301

    Wenn 53,333333 µs 720 Pixel entsprechen, war der Wert schon nahe am Optimum. Absolutes Optimum wäre.


    Code
    53,333333 µs = X / 53 Mhz
X = 53,333333 µs * 53 MHz
X = 2826,666666

    Somit hätten wir für die 702 aktiv ausgenutzten Pixel im MPEG2 Transportstrom die 52 µs für das analoge Ausgabebild. Von dem her war meine Ursprüngliche Berechnung für die h-Werte falsch.


    Wenn wir die 2826,666666 Werte so nehmen und zurückrechnen kommen wir auf folgende Werte. Diese sind optimal, vorausgesetzt die Taktfrequenz mit 53 stimmt in etwa (zweite Kommastelle ist vernachlässigbar, die erste ist schon noch ausschlaggebend).


    Code
    2833 - 2826,666666 = 6,333333
6,333333 / 2 = 3,1666666 ~ 3
538 (0x21a) + 3 = 541
3371 (0xd2b) - 3 = 3368

    Daraus folgt.


    Code
    pal_h_start > 21d
pal_h_end > d28

    Ich werde die Werte mal heute Abend beobachten und berichten. Wenn sie passen, müssen sie eben noch ein mal angepasst werden im Treiber.


    Zitat

    Originally posted by Rafiki
    Ich sehe gerade, in der ITU-R BT.656-5 stehen auch die hier gesuchten Werte drinnen -
    Field blanking from Line 624 to 22 (inklusive) und 311-335. Macht zusammen 49 Zeilen --> insgesamt 576 aktive. Erste aktive ist demnach 23 und 336.


    Der Wert 2D für das derzeitige pal_v_start wäre bei Zeile 45.


    Code
    45 - 23 = 22

    Pal_h_start passt oder? Oder wie würdest du diese Norm auf unsere Werte umsetzen?


    tmbinc & Entwickler:
    Kann man die genaue Taktfrequenz mal eruieren und verifizieren? Dieser Faktor ist der entscheidendste, wenn man genau berechnen will.


    Update: Zwischen den Werten, die jetzt im Treiber sind und denen von mir hier neu berechneten, sieht man keinen Unterschied. Die feinen Linien in meinem Testbild sehen mit den hier berechneten Werten genauso aus wie mit den aktuellen Werten im Treiber.


    Wenn man berechnet, kann man den Unterschied auch nicht sehen. Das sind im Vergleich zum ursprünglichem Wert nur 2 Werte horizontal Unterschied.


    Code
    0xd27 - 0x21e = 0xb09 (2825) ... im aktuellen Treiber
0xd28 - 0x21d = 0xb0b (2827) ... hier berechnet


2825 / 53 MHz = 53,301887 µs

    Da ich die Werte d27/21e für geometrisch richtiger empfand (Referenzbilder), denke ich, dass die aktuellen schon passen. Zudem ändern die rein rechnerisch exakteren Werte kein Bischen am Bild. Wenn die Taktfrequenz des Prozessors auch nur um eine Kommastelle höher oder geringer ist, sind die Werte rechnerisch ohnehin wieder falsch. Ich würde mich also eher auf das Referenzbild berufen und die Werte so lassen, wie sie jetzt sind.

    3 Mal editiert, zuletzt von dandjo ()

    Einige grundlegende Dinge die mir fehlen -


    - 53MHz, woher kommen die? Sind's vielleicht 54MHz?
    - aufblasen auf ca. 3000Pixel im Xilleon (tmbinc) - sind das die Eingangspixel (720) mit einem ganzzahligen vielfachen hochgerechnet? Ich finde das im Xilleon Datenblatt nicht. Wenn nicht ganzzahlig, also mit was anderem als x4, dann erübrigt sich die ganze scaling Diskussion, weil ohnehin schon ganz am Anfang interpoliert/gefiltert wird.


    Zitat

    45 - 23 = 22


    Die Rechnung verstehe ich nicht. Ich nehme mal an, im Xilleon wird das ganze Bild mal in den Speicher geschrieben. Als interlaced Bild wie's vom Sender kommt. 720Pixel x 576 Zeilen auf ca. 3000 (?) 'aufgeblasen' mal wieviele Zeilen? Wird auch vertikal aufgeblasen?


    Wenn sich dann der PAL encoder das Bild aus dem Speicher holt, dann sollte er theoretisch bei Ausgangszeile 23 (336) beginnen Daten vom Speicher über die DACs rauszugeben. Wie passen da die 45 zusammen?


    Ich weiß nicht wie das Bild im Speicher liegt und auch nicht wie da die pal_x_xxx Werte reinpassen. Also bevor ich weiter spekuliere müßte ich da etwas mehr Ahnung von den Xilleon Interna haben....


    Was wir aber schon wissen, oder glauben zu wissen, ist, daß die Sender scheinbar nicht wirklich alle 720x576 Pixel mit sinnvollen Videoinformation befüllen. Wenn's horizontal weniger als 720 sind, wieviel sind's dann vertikal?

    Die 45 für pal_v_start sind logisch relativ einfach erklärbar.


    PAL besitzt 625 Zeilen, davon 576 aktive. Das erste aktive Halbbild beginnt bei Zeile 22,5 und endet bei Zeile 310. Jetzt folgt die vertikale Austastlücke mit ca. 25 Zeilen Dauer (22,5 Zeilen + horizontale Austastlücke). Das zweite Halbbild beginnt dann bei Zeile 336 und endet bei Zeile 623,5. Dann bleiben noch 1,5 Zeilen, die sich mit den 22,5 im ersten Halbbild wieder auf ungefähr 24 Zeilen Dauer addieren, die der Elektronenstrahl von rechts unten nach links oben benötigt. Das sind ungenaue Werte, da hier sehr viel Spiel möglich ist. Im Groben kann man sagen, dass die aktiven Inhalte beide Halbbilder, wenn man immer bei 0 (sprich von oben) startet, bei 22,5 Zeilen beginnen.


    Da sich die Werte im Treiber höchstwahrscheinlich auf Vollbilder beziehen, muss man die 22,5 Zeilen, die im ersten Halbbild in die vertikale Austastlücke fallen mal 2 nehmen, womit man auf die 45 (= 0x2d) kommt. Ob man nun bei 43 oder 47 beginnt, ist nur ein Rundungsfehler, 45 ist aber definitiv die goldene Mitte, die sich erwiesenermaßen auch in anderen Geräten so konfiguriert vorfindet.

    Hier noch ein paar Screenshots von einigen Sendern. Es ist wirklich kein eindeutiger Trend erkennbar. Manche nutzen die ganzen 720x576 Pixel aus, manche nutzen nur die 702x576 Pixel, manche überhaupt andere Bereiche.


    Was nun die Norm ist und welche Sender hier aus der Reihe tanzen, würde mich auch brennend interessieren. Im Endeffekt wird es aber darauf hinauslaufen, dass sich keiner wirklich daran hält und die Receiver dies ohnehin nicht 100%ig korrekt unterstützen können.


    Nachtrag: Ich habe mir das nun noch einmal angesehen. Alle Receiver und DVD Player, die ich habe, schneiden links uns rechts vom Bild genau diese 18 Pixel von den 720x576 Pixel weg, um die 702 aktiven zu erhalten. Auch MPEG Streamclip tut das, wenn man ein 4:3 oder 16:9 Bild als Still-Frame oder mit einem PAR von 1:1 exportiert. Das hat schon etwas auf sich. Es sieht ja nicht umsonst das Testbild von Burosch auf jedem von mir getesteten TV aus wie ein flach liegendes Ei. Erst wenn man es auf 702 Pixel Breite umrechnet, passt der Kreis. Dass das alle Geräte falsch machen, kann ich mir keinesfalls vorstellen. Sendern, die diese zusätzlichen 16 Pixel ausnutzen, muss es bewusst sein, dass man diese Pixel im normalen TV Betrieb ohnehin nie zu sehen bekommt. Zudem muss das PAR, obgleich man diese 16 Pixel ausnutzt oder nicht, auf 702 Pixel angepasst sein, sprich einen PAR von 768:702 besitzen.