# Suche: Mplayer-Tunig Tipps! - Mplayer erzeugt hohe CPU-Last

## ChrisJumper

Hallo,

nachdem ich mit bedauern feststellen musste das cp, trotz aktiviertem DMA die Daten über die CPU schiebt "weil/und" es erst seit Kernel 2.6.17 eintsprechende Systemcalls (tee, splice vmsplice) zur Verfügung stehen mit denen man das mal ändern könnte. Fühle ich mich schon so als hätte mein Gentoo Schnupfen.

Zum eigentlich Thema:

Mein Mplayer verursacht bei einigen Dateien 70-80% CPU-Last, ich möchte der Sache auf den Grund zu gehen.

Vielleicht liegt es nur an speziellen Codecs-Implementierungen oder daran das die CPU-Detection nicht richtig funktioniert oder (viel wahrscheinlicher) daran das ich den nicht richtig konfigurierte (Useflags-etc).

```
 $ mplayer ./gwen-ingametrailer-hires-de.wmv 

MPlayer dev-SVN-rUNKNOWN-4.1.2 (C) 2000-2007 MPlayer Team

CPU: AMD Athlon(tm) XP 3000+ (Family: 6, Model: 10, Stepping: 0)

MMX2 supported but disabled

CPUflags:  MMX: 1 MMX2: 0 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0

MPlayer mit CPU-Erkennung zur Laufzeit kompiliert.

Spiele ./gwen-ingametrailer-hires-de.wmv.

ASF-Dateiformat erkannt!

[asfheader] Audiostream gefunden, -aid 1

[asfheader] Videostream gefunden, -vid 2

VIDEO:  [WMV2]  1280x720  24bpp  1000.000 fps  3500.0 kbps (427.2 kbyte/s)

Clip-Info:

 name: 

 author: 

 copyright: 

 comments: 

[VO_TDFXVID] Kann /dev/tdfx_vid nicht öffnen: No such file or directory.

==========================================================================

Öffne Videodecoder: [dshow] DirectShow video codecs

Decoder supports the following YUV formats: YUY2 IYUV UYVY YV12 YVYU I420 YVU9 

Decoder is capable of YUV output (flags 0x7f)

VDec: VO wird versucht, auf 1280 x 720 (Bevorzugter Farbraum: Packed YUY2) zu setzen.

[PP] Verwende Postprocessing-Routinen des Codecs, max q = 4.

VDec: Verwende Planar YV12 als Ausgabefarbraum (Nummer 0).

Film-Aspekt ist undefiniert - keine Vorskalierung durchgeführt.

VO: [xv] 1280x720 => 1280x720 Planar YV12 

Ausgewählter Videocodec: [wmv8] vfm: dshow (Windows Media Video 8)

==========================================================================

==========================================================================

Öffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders

AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)

Ausgewählter Audiocodec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))

==========================================================================

AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)

Starte Wiedergabe...
```

Meine Version + Useflags:

```
 Installed versions:  1.0.20070622-r1(17:38:54 27.06.2007)(3dnow 3dnowext X a52 aac aalib alsa -altivec -amrnb -amrwb arts -bidi -bindist -bl -cddb -cdparanoia cpudetection -custom-cflags -debug -dga -directfb -doc dts -dv -dvb dvd -dvdnav -enca encode esd -fbcon -ftp -ggi gif gtk iconv ipv6 -ivtv jack -joystick jpeg -libcaca -lirc -live -livecd -lzo mad -md5sum mmx -mmxext -mp2 mp3 -musepack -nas -openal opengl oss png -pnm quicktime -radio -rar real -rtc -samba sdl -speex -srt sse -sse2 -ssse3 -svga -tga theora -tivo truetype unicode -v4l -v4l2 video_cards_mga video_cards_s3virge video_cards_tdfx video_cards_vesa -vidix vorbis win32codecs -x264 -xanim -xinerama xv -xvid -xvmc -zoran)
```

```
$ cat /proc/cpuinfo 

processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 6

model           : 10

model name      : AMD Athlon(tm) XP 3000+

stepping        : 0

cpu MHz         : 2091.239

cache size      : 512 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts

bogomips        : 4184.72

clflush size    : 32
```

Bin für jeden Hinweis dankbar!

----------

## Vortex375

Du kannst noch das mmxext USE-Flag setzen (wird von deiner CPU unterstützt) und die runtime cpu detection (cpudetection USE-Flag) würde ich abschalten.

Versuche für wmv Wiedergabe mal die ffmpeg Decoder und nicht die DirectShow Codecs zu verwenden. Das machst du, indem du die Option "-vfm ffmpeg" an mplayer übergibst.

Wenn es damit besser läuft, dann kannst du dir eine angepasste codecs.conf in deinem ~/.mplayer Verzeichnis erstellen, damit der die ffmpeg Decoder standardmäßig nimmt.

----------

## sirro

 *Vortex375 wrote:*   

> Wenn es damit besser läuft, dann kannst du dir eine angepasste codecs.conf in deinem ~/.mplayer Verzeichnis erstellen, damit der die ffmpeg Decoder standardmäßig nimmt.

 

Wie würde ich das angehen? Einfach die komplette codecs.conf kopieren und den ffmpeg-codec auf working setzen?

Dann müsste ich das ja nach jedem update machen, gibt es da was eleganteres?

Habe zwar nicht das gleiche Problem, aber ein der ffmpeg-decoder braucht wirklich was weniger und ich wollte den schon immer gerne als default haben.

----------

## papahuhn

Kann es sein, dass DRI bei dir deaktiviert ist?

----------

## Vortex375

 *Quote:*   

> Dann müsste ich das ja nach jedem update machen, gibt es da was eleganteres? 

 

Eigentlich musst du das nicht nach jedem Update wiederholen. Ich hab meine eigene codecs.conf in meinem Homeverzeichnis, mit der ich den mad Codec als Standard für mp3 eingestellt habe. Ich benutze ein svn ebuild für mplayer und update mplayer oft. Trotzdem funktioniert meine codecs.conf noch.

 *Quote:*   

> Einfach die komplette codecs.conf kopieren und den ffmpeg-codec auf working setzen? 

 

Hmm jo, eigentlich müsste das so funktionieren. Es werden außerdem die Codecs, die weiter oben in der Datei stehen gegenüber denen weiter hinten bevorzugt (obwohl in der Doku etwas gegenteiliges steht). Wenn du also wie ich mad statt mp3lib als mp3-Decoder verwenden wolltest, dann reicht es den "audiocodec"-Block von mad vor den von mp3lib zu kopieren.

Du kopierst dir einfach die codecs.conf von /usr/share/mplayer/codecs.conf nach ~/.mplayer/codecs.conf und nimmst dann die Anpassungen dort vor. Hin und wieder solltest du vieleicht die Datei nochmal neu kopieren, aber so oft kommen da auch keine neuen Codecs dazu.

----------

## sirro

 *Vortex375 wrote:*   

> Trotzdem funktioniert meine codecs.conf noch.

 

Klar, aber man würde neue Codecs verpassen komplett verpassen. Was nicht in der Datei ist scheint nicht zu gehen. Werde das mal ausprobieren.

Die /usr/share/mplayer/codecs.conf gibt es uebrigens nicht mehr, die ist jetzt intern. Man sie aber noch im source-tar.gz von mplayer.

----------

## Anarcho

Durchaus Sinn macht auch das probieren von verschiedenen Video Outputs.

Einfach mit "mplayer -vo help" ausführen und mal durchtesten. Gut sollten xvmc (gibt es nicht immer) oder xv sein. Auch sdl kann man probieren.

----------

## ChrisJumper

 *Vortex375 wrote:*   

> Du kannst noch das mmxext USE-Flag setzen (wird von deiner CPU unterstützt) und die runtime cpu detection (cpudetection USE-Flag) würde ich abschalten.

 

Ok gemacht...

 *Quote:*   

> 
> 
> Versuche für wmv Wiedergabe mal die ffmpeg Decoder und nicht die DirectShow Codecs zu verwenden. Das machst du, indem du die Option "-vfm ffmpeg" an mplayer übergibst.
> 
> 

 

Sehr interessant. mit ffmpeg verbraucht er in der Tat ca. 50-60% der Ressourcen. Die Lastspitzen sind etwas anders verteilt, etwas niedriger. Aber immer noch hoch.

 *Quote:*   

> 
> 
> Wenn es damit besser läuft, dann kannst du dir eine angepasste codecs.conf in deinem ~/.mplayer Verzeichnis erstellen, damit der die ffmpeg Decoder standardmäßig nimmt.

 

Das werde ich trotzdem mal ausprobieren.

Interessant ist auch das papahuhn nach dri fragt, denn es ist in der Tat deaktiviert. Ich sollte unbedingt besser Kommentieren warum ich diverse Dinge auskommentiere. Ich kommentier es mal aus und starte später neu.

@Anarcho

Also xv und sdl sind gesetzt, die Useflags xvid und xvmc noch nicht. Ich denke ich werde beide nochmal setzen. Kann ja nicht schaden.

Bis jetzt sieht es so aus...

```
 $ mplayer -vo help

MPlayer dev-SVN-rUNKNOWN-4.1.2 (C) 2000-2007 MPlayer Team

CPU: AMD Athlon(tm) XP 3000+ (Family: 6, Model: 10, Stepping: 0)

CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0

Kompiliert für x86 CPU mit folgenden Erweiterungen: MMX MMX2 3DNow 3DNowEx SSE

Verfügbare Videoausgabetreiber:

        tdfx_vid        tdfx vid

        xv      X11/Xv

        x11     X11 ( XImage/Shm )

        xover   General X11 driver for overlay capable video output drivers

        gl      X11 (OpenGL)

        gl2     X11 (OpenGL) - multiple textures version

        dga     DGA ( Direct Graphic Access V2.0 )

        sdl     SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)

        svga    SVGAlib

        aa      AAlib

        null    Null video output

        mpegpes Mpeg-PES file

        yuv4mpeg        yuv4mpeg output for mjpegtools

        png     PNG file

        jpeg    JPEG file

        gif89a  animated GIF output

```

Danke für eure Antworten!

----------

## Anarcho

Hast du denn auch mit den verschiedenen vo optionen videos probiert?

Also z.B.:

mplayer -vo xv datei.avi

----------

## ChrisJumper

Hmm. Jetzt hab ich dies alles ausprobiert. Aber signifikant verbessert hat sich nichts.

Die CPU Last ist aber wenigstens um ca. 20-30 Prozentpunkte zurück gegangen. Weitere ca. 5% sind drin wenn ich das ganze unter Fluxbox starte statt unter Gnome mit Beryl.

So langsam beschleicht mich das Gefühl das es einfach an Dateien mit hoher Bild-Auflösung liegt. Aber kann dies der Grund sein, das es sich so stark Äußert? Ich vergleich das jetzt leider nur mit dem Windows-XP von einem bekannten und dessen Ressourcen verbrauch im Task-Manager. Andererseits hat er auch schon einen Dual-Core. Und dieses Phänomen erscheint bei höherer Leistung nicht mehr so gravierend.

Ich versuche mal die selbe Datei auf meinem zweiten, 64-bit, dual core, gentoo PC abzuspielen.

Eine Datei die mir damals schon richtig Probleme machte war die HD-Version von Elephants Dream, dabei war die Auflösung des Videos um einiges höher als der meines Monitors/Desktops und ich dachte der Leistungsverlust wird verursacht dadurch das jeder Frame runterskaliert werden muss.

----------

## der.gecko

wieviel ram hast du und welche grafikkarte benutzt du?

----------

## papahuhn

Vielleicht zum Vergleich:

Die 1920er Version von Elephants Dream belastet einen der zwei Kerne meines E6600 Core2Duo mit 60%.

----------

## Vortex375

 *Quote:*   

> Die /usr/share/mplayer/codecs.conf gibt es uebrigens nicht mehr, die ist jetzt intern.

 

Stimmt nicht.

 *Quote:*   

> So langsam beschleicht mich das Gefühl das es einfach an Dateien mit hoher Bild-Auflösung liegt. Aber kann dies der Grund sein, das es sich so stark Äußert?

 

Unter Umständen schon. Vor allem wenn du beryl verwendest, weil hierbei das Bild ja erst in eine Off-Screen-Pixmap gerendert wird und danach auf den Bildschirm kopiert werden muss. Bei höheren Auflösungen steigt natürlich die Menge an Daten, die kopiert werden müssen und dadurch auch der "Overhead" durch das Compositing durch beryl.

Am schnellsten sollte im Prinzip immer der xv Treiber sein, zumindest dann, wenn der Grafikkartentreiber die XVideo-Schnittstelle unterstützt und dort Hardwarebeschleunigung anbietet.

Ansonsten kannst du mit einer OpenGL 2.0 kompatiblen Grafikkarte auch folgendes testen.

```
-vo gl:yuv=4:lscale=1:cscale=1
```

(für Details siehe man-page)

Das verwendet ein Fragment-Program zur beschleunigten Videoausgabe. Fragment-Programs sind kleine Programme, die in irgend so ner Shader-Programmiersprache geschrieben und auf dem Grafikchip ausgeführt werden. Du brauchst dazu die OpenGL-Erweiterung "GL_ARB_fragment_program" (überprüfen mit "glxinfo | grep fragment").

Ich würde außerdem die Audio-Ausgabe unbedingt auf ALSA umstellen (-ao alsa). OSS ist seit 10 Jahren veraltet und die Kompatibilitätsschicht wird nur noch wegen einigen (vorallem Close-Source) Programmen angeboten, die noch keine ALSA-Unterstützung besitzen.

----------

## musv

 *Vortex375 wrote:*   

> Ich benutze ein svn ebuild für mplayer und update mplayer oft. Trotzdem funktioniert meine codecs.conf noch.

 

Das ist interessant. Ich fahr hier ein ~x86-System, aber mplayer ist das einzige Paket, was ich in package.keywords auf stable gesetzt hab. Irgendwie waren mir die Testing-Versionen aus dem Portage zu buggy. Einmal war die Tastatursteuerung (Spulen, Lautstärke, usw) abgestellt, dann funktionierte das OSD nicht mehr. Irgendwann hat's mir gereicht. Seit ich das Teil auf Stable umgestellt hab, gibt's diese Probleme nicht mehr. 

ChrisJumper: 

Bei mir (Athlon-XP2600+, xv-Treiber) läuft das Video meist mit ca. 40% CPU-Last, geht aber stellenweise bis auf 70% hoch. Die Hauptgründe (mmx2, cpudetection) wurden ja schon genannt, xv sollte auch der schnellste Treiber sein. Aber bei der Auflösung ist das einfach normal, daß das Video etwas mehr Rechenleistung beansprucht. Und der wmv-Codec wird noch das Restliche dazutun. Zumindest hat das Video bei mir stellenweise geruckelt, obwohl die CPU-Last nicht bemerkbar höher war als an anderen Stellen des Videos. Elephants-Dream lief bei mir auch relativ flüssig, brauchte aber auch relativ viel CPU-Leistung. 

Und ja, wenn Beryl in Verbindung mit Gnome im Hintergrund läuft, ist das auch kein Wunder, wenn das Video scheinbar mehr Leistung braucht. 

Gibt's eigentlich irgendwo eine Aufstellung, welcher Codec für mp3, video usw. die besten Resultate liefert? Bis jetzt hab ich nur die Erfahrung gemacht, daß die xine-lib 'ne bescheidene Qualität hat. Manche vielleicht fehlerhafte MP3s geben im Amarok stellenweise häßliche Geräusche von sich, im mplayer laufen diese sauber durch. Bei Videos sind mir bisher noch keine speziellen Unterschiede zwischen verschiedenen Codecs aufgefallen.

----------

## Vortex375

 *Quote:*   

> Gibt's eigentlich irgendwo eine Aufstellung, welcher Codec für mp3, video usw. die besten Resultate liefert?

 

In sämtlichen Quellen die ich gelesen habe wird mad als bester mp3-decoder gelobt. Er hat auf die weitläufigste Verbreitung. xine-lib benutzt mad, audacious hat in der neusten Version von mp3lib auf mad umgestellt. Sogar Rockbox (alternatives OS für portable Player) benutzt mad für die mp3-Wiedergabe.

 *Quote:*   

> Das ist interessant. Ich fahr hier ein ~x86-System, aber mplayer ist das einzige Paket, was ich in package.keywords auf stable gesetzt hab.

 

Keine Probleme hier mit dem svn ebuild aus dem berkano Overlay (ist in layman).

----------

## sirro

 *Vortex375 wrote:*   

>  *Quote:*   Die /usr/share/mplayer/codecs.conf gibt es uebrigens nicht mehr, die ist jetzt intern. 
> 
> Stimmt nicht.

 

Bei deiner svn-version mag das anders aussehen, aber ich schreibe doch keinen quatsch:

```
$ equery files mplayer|grep conf

/etc/mplayer/mplayer.conf

/usr/share/mplayer/input.conf

/usr/share/mplayer/menu.conf

/usr/share/mplayer/mplayer.conf
```

```
$ mplayer -v dump

[...]

get_path('codecs.conf') -> '/home/sirro/.mplayer/codecs.conf'

Lese /home/sirro/.mplayer/codecs.conf: Kann '/home/sirro/.mplayer/codecs.conf' nicht öffnen: No such file or directory

Lese /etc/mplayer/codecs.conf: Kann '/etc/mplayer/codecs.conf' nicht öffnen: No such file or directory

Benutze eingebaute Standardwerte für codecs.conf.
```

----------

## ChrisJumper

 *der.gecko wrote:*   

> wieviel ram hast du und welche grafikkarte benutzt du?

 

Bei dem PC hab ich ca.  1,5 GB Arbeitsspeicher.  Geforce 7600 GS.

Jetzt ist mir das auch nicht mehr so wichtig, da andere Filme nicht so viel Ressourcen fressen und so oft schau ich ja auch keine Trailer.

Es hat mich nur interessiert, wie es dazu kommen konnte. das dieser eine Ausgerechnet so viel braucht.

Bei diesem Versuch:

```
$ mplayer  gwen-ingametrailer-hires-de.wmv 

MPlayer dev-SVN-rUNKNOWN-4.1.2 (C) 2000-2007 MPlayer Team

CPU: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz (Family: 6, Model: 15, Stepping: 6)

CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1

Kompiliert für x86 CPU mit folgenden Erweiterungen: MMX MMX2 SSE SSE2

Spiele gwen-ingametrailer-hires-de.wmv.

ASF-Dateiformat erkannt!

[asfheader] Audiostream gefunden, -aid 1

[asfheader] Videostream gefunden, -vid 2

VIDEO:  [WMV2]  1280x720  24bpp  1000.000 fps  3500.0 kbps (427.2 kbyte/s)

Clip-Info:

 name: 

 author: 

 copyright: 

 comments: 

==========================================================================

Erforderliche Videocodec Familie [wmv8] (vfm=dshow) nicht verfügbar.

Aktiviere sie beim Kompilieren.

Erforderliche Videocodec Familie [wmvdmo] (vfm=dmo) nicht verfügbar.

Aktiviere sie beim Kompilieren.

Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family

Ausgewählter Videocodec: [ffwmv2] vfm: ffmpeg (FFmpeg M$ WMV2/WMV8)

==========================================================================

==========================================================================

Öffne Audiodecoder: [ffmpeg] FFmpeg/libavcodec audio decoders

AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)

Ausgewählter Audiocodec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))

==========================================================================

AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)

Starte Wiedergabe...

VDec: VO wird versucht, auf 1280 x 720 (Bevorzugter Farbraum: Planar YV12) zu setzen.

VDec: Verwende Planar YV12 als Ausgabefarbraum (Nummer 0).

Film-Aspekt ist undefiniert - keine Vorskalierung durchgeführt.

VO: [x11] 1280x720 => 1280x720 Planar YV12 

[swscaler @ 0xbf78f0]SwScaler: using unscaled yuv420p -> rgb32 special converter

```

auf dem Dual Core, werden lediglich ~14% einer CPU beansprucht. Wahrscheinlich bringen mmx2 und sse2 hier noch einen größeren Geschwindigkeitsvorteil.

Ich finde es immer wieder interessant wie viele Optionen man unter Linux, speziell unter Gentoo hat. Eigentlich muss man sich dabei auch ein wenig besser mit der Technik auskennen sonst verlaufen die Möliglichkeiten im Sand. Aber das hat man als 0815 User mit einer exotischen Hardware unter anderen großen Betriebssystemen wohl auch.

Vielen dank für eure Anregungen :)

Grüße

Chris

----------

## Vortex375

 *Quote:*   

> Bei deiner svn-version mag das anders aussehen, aber ich schreibe doch keinen quatsch

 

Ich glaubs dir, aber möglicherweise sind die Gentoo ebuilds für mplayer auch Mist. Mein mplayer konnte nach einem Update nicht mal mehr mp3 abspielen. Seit ich das svn ebuild benutze hab ich keine Probleme mehr.

Die man-page erweckt auf jeden Fall den Eindruck, als sei die eingebaute codecs.conf nur als Fallback-Option für den Notfall eingebaut.

----------

