Re: [VLC] Abspielprobleme mit Live-Streams

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