Re: vlc und mplayer - race conditions?

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Thu, 26 Aug 2010 10:20:00 +0200 (CEST)

Bernd Walter wrote:
> Heino Tiedemann <rotkap(at)GMX.de> wrote:
> > Bernd Walter wrote:
> > > Oh - der Lüfter dreht bei mir in erster Linie nur hoch, wenn ich
> > > diverse Webseiten offen lasse - auch wenn die auf dem Bildschirm
> > > absolut nix verändern und sogar wenn der Browser auf einem gerade
> > > nicht aktiven virtuellen Desktop läuft.
> >
> > Firefox unter KDE? :)
>
> Seamonkey mit Windowmaker - aber ich kann diese Effekte auch auf
> Windows mit diversen Browsern feststellen.
> Mein Notebook ist ein Atom, da merkt man ziemlich schnell, wenn
> so ein Browser mal Leistung zieht.

Schalt mal testweise JavaScript ab. Ich beobachte das auch
ab und zu (ich verwende Opera), und in der Regel lässt es
sich darauf zurückführen, dass client-seitige Skripte in
einer Webseite irgendwelche obskuren Tätigkeiten entfalten.
Damit meine ich sowohl JavaScript als auch Flash.

Sehr beliebt ist zum Beispiel "verschlüsseltes" JavaScript
(soll wohl dem Kopier- oder Modifikationsschutz dienen),
das sich im Browser erstmal entschlüsseln muss. Und damit
es "sicherer" ist, wird jede Funktion erst dann "on demand"
entschlüsselt, wenn sie gebraucht wird, d.h. der Browser
ist die ganze Zeit fast mit nichts anderem beschäftigt.

In manchen Fällen könnte man fast den Eindruck haben, dass
die eigenen CPU-Resourcen ungefragt für irgendeine Cloud
abgezweigt werden. Wer weiß ...

Aus Neugierde habe ich ab und zu einen Tracer mitlaufen, so
dass ich sehe, was da für Aktivitäten abgehen. Das ist zum
Teil echt erschreckend. Zum Beispiel hat www.dell.com einen
Click-Handler für die gesamten Seitenflächen, d.h. ganz egal
wo man hinklickt (auch auf den Hintergrund), es wird an die
Dell-Webserver zurückgemeldet und fleißig Cookies hin und
hergeschickt. In einem anderen Fall musste man nicht einmal
klicken: Sämtliche Mausbewegungen wurden an den Webserver
gemeldet, solange der Browser den Fokus hatte.

Ich löse das Problem so, dass JavaScript und Flash grund-
sätzlich abgeschaltet sind (das hat den praktischen Neben-
effekt, dass auf etlichen Webseiten keine Werbung mehr
angezeigt wird), und lasse es speziell nur für die Sites
bzw. URL-Pfade zu, wo es tatsächlich benötigt wird. Bei
Opera kann man es recht fein granuliert einstellen; bei
Firefox bestimmt auch (bzw. es gibt vermutlich ein halbes
Dutzend Plug-ins dafür).

> Grausam, nicht?
> Das Angebot an wirklich tauglichen Browsern ist eindeutig gleich null.
> Es bleibt einem nur übrig sich das kleinste Übel rauszusuchen.

Das stimmt leider. Bei mir persönlich hat sich als das
kleinste Übel der Opera herauskristallisiert, aber je nach
Anforderungen und Gewohnheiten kann es natürlich auc ein
anderer sein (ich will nicht behaupten, dass Opera der
Beste sei).

Wenn ich mal kurz etwas auf einer "einfachen" Web-Seite
nachschlagen will, starte ich manchmal auch schnell den
Dillo (ports/www/dillo2). Der kann gar kein JavaScript,
und die Rendering-Engine hat etliche Macken, aber er
ist *sauschnell* und sehr resourcenschonend. Für Dinge
wie den heise-Newsticker oder Spiegel-Online (solange
man keine Videos gucken will), rfc-editor.org usw. genügt
er vollkommen.

> > > Ich schalte aber auch die Auflösung vom X11 um statt den Player
> > > skalieren zu lassen.
> >
> > Verstehe ich richtig - du änderst lieber die auflösung von deinem X11
> > als den mplayer - beispielsweise - im vollbild laufen zu lassen?
>
> Genau - per xv könnte der Player das selber umschalten, aber da ich
> lieber mit x11 arbeite muss ich das selber tun.
> Meine normale Auflösung beträgt 2000x1600 mit PCI-Karten, das bremst
> gewaltig, wenn der Player die alle mit bewegten Bildern versorgen will.
> Wenn ich hingegen umschalte braucht er weder Skalieren, noch so viele
> Daten schaufeln - auch hier wäre xv besser, weil das dann die Karte
> skalieren würde, aber auch die müsste dafür was unnötiges tun.

Bei dem letzten Satz muss ich ausnahmsweise widersprechen.

Der YUV-Scaler ist so ziemlich der primitivste Bestandteil
eines Graphikchips. Vermutlich ist der eh immer aktiv, egal
ob er gerade benötigt wird oder nicht. Und ob der Scaler
eine Graphik auf 640x480 oder auf 2000x1600 aufzieht, ergibt
(bei gleichen Eingangsdaten) keinen messbaren Unterschied.
Die kubische / bikubische Interpolation, die da gemacht wird,
ist aus technischer Sicht ein Witz.

Davon abgesehen führt der YUV-Scaler so "nebenbei" auch die
Farbraumkonvertierung durch, da das Ausgangsmaterial aller
gängigen Videoformate in YUV bzw. YCbCr vorliegt. Dadurch
nimmt er nicht nur ebenfalls dem Prozessor Arbeit ab, son-
dern verbessert auch die Bildqualität, da zuerst die Skalie-
rung und dann die Konvertierung nach RGB durchgeführt wird.
Softwarelösungen konvertieren in der Regel zuerst nach RGB
(verlustbehaftet!), und skalieren dann das Ergebnis auf die
Bildschirmgröße, was erstens Verlustartefakte verstärkt, und
zweitens kommen im allgemeinen Skalierungsalgorithmen zum
Einsatz, die schneller und qualitativ minderwertiger sind
(z.B. nur lineare Interpolation).

> Vor allem bei Videos mit kleiner Auflösung macht es sehr viel aus,
> wenn man die Bildschirmauflösung anpasst.

Gerade bei Videos mit geringer Auflösung kommt es der Bild-
qualität zugute, wenn man es den Hardware-Skaler auf die
volle Bildschirmauflösung ziehen lässt. Mein Xorg läuft
dauerhaft mit der nativen Auflösung des LCD (1920 x 1080),
und nichts anderes würde ich empfehlen. Beim Abspielen
einer DVD ist der Prozessor 96% idle, egal ob in einem
kleinen Fenster oder Fullscreen. Und der Graphikchip (on-
board, ohne eigenen Lüfter) langweilt sich dabei auch.
Der entsprechende Temperatursensor auf dem Board geht um
kein Zehntelgrad rauf.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
Python is executable pseudocode.  Perl is executable line noise.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 26 Aug 2010 - 10:20:24 CEST

search this site