Re: [VLC] Abspielprobleme mit Live-Streams

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