Vertikaler Bildversatz

  • zu beginn noch mal danke an alle, die versucht haben, die bioldlage zu korrigieren. so wie es jetzt im treiber enthalten ist, ist es schon gut. nun sollte ggf. noch ein endgültiges feintunig in richtung der letzten werte von dandjo (2d/26d) stattfinden und dann dürfte das bild doch bei der mehrzahl der nutzer passen.
    ich vertrete sowieso die theorie, dass nur ein paar geeks ein bildlageproblem haben. :grinning_squinting_face:
    für meinen teil habe ich die letztgenannten werte im startskript und bin dankbar.
    Regloh

  • Siehe Seite 3 in diesem Thread.


    Seite 3, Vertikaler Bildversatz


    Hier auch noch einmal komplett mit den neuen (auch horizontalen) Werten.


    Code
    cd /etc/init.d/
    touch video_adjust_script.sh
    chmod 755 video_adjust_script.sh
    echo "echo 2d > /proc/stb/video/pal_v_start" > video_adjust_script.sh
    echo "echo 26d > /proc/stb/video/pal_v_end" >> video_adjust_script.sh
    echo "echo 21e > /proc/stb/video/pal_h_start" >> video_adjust_script.sh
    echo "echo d27 > /proc/stb/video/pal_h_end" >> video_adjust_script.sh
    cd /etc/rcS.d/
    ln -s ../init.d/video_adjust_script.sh S70video_adjust_script.sh

    3 Mal editiert, zuletzt von dandjo ()

  • Zitat

    Original von dandjo
    .... Der Scaler im Xilleon greift ohnehin, egal welche Werte man konfiguriert. Es wird ja nicht das digitale Bild gescalet, sondern einfach anhand der Werte in ein analoges Signal gewandelt. Es ist so gesehen wurscht, wie du die Werte gewichtest...


    Vom Sender kommen ein gewisse Anzahl von Zeilen und Pixel. Die D/A Wandler am Ausgang laufen üblicherweise pixelsynchron. Wäre ja schwachsinnig wenn nicht. Im Ausgabesignal, auch wenn's auf analog gewandelt wurde, sind genausoviel Pixel und Zeilen wie im Transportstream (Eigentlich ist's umgekehrt. Es werden genau _diese_ Anzahl von Zeilen übertragen, weil genausoviele in dem dafür vorgesehenen Bereich bei PAL dargestellt werden können. In der horizontalen hat man sich halt auf ein gemeinsames vielfaches geeinigt bei welchem man die vorgegebenen Bandbreite halbwegs rüberbringt). Wenn man nun ein Bild statt 1/1, scaliert weitergeben will, dann muß man also Zwischenwerte berechnen die mit dem Originalsignal nicht identisch sind (und auch Ränder beschneiden...). Die Wandler kann ich ja deswegen nicht dynamisch während der Zeile anders takten und eine andere Zeilenanzahl kann ich schon gar nicht ausgeben. Ein interpolierter Wert ist aber keine originalgetreue Information mehr. Am anschaulichsten ist dies bei einer scharfen Kante. Wenn ich da scaliere und interpoliere, wird irgendein Zwischenwert genommen und das Endergebnis ist, neben anderen Effekten, zumindest nicht mehr so scharf wie das Original.


    Korrigiere mich wenn ich da falsch liege, aber ich kann mir rein technisch nicht erklären, wie ich ohne Qualitätsverlust scalieren könnte. Zumindest nicht in Echtzeit mit der Rechenleistung in der Box. Und ich hab auch noch keinen Scaler gesehen der das könnte. Am besten im Consumerbereich machen das noch die 'besten' TVs. Auch deshalb sollte wenn schon, dann nur im TV gescaled werden. Allenfalls noch in einem mehrere k€ teuren Surround Verstärker. Aber nicht in einem SAT-Receiver.

  • Also ich kann dir nicht ganz folgen, aber habe das so verstanden.


    Aus den 576 Pixel des digitalen Bildes werden die sichtbaren 576 Zeilen des analogen Bildes (plus eben die Informationen in der vertikalen Austastlücke, also insgesamt 625 Zeilen). Wo man das digitale Bild mit den 576 Zeilen im analogen Signal vertikal platziert, ist, wie man in diesem Thread ja schön sieht, vom D/A Wandler abhängig. Vertikal kann, oder bessergesagt sollte man nicht skalieren, da es hierbei unumstößlich zu Artefakten auf Grund der Zeilensprungtechnik kommt. Sogar das Verschieben ist auf die Zeilenfolge in Zweierschritte begrenzt.


    Aus den 720 Pixel vertikal des digitalen Bildes entsteht ein analoges durchgängiges Zeilensignal mit einer bestimmten Dauer. Die Dauer der analogen Zeile ist mit der Bildfrequenz von 50 Hz auf 64 µs begrenzt. Diesen Wert kann man nicht ändern. Was man ändern kann ist, wie das digitale Bild mit den 720 Pixel auf dieser Zeile verteilt wird, sprich, wie stark jedes einzelne Pixel entzerrt wird und wo es sitzen soll. Die Pixel müssen so und so entzerrt werden um ein aspektrichtiges PAL Bild zu erzeugen (Stichwort Aspekt Ratio = PAR). Diese Entzerrung und Platzierung auf der Zeile passiert über die h-Werte in /proc/stb/video/.


    Deshalb ist es eigentlich wurscht, wie die Werte gewichtet sind. Natürlich, wenn man sie extrem verändert, gibt es auch da Artefakte, aber bei unseren minimalen Änderungen siehst du keinen Unterschied. Diese Platzierung im analogen Signal darf man keinesfalls mit einer digitalen Skalierung gleichsetzen.


    Das ist mein Verständnis.

  • Die DACs am Ausgang laufen eben NICHT Pixelsynchron. Das hat man vor ewigkeiten mal abgeschafft, als man DACs bauen wollte, die mehrere Normen können, ohne riesige, umschaltbare analoge Filter dahinter bauen zu müssen (ihr wisst schon, Aliasing und Oversampling usw.).


    Der DAC im Xilleon läuft daher immer mit einer (relativ) festen Rate, hat ein definierten digitales Filter (dessen koeffizienten man dann halt umschaltet), so dass das Signal am Ende dem Standard entspricht. Für die feste DAC-Rate gibts dann ein festes anloges Filter, um hier das Aliasing zu vermeiden. Durch die hohe Frequenz nach dem Oversampling kommts hier auch nicht auf Details draufan. Würde der DAC mit 13.5MHz laufen, wäre es schon enorm schwer, aliasing zu verhindern, und trotzdem die volle PAL-Bandbreite zu ermöglichen. Und mal eben ein anderes Format ausgeben wäre dann unmöglich.


    Bei PAL gibt es keine scharfen Kanten - das entspräche ja einer unendlichen Bandbreite, und man hätte eher einen Sender als einen PAL-Ausgang gebaut, und würde durch jede EMV-Prüfung fallen.


    In sofern wird jede Zeile auf diese ~3500 Pixel "aufgeblasen" (genauer: 12*Fsc, mit Fsc=4.43MHz subcarrier freq., danach wird nochmal hochskaliert um auf die DAC-Ausgabefrequenz zu kommen, die, meine ich, bei ~148.5MS/s liegt), und dann so am DAC ausgegeben. Woher sollte hier ein Qualitätsverlust kommen? Höchstens durch schlechte Oversampling-Filter, aber die sind schon sehr massiv. Ist ja im digitalen nicht weiter teuer. Das Argument "jede Bildbearbeitung verringert die Qualität" ist natürlich grundsätzlich nicht falsch. Aber eine simple Skalierung ist dann doch recht gut durchzuführen, auch in Echtzeit. Die Filter arbeiten mit ausreichender Genauigkeit (was bei 8bit Eingangsdaten ja auch nicht so DIE Kunst ist), und haben meist 10 Taps (der finale Filter, der die letztendlich ausgegebene Bandbreite begrenzt, noch mehr). Wesentlich mehr Qualität dürfte im analogen Kabeln und bei den ADCs verloren gehen, wo jedes Bit richtig Geld kostet.


    Wesentlich mehr Qualität geht ausserdem bei jeglicher Framerateanpassung verloren. Aber das ist ja nicht das Thema hier.

  • Ich habe das Bild nun auch noch mit einem No-Name Digitalreceiver verglichen. Bei diesem sieht man bei der RGB / CVBS Umschaltung auch den Versatz der 2 Zeilen nach oben und unten. Dieser Effekt ist also TV spezifisch.


    Das Bild sitzt jedoch sogar mit diesem Receiver bei CVBS mittig. 2d/26d und CVBS auf der Dreambox sitzen in diesem Fall optimal und so wie mit diesem Receiver.


    Bitte, tmbinc, nimm die neuen Werte. :smiling_face:

  • :frowning_face:
    tmbinc: Ich sehe gerade, die neuen h-Werte sind nicht in dem neuen Treiber. Vielleicht hast du das überlesen. Hier nochmal die letzten von mir als die "besten" herauskristallisierten Werte. Bitte auch noch die h-Werte anpassen. Danke!


    Code
    2d > /proc/stb/video/pal_v_start
    26d > /proc/stb/video/pal_v_end
    21e > /proc/stb/video/pal_h_start
    d27 > /proc/stb/video/pal_h_end


    Nachtrag: Ich würde dringend empfehlen die h-Werte noch anzupassen, da ich mit den 21c/d29 Werten bei manchen Sendungen horizontale Streifen sehen konnte, die mit den 21e/d27 Werten nicht auftreten.

    2 Mal editiert, zuletzt von dandjo ()

  • tmbinc: Auch ich sage vielen Dank für den neuen Treiber und die freundliche Unterstützung!


    @all: Wann und wo genau kommen diese Farbverschiebungen? Ich kann die nicht nachvollziehen?! (Gott sei Dank! :winking_face: )

    Best regards,


    it's not a trick, it's a Nick! :winking_face:

  • Zitat

    Original von tmbinc
    Die DACs am Ausgang laufen eben NICHT Pixelsynchron. Das hat man vor ewigkeiten mal abgeschafft, als man DACs bauen wollte, die mehrere Normen können, ohne riesige, umschaltbare analoge Filter dahinter bauen zu müssen (ihr wisst schon, Aliasing und Oversampling usw.).


    Bei mehrfach Oversampling ist das Filter aber kein Problem mehr. Vor allem, da ja auch der Pixelclock am Ausgang selbst zwischen 50/60Hz (PAL/NTSC) mit 13,5MHz gleich ist (ITU-601, 656). Die DACs können natürlich mit einem ganzzahligen vielfachen davon laufen, was ja das Prinzip von oversampling ist.


    Zitat

    Der DAC im Xilleon läuft daher immer mit einer (relativ) festen Rate, hat ein definierten digitales Filter (dessen koeffizienten man dann halt umschaltet), so dass das Signal am Ende dem Standard entspricht. Für die feste DAC-Rate gibts dann ein festes anloges Filter, um hier das Aliasing zu vermeiden. Durch die hohe Frequenz nach dem Oversampling kommts hier auch nicht auf Details draufan. Würde der DAC mit 13.5MHz laufen, wäre es schon enorm schwer, aliasing zu verhindern, und trotzdem die volle PAL-Bandbreite zu ermöglichen. Und mal eben ein anderes Format ausgeben wäre dann unmöglich.


    13,5MHz wäre heutzutage in der Tat nicht besonders klug, aber schon mit 4-fach Oversampling sollte es filtermäßig kein großer Aufwand mehr sein. Welches andere Format neben PAL und NTSC (SECAM ist ja vom Timing her gleich PAL B/G) sollte man noch ausgeben wollen?


    Zitat

    Bei PAL gibt es keine scharfen Kanten - das entspräche ja einer unendlichen Bandbreite, und man hätte eher einen Sender als einen PAL-Ausgang gebaut, und würde durch jede EMV-Prüfung fallen.


    Ja alles ist relativ und mit scharfer Kante bei PAL meinte ich natürlich, was sich grad mit 5MHz Bandbreite reproduzieren läßt. Deshalb haben wir ja 720 aktive Pixel pro Zeile, weil mehr im analogen Ausgangssignal eh nicht gehen würde. Ein Pixel weiß und das nächste schwarz meinte ich mit 'scharfer' Kante.


    Zitat

    In sofern wird jede Zeile auf diese ~3500 Pixel "aufgeblasen" (genauer: 12*Fsc, mit Fsc=4.43MHz subcarrier freq., danach wird nochmal hochskaliert um auf die DAC-Ausgabefrequenz zu kommen, die, meine ich, bei ~148.5MS/s liegt),


    Ah, jetzt wird's interessant. 148,5MHz = 11 x 13,5MHz. Also doch pixelsynchron mit 11fach oversampling (zumindest nehme ich mal an das die synchron laufen). Das mit den 3500 Pixel hab ich noch nirgends gefunden. Könntest du das noch mal genauer erklären? Ev. wo das in der Xilleon Spec. zu finden ist. Vielleicht 4 x 864?


    Zitat

    und dann so am DAC ausgegeben. Woher sollte hier ein Qualitätsverlust kommen? Höchstens durch schlechte Oversampling-Filter, aber die sind schon sehr massiv. Ist ja im digitalen nicht weiter teuer. Das Argument "jede Bildbearbeitung verringert die Qualität" ist natürlich grundsätzlich nicht falsch. Aber eine simple Skalierung ist dann doch recht gut durchzuführen, auch in Echtzeit. Die Filter arbeiten mit ausreichender Genauigkeit (was bei 8bit Eingangsdaten ja auch nicht so DIE Kunst ist), und haben meist 10 Taps (der finale Filter, der die letztendlich ausgegebene Bandbreite begrenzt, noch mehr). Wesentlich mehr Qualität dürfte im analogen Kabeln und bei den ADCs verloren gehen, wo jedes Bit richtig Geld kostet.


    Ich versuche es zu erklären - angenommen es wechseln im ankommenden Datenstrom immer weiße mit schwarzen Pixel, also ein senkrechtes Linienmuster mit 360 weißen und 360 schwarzen Linien. Wohlgemerkt perfekt vom Sender digital max. mögl. Auflösung (50Hz PAL, 864 Pixel pro Zeile davon 720 aktive/sichtbare). Wenn ich nun das Ausgabebild etwas aufzoome, indem ich z.B. von den 720 links und rechts 20 wegschneide und daraus wieder 720 mache (also die mittleren 680 Pixel formatfüllend), dann werden einige Linien nach wie vor scharf sein, aber in anderen Bereichen muß ich Mittelwerte zwischen den benachbarten Linien bilden. Und genau das macht der scaler wenn es sich nicht um ein ganzzahliges Vielfaches handelt. Im Bild sieht man dann ein Streifenmuster abwechselnd von ziemlich scharfen Bereichen wo sich's grad durch Rundung ausgeht, und dann wieder schwammig verwaschenen Bereichen wo eben das weiße bzw. schwarze Pixel in der Mitte des ausgegebenen liegen würde, und wo dann unterschiedliche Grautöne errechnet werden.


    Jetzt mag man einwenden, es gibt ja ohnehin kaum TVs mit 720 Pixel horizontaler Auflösung. Nun, das ist schon klar und der Fernseher muß ohnehin auf seine Panel Auflösung hochscalieren. Nur, das TV rechnet auch am Eingang mit 720 aktiven Pixel (ITU-....), und ein TV ist, oder besser gesagt sollte darauf optimiert sein, dieses scaling möglichst perfekt zu beherrschen. Der TV Hersteller weiß welches Panel er einsetzt und kann auf diese Werte optimieren. Jetzt mag es durchaus sein, daß viele TVs ohnehin keine guten scaler verbaut haben und man deshalb solche scaling Effekte in der Dreambox ohnehin nicht mehr sieht. Aber zweimal scaling Fehler sind mit Sicherheit schlechter als einmal scaling Fehler. Und ein guter scaler im TV hat nur dann eine Chance, wenn er möglichst gute, unverfälschte Signale vorgesetzt bekommt.


    Man kann natürlich der Meinung sein, der Xilleon scaler ist so super toll und besser als die meisten TV scaler. Für viel TVs kann das durchaus zutreffen. Aber zweimal scalen ist immer schlechter als nur einmal. Auch meine ich, die besseren TVs haben durchaus bessere scaler als das was ein Computerchiphersteller wie ATI in einem set top box chip wie den Xilleon einbauen kann.


    Das einem solche Effekte im Live-Bild nicht immer sofort ins Auge stechen müssen, ist auch klar. Aber wenn man weiß auf was man schaut, entsprechend kritische Bilder anschaut und eine Referenz hat, sieht man sowas.


    Nochmal zusammengefasst - meiner Meinung nach darf in einem Receiver nicht gescaled werden. Das muß der Fernseher machen und der kann das auch besser. Außerdem kriegen so auch die letzten verwegenen die noch auf einem analogen Röhren TVs oder einem richtig teuerem Röhrenbeamer schauen, das beste mögliche Analogsignal aus dem Receiver.

  • Es kommen ja nicht 864 Pixel pro Zeile daher sondern 720 passiv und 702 aktiv. Da wird ja nicht skaliert, sondern einfach die 720 Pixel in die 64 µs Zeilendauer analoggewandelt. Wenn man von diesen Umständen ausgeht, wo würde hier skaliert werden?