Mailinglist Archive: opensuse-multimedia-de (30 mails)

< Previous Next >
Re: [opensuse-multimedia-de] [VLC] Abspielprobleme mit Live-Streams
  • From: David Haller <opensuse@xxxxxxxxxx>
  • Date: Sun, 31 May 2009 07:30:02 +0200
  • Message-id: <20090531053002.GA24236@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-multimedia-de+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups