Am Sonntag, 31. Mai 2009 schrieb David Haller:
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? ;)
Viel fehlt da nicht, ruhige Stellen so 60%, bei besonders hektischen Szenen mit hoher Bitrate ruckelts dann auch mal ein bisschen, also > 100%. Hab mir damals als ich mir das DVD Laufwerk angeschafft habe auch nen Celeron 1 GHz reingepackt, der leider nicht mehr funktioniert (Lüfter verrutscht, überhitzt). Jetzt steckt eben wieder der PII drin (genauer zwei davon, deshalb bliebe auch beim DVD schauen noch Reserven, aber mit der Kiste mach ich nur noch selten was, DVDs werden darauf nur noch für Tests abgespielt).
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
Aber die müsste doch XVideo beherrschen (-vo xv beim MPlayer). Das hilft freilich nicht bei der dekodierung, aber bei der Farbraumwandlung und Skalierung (wer hat schon eine YUV Grafikkarte und 720x576 Auflösung auf dem Schirm). Von XVideo Motion Compensation (xvmc) ist ja gar nicht die Rede (müsste mein Dell Notebook mit Intel 945er Chipsatz beherrschen, killt aber mit dem 2.7.1er Intel Treiber nur den X-Server, mit früheren Treibern gings mal, aber die hatten andere Probleme, da soll der Core2Duo das Decodieren übernehmen, der merkt das kaum).
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
Siehe Wikipedia: http://de.wikipedia.org/wiki/Kaffeine Gibt meiner Meinung nach keinen besseren Desktopmediaplayer wenn man auch Digitalfernsehen einsetzt. Aber es ist doch schön Alternativen zu haben, egal ob Desktopumgebung/Windowmanager oder Mediaplayer. Ich bin da nicht auf dem Kreuzzug und will alle zu den von mir verwendeten Programmen bekehren. Ich KDE seit 1.0.1 laufen (auf meinem Amiga 3000 unter ner Schatztruhe RadHat 5.1 Portierung für den Amiga), und seit gestern die 4.3er Vorversion 4.2.88.
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.
Ich weiß das, nicht umsonst habe ich wegen jedem kleinen optimierungsfurz in ffmpeg vor der 0.5er Release ein neues Paket für Packman geschnürt. Bis ich auf meinem damals aktuellen Asus Notebook mit PentiumM 1,6 GHz FullHD Videos weitestgehend ruckelfrei abspielen konnte (mit xine basierten Playern, unter MPlayer hab ich es nie ohne massive Framedrops hinbekommen, und VLC gleich zweimal nicht, da blieb das Bild irgendwann einfach nur noch stehen). Wenn aber ein 1,6 GHz PentiumM FullHD schafft, dann schafft ein P3 1 GHz PAL, das sind weniger als 20% der Daten (2.073.600 gegen 408.960 Pixel).
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.
gstreamer ist aber keine Abstraktionsschicht sondern ein modulares Mediaframework. Gewisse Abstaktionsschichten sind immer nötig, wenn man flexibel sein will und nicht wie zu C64 und frühen Amiga Zeiten speziell für eine Hardware programmiert. MPlayer könnte ja auch nicht diverse Video und Audio Ausgabeplugins ansteuern (mplayer -vo help, bzw. mplayer -ao help), wenn es nicht Abstrahieren würde. Würde man nicht zwischen Demuxen, Decodieren, Nachbearbeiten und Ausgeben immer wieder einheitliche Schichten einbauen, könnte man manches effizienter programmieren, könnte aber auch nicht so flexibel sein und z.B. mit vdpau die Decodierung an die Grafikkarte deligieren. Als ich den IFF demuxer und ILBM, ANIM und SV8X decoder für xine geschrieben habe, fande ich es auch unpraktisch die Bitplanes in YUV anstelle in RGB zu wandeln, aber das Framework erfordert es eben so und im Gegensatz zu xanim werden die alten Amgia-Animationen dann auch skaliert flott wiedergegeben, da das dann normal die Grafikkarte erledigt. Bringst Du das mit KDE4s Phonon durcheinander? Aber auch das ist aber im Grunde nur ein Binding ähnlich wie gtkmm für C++ Programmierer die gtk verwenden wollen. Ich bin heidenfroh, dass wir mit KDE4 arts losgeworden sind, jetzt kommt aus dem Gnome Lager pulse-audio, das bis jetzt noch viel Problematischer ist, als es arts jemals war. Seit alsa selber Streams zusammenmixen kann, hat sich ein derartiger Sounddämon meines Erachtens weitestgehend erledigt.
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
Ich weiß noch, wie stolz wir einst waren, als die ersten Amigas mit hoch optimierten Assembler Routinen MP3s ohne Aussetzer wiedergeben konnten :-) Die Sache ist nur, das bei Audio Aussetzer sofort auffallen, ein Framedrop im Video ist leichter zu verschmerzen, als ein noch so kurzer Audio-Ausfall und wenn diese 1% kurzfristig nicht zur Verfügung stehen, kommt das schon mal vor.
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'.
XFree86 3.3.6? Ok, ich ziehe meine Frage bezüglich XVideo Unterstützung zurück, die kam AFAIR erst mit 4.0 rein. Ich vergaß hier mit einem Paläontologen zu diskutieren ;-) Wenn Du das alles der CPU noch aufbürdest, dann ist klar, dass X264 in PAL Auflösung nicht mehr zu bewältigen ist.
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? ;)
Ähm, Windows, was war das noch gleich? Bei Packman dürfen wir unsere Pakete halt nicht nur nach individuellen Vorlieben bauen.
[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 ;)
Definitiv, unter SUSE 7.1/7.3 gabs noch keine Treiber mit XVideo Extension, da war auf der Kiste nur unskalierte Ausgabe in Briefmarkengröße möglich. Man muss ja auch bedenken, dass der G3 keine Multimediaerweiterung hat, Altivec kam erst mit dem G4, das ist gegenüber den damaligen Intel/AMD CPUs, die mindestens MMX hatten, schon ein Nachteil. Erst als ich mir dann vom Gatos Projekt die ati.2 Treiber besorgte konnte man was damit anfangen. Mittlerweile sind die in X.org eingeflossen. Recht lustig fand ich, dass divx Filmchen die unter MacOS mit Quicktime nur als Slideshow über den Bildschirm fluppten, unter Linux dann gut durchliefen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de -- To unsubscribe, e-mail: opensuse-multimedia-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-multimedia-de+help@opensuse.org