Hallo, Am Sam, 30 Mai 2009, Manfred Tremmel schrieb:
Am Samstag, 30. Mai 2009 schrieb David Haller: [..]
Athlon 500) zu langsam sein für H.264 bei mehr als "Briefmarke"... Mal annehmend, daß dein P3 >= 1 GHz hat, solltest du grob geschätzt MPEG2 in PAL Auflösung (720x576, ggfs. anamorph), DIVX ebenso, aber nur "grade so", H.264 nur in "kleiner" (z.B. 512x384 o.ä.) noch ruckelfrei abspielen[1].
Naja, PAL-DVDs (720x576) spielt mein Pentium II mit 400 MHz auch ab.
Jo, is die gleiche Klasse. Aber die CPU Last dürfte nahe an 100% sein, oder? ;)
Wichtig ist, dass die Grafikkarte mithilft (XVideo-Extension) und kein Deinterlacing fällig wird.
Die Grafikkarte hilft bei mir nicht mit (Matrox Mystique (das Original, 4 MB SGRAM, 170MHz RAMDAC)). Und ich verwende Filter, normal: mplayer -idx -framedrop -vf eq2=2.5 -af volnorm,volume=10
Das schluckt nämlich je nach Qualität oft deutlich mehr als das MPEG2 decoding (Kaffeine mit höchster Deinterlacingstufe kostet das Deinterlacing ungefähr dreimal so viel CPU-Zeit wie das MPEG2 decoding).
Kaffeine? Was ist das? :) KDE hab ich hier nur 1.1.2 und 2.0.0, beide nur installiert, nicht in Verwendung :-P
H.264 ist da natürlich noch ein ganz anderes Kaliber, sollte aber in PAL Auflösung mit einem P3 1GHz noch klappen.
Ohne Framedrops eher kaum. Bzw. nur wenn die GraKa mithilft. H.264 braucht _deutlich_ mehr CPU als Divx (schätzomativ 3mal?) und das braucht auch schon deutlich mehr als MPEG2.
Bzgl. Ton ist es aber nochmal ne ganz andere Sache, da können die aktuellen Sachen wie "Pulse-Audio", Gstreamer etc. viel Ärger machen. Je nachdem wie schnell dein iP3 also ist, bzw. wie das ganze neumodische Krams von KDE/Gnome konfiguriert ist / funktioniert, kann es also Probleme geben. Festes Einstellen auf "ALSA" Ausgabe sollte helfen.
Mein Credo, alsa-plugins-pulse deinstallieren und in Yast auf tabu setzen, dass es kein Programm automatisch nachinstalliert. Dann alle Anwendungen, die es ermöglichen fix auf alsa stellen, damit Automatismen nicht die OSS-Emulation verwenden. "Pulse-Audio" ist ein Geschwür in der Linux-Soundlandschaft! Gstreamer sollte in den Zusammenhang allerdings keine Probleme bereiten, es ist ein Mediaframework wie die xine-lib und sollte Programme, die es nicht benutzen nicht beeinflussen.
Jedes Software-(Abstraktions-)Layer zwischen Player und Hardware braucht CPU ... Ich hab auch auf dem neuen Rechner mit der 11.1 weder gstreamer noch pulse-audio installiert -- bzw. nur die libs jew. für die Abhängigkeiten, weil vieles gegen die gelinkt ist, aber ansonsten beides komplett inaktiv.
Wenn deine CPU zu lahm wäre, sollte sich das zuerst bei der Video-, nicht bei der Audiowiedergabe von Filmen manifestieren ...
Nicht zwangsweise. Die Videodecodierung schluckt natürlich mehr Rechenpower, aber je nach Priorisirung kann auch audio als erstes ins stocken geraten.
Stimmt schon. Aber Video schluckt schon auf meiner alten Kiste sicher deutlich über 90% Rechenleistung beim Abspielen. mplayer spielt mir hier z.B. einen "gedumpten" ac3 Soundtrack mit < 1% CPU-Last (auf dem Athlon 500!) ab... Selbst wenn ich o.g. Audiofilter (volnorm,volume=) mit dazunehme liege ich immer noch unter 1% Last (lt. top, ich muß auf die Sortierung nach Speicherbelegung umschalten, damit ich mplayer überhaupt zu sehen bekomme), der "Idle"-Wert von top verändert sich auch nur passend dazu (<=1%). Wenn ich das Video (Divx, 684x384) dazu mitabspiele liege ich typisch bei 85-100% CPU-Last, davon ca. 40-50% Last durch X (XFree86-3.3.6), der Rest für mplayer selber. Aber du hast auch wieder Recht: das dekodieren / abspielen selber braucht hier gar nicht soo viel CPU, sondern die Darstellung. Achso: '-vo x11'.
Bzgl. der Tonprobleme würde die Ausgabe von VLC (und mir auch von mplayer, falls der ebenfalls "muckt") helfen. Achso: zur Kontrolle könntest / solltest du auch mal testen, wie es mit 'xine' (ebenfalls von Packman) tut (oder auch nicht).
Und dabei vielleicht die CPU auslastung verfolgen, z.B. top mitlaufen lassen und schauen, ob Idle auf 0 sinkt.
ACK.
BTW @ Detlef / Manfred (zur Weiterleitung): könnte man das '--enable-dc1394' erstmal aus dem .spec werfen? Scheint ja (nicht nur bei Christian, siehe opensuse-de) viel Ärger zu machen. Am besten (bis es dann mal tut) konsequent per explizitem '--disable-dc1394'?
Ich frag mal bei Detlef an, hatte ja sicher seine Gründe, das reinzunehmen.
[aus der anderen Mail:]
Habs im spec file von enable auf disable geändert und den Build nochmal angeleiert. Detlef meinte: "wenn es denn hilft, schmeiß es raus."
Danke. Ist ja "nur" für den direkten Zugriff auf per Firewire angeschlossene (DV)-Kameras via libdc1394... Zumindest vorübergehend halte ich das durchaus für verzichtbar ;) (ich selber schmeiß auch noch mehr raus, was will ich mit Zugriff via smb/cifs wenn's hier seit Jahren kein Windows mehr gibt? ;)
[1] bei mir reicht's nicht mal dafür. H.264 geht mit max. 384x288 oder so, Divx mit ~684x384, MPEG2 gerade noch mit PAL...
Hm, das schafft mein oles PowerBook G3 mit 266 MHz ja fast noch.
s.o., wohl nur wg. der besseren Grafikkarte/-treiber ;) -dnh -- In the Beginning there was nothing, which exploded. -- Terry Pratchett, Lords and Ladies -- To unsubscribe, e-mail: opensuse-multimedia-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-multimedia-de+help@opensuse.org