ck's Blog

Schlagwort: Windows

  • Pixelige Videowiedergabe unter Aero.

    Seit wenigen Wochen verwende ich Windows 7. Dank des MSDN Academic Alliance Programms von Microsoft habe ich darauf bereits mehrere Wochen vor dem offiziellen Verkaufsstart Zugriff. Obwohl ich eigentlich mit dem zuvor bei mir installierten Windows Vista nicht unzufrieden war, wagte ich den Umstieg, da das neue Betriebssystem aus Redmond in der Fachpresse hoch gelobt wurde.

    Jedoch stellte sich sehr bald ein Problem bei der Wiedergabe von Videos ein, das bei jedem Medienplayer außer dem Windows Media Player und dem Windows Media Center auftrat. Clips wurden nur stark verpixelt angezeigt, was sich vor allem beim Abspielen von niedrig aufgelöstem Material im Vollbildmodus bemerkbar machte. Es wirkte, als sei jede Art von Weichzeichner bzw. Interpolation zur Vergrößerung deaktiviert.

    Folgender Screenshot soll das Problem verdeutlichen. Neben den für Videokompression typischen Kompressions- (durch das Streichen von Fourier- bzw. DCT-Koeffizienten) und Gibbs’schen Artefakten ist das Bild stark verpixelt, was besonders bei den blonden Haaren am Rand, den Augen und vor allem dem eingeblendeten Schriftzug deutlich wird. Ein Klick auf das Bild öffnet eine Vergrößerung, bei der das Problem besonders gut sichtbar wird.

    Nach ein wenig Recherche im World Wide Web bin ich darauf gestoßen, dass es sich anscheinend um ein Problem mit Aero handelt, der von Microsoft mit Windows Vista eingeführten grafischen Benutzerschnittstelle. Das hat mich einerseits gewundert, da ich unter Vista dieses Problem nicht hatte, würde allerdings erklären, warum sämtliche Player außer den obigen beiden dieses Phänomen produzierten.

    Letztendlich bekam ich die fehlerhafte Darstellung mit dem VLC Media Player in den Griff, da man mit ihm schnell die Ausgabeoptionen konfigurieren kann. Aber im Normalfall dürfte es auch jeder andere Medienplayer tun, der ähnliche Einstellmöglichkeiten bietet. Die entsprechende Option findet man unter „Extras“ → „Einstellungen“ (auch erreichbar über Strg+P) → „Video“ (im einfachen Anzeigemodus) → „Ausgabe“. Im dortigen Dropdown-Menü stehen einem zahlreiche Optionen zur Verfügung. Ich verwende nun „OpenGL-Videoausgabe“, da ich mit „DirectX-Videoausgabe“ Probleme habe: Starte ich mit dieser Einstellung die Videowiedergabe, so wird Aero komplett deaktiviert, was zwar nichts kaputt macht, aber nicht sein muss.

    Mit dieser Einstellung werden Videos wieder korrekt hochgerechnet, so wie ich das bisher gewohnt war. Als Beweis soll folgender Screenshot dienen. Der vergrößert zwar wieder die bekannten gibbs’schen Artefakte und Kompressionsmängel zeigt, das Bild ist nun aber ansonsten sauber glättet.

    Zu beachten ist nur noch, dass der VLC Media Player derartige Einstellungen erst nach einem Neustart des Programms bzw. des abzuspielenden Videos übernimmt.

    Abschließend sei auch noch erwähnt, dass ich eine Grafikkarte von NVIDIA verwende, genauer gesagt eine GeForce 8800 GTS der zweiten Generation. Da das Verpixelungsproblem jedoch mit Aero und nicht einem konkreten Treiber zusammenhängt, dürfte das Klötzchenbild auch bei der ein oder anderen Graikkarte von AMD (ehemals ATI) auftreten.

  • Der Pinguin spurtet davon.

    Gestern stand die Abschlusspräsentation meines Programmierpraktikums an, die sehr erfolgreich verlief. In den nächsten Tagen werde ich dann auch die Ausarbeitung meines Programmierpraktikums online stellen.

    Bei der Vorbereitung der Präsentation ist mir noch was aufgefallen, was auch in der Ausarbeitung keine Erwähnung mehr findet. Entwickelt hab ich mein Simulationstool hauptsächlich unter Windows, die Präsentation der Software habe ich jedoch unter Linux gemacht. Dabei ist mir aufgefallen, dass die Erstellung der Simulationsbilder unter Linux (unterer Screenshot) wesentlich weniger Zeit beansprucht als unter Windows (oberer Screenshot), was folgende beiden Screenshots illustrieren sollen.


    Zwar werden die Laufzeiten auf ganze Sekunden abgerundet, aber man sieht, dass die Ausführung unter Windows (oberer Screenshot) sage und schreibe doppelt so lange dauert wie unter Linux (unterer Screenshot). In meinem Fall handelt es sich um die Distribution Ubuntu).

    Dabei wurde beide Male haargenau der selbe Zylinder simuliert mit exakt den selben Form-, Lage-, Beleuchtungs- und Modellierungsparametern. Beide Male wurde die Software mit gcc kompiliert mit absolut identischen Compileroptionen. In keinem der beiden Testläufe waren zusätzliche Programme geöffnet, die Prozessor oder Speicher hätten auslasten können. Auch das Testsystem, mein Notebook, war beide Male das gleiche.

    Zwar handelte es sich bei meiner Windows XP Professional Version um die 32-Bit Variante und bei Ubuntu um die mit 64-Bit Unterstützung, das dürfte aber nur einen Unterschied bei der Genauigkeit der Berechnungen, jedoch nicht bei deren Geschwindigkeit machen. Auch die Tatsache, dass nur die Windows Version das Abspeichern von PNG-Dateien unterstützt, dürfte keinen Unterschied machen, da dieses Abspeichern explizit ausgeführt werden muss und nichts mit dem eigentlichen Bildberechnungsprozess zu tun hat. Da es sich bei der CPU in meinem Notebook (einem AMD Athlon-64 3000+) um eine Singlecore CPU handelt, kann auch eine eventuell betriebssystemabhängige Schleifenparalellisierung (in der aktuellen Version ist Zybesi keine Multithreadanwendung), für die wirklich einiges Potential in meiner Software vorhanden ist, nicht schuld an den massiven Leistungsunterschieden sein. Auch habe ich darauf geachtet, dass die CPU sowohl unter Windows als auch unter Linux auf maximalem Arbeitstakt läuft und sich nicht in irgendeinem Stromspamodus befindet und sich somit automatisch herunter taktet.

    Das soll jetzt natürlich nicht heißen, dass Linux das bessere (oder zumindest schnellere) Betriebssystem ist, aber eine Erwähnung in Form dieses Blogeintrags war’s mir dann doch wert.

    Nachtrag („Wer lesen kann ist klar im Vorteil“ oder „Wikipedia ist (meistens) dein Freund“):
    Jetzt habe ich doch noch die Lösung für den großen Geschwindigkeitsunterschied bei den Berechnungen unter den beiden Betriebssystemen gefunden. Den weitaus größten Teil der Berechnungen in meinem Simulationstool machen Skalarprodukte von Vektoren aus, also im Prinzip Additionen und Multiplikationen von Gleikommazahlen. Bei der AMD64-Architektur, die die x86-Architektur und den x86-Befehlssatz erweitert und über die meine Notebook-CPU verfügt, sind zwei Faktoren entscheidend für den Performanceboost, den ich festgestellt habe.

    • Im 64-Bit Modus stellt die AMD64-Architektur 16 zusätzliche Register zur Verfügung, die bei der Ausführung von 32-Bit Anwendungen auf der selben CPU nicht zugänglich sind.
    • Hauptunterschied für den Geschwindigkeitsunterschied dürfte jedoch sein, dass die AMD64-Architektur für Gleitkommaoperationen nicht auf die x86-FPU zurück greift, sondern stattdessen die entsprechende SSE-Einheit benutzt. Diese ist von Haus aus performanter als die x86-FPU. Größter Vorteil der SSE-Einheit ist die Tatsache, dass deren Register, in denen die Operanden für eine Berechnubg stehen, 128 Bit breit sind. Im Gegensatz dazu sind die Register der x86-FPU nur 80 Bit breit.
      In ein Register der SSE-Einheit passen also vier Gleitkommazahlen einfacher Genauigkeit oder zwei Gleitkommazahlen doppelter Genauigkeit. Der Clou ist nun, dass die SSE-Einheit tatsächlich pro Verarbeitungschritt jeweils zwei Gleitkommazahlen doppelter Genauigkeit aus zwei Registern nehmen kann und so in einem Schritt zwei Gleitkommaberechnungen durchführt. Dies dürfte wohl die doppelte Ausführungsgeschwindigkeit der Bildberechnung unter Linux im 64-Bit Modus erklären.

    Wer das alles mal selbst durchlesen möchste, dem empfehle ich die beiden Wikipedia-Artikel zu AMD64 und SSE, aus denen ich diese Informationen habe.