Re: vlc und mplayer - race conditions?

On Thu, Aug 26, 2010 at 10:20:00AM +0200, Oliver Fromme wrote:
> 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.

Ich weiß bereits, dass das Javascript ist, aber das braucht man
heutzutage aber auch.
Flash ist harmlos - der startet bei mir ein externes npviewer.bin,
den man zwischendurch einfach mal abschiessen kann, wobei der
sich leider auch sehr regelmässig notwendig ist.

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

ROFL

> 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 habe hier einen Proxy zwischen - ja da geht regelmässig was
spannendes durch...

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

Naja - manche Seiten, auf denen ich das brauche sind auch diejenigen,
die den Ärger machen.

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

Die härteste Erkenntniss, die ich zuletzt mit Browsern hatte war,
dass ich den Eindruck gewannt, dass der Firefox bereits nach
wenigen Klicks tot war.
Es stellte sich heraus, dass es daran lag, dass mein Homedir
mit den zugehörigen .*-dirs auf einem NFS-Server lag - was für
eine böser Umtrieb mich auch immer dazu getrieben hat sowas
dummes zu tun.
Jedenfalls war der bereits kurze Zeit später nur noch mit dem
NFS-Server beschäftigt.
Der Seamonkey-2 hat das gleiche Problem übernommen.
Jetzt habe ich das Verzeichniss auf die lokale Platte verschoben
und der Spuk verschwand.

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

Gute Idee.

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

Das deckt sich rein gar nicht mit meinen Beobachtungen, aber mag
durchaus an meinem alten X oder den alten Karten liegen.
Bei mir macht es jedenfalls einen deutlichen Unterschied.
Möglicherweise ist der wirklich immer aktiv, nur meine Karte zu
lahm, womit du dann trotzdem recht hättest.

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

Das sieht bei mir komplett anders aus.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message