Xine und Internet Video-Streams
Hallo zusammen, wenn ich mir mit Xine Video-Streams aus dem Internet ansehe, stürzt Xine unabhängig vom Frontend früher oder später ab. Fehlermeldungen gibt es keine, auch beim Start in einer Konsole kommt nur: rene@falconeyes:~> Loading codec DLL: 'vp6vfw.dll' Loaded DLL driver vp6vfw.dll KCrash: Application 'kaffeine' crashing... kaffeine: Fatal IO error: client killed Unable to start Dr. Konqi Dabei kann man kaffeine mit jedem beliebigen Frontend für xine austauschen, das Ergebnis ist immer gleich. Was mir auch auffällt ist, das bei Video-Streams der Sound dem Bild um etwa 1,5 Sekunden vorauseilt. Der Puffer ist öfters auch schneller leer, als aus dem Netz nachgeladen werden kann, trotz DSL-Verbindung. -> Absturzgrund? Wie kann man Programmen eine höhere Download-Bandbreite zuordnen? Die mögliche Kapazität wird jedenfalls nicht ausgenutzt. Ich habe das mit KInternet -> Datenübertragungsrate ansehen... überprüft. Unter Windows auf dem selben Rechner ist der Puffer des jeweiligen Players jedenfalls immer gut gefüllt, so das ich Verbindungsprobleme zum jeweiligen Server wohl ausschließen kann. Beispiel-Stream (jposuki-TV): http://mullemeck.serveftp.org/jps_beta/listen.pls?ses_jpst=2512ee13d0a94ddad... Grüße René
Am Mittwoch, 18. Januar 2006 12:56 schrieb René Falk:
wenn ich mir mit Xine Video-Streams aus dem Internet ansehe, stürzt Xine unabhängig vom Frontend früher oder später ab.
Welche xine-lib Version ist im Einsatz und welche SUSE Version? Für 10.0 gibt es unter ftp://packman.iu-bremen.de/testing/xine-cvs immer die aktuellen CVS-Versionen, eventuell behebt die das Problem, ansonsten bitte einen Bugreport: xine --bug-report http://mullemeck.serveftp.org/jps_beta/listen.pls?ses_jpst=2512ee13d0a94ddad... Und das Ergebnis an die xine Mailingliste. Hier läuft der erste Klipp auf jeden Fall durch mit der aktuellen CVS Version.
Was mir auch auffällt ist, das bei Video-Streams der Sound dem Bild um etwa 1,5 Sekunden vorauseilt.
Kann ich hier auch nichts feststellen.
Der Puffer ist öfters auch schneller leer, als aus dem Netz nachgeladen werden kann, trotz DSL-Verbindung. -> Absturzgrund?
Unwahrscheinlich, dass das derartige Probleme hervorruft. Du kannst aber auf jeden Fall die Puffer hochsetzen (xine Einstellunge unter engine buffers.audio_num_buffers und buffers.video_num_buffers), dann wird mehr zwischengespeichert und Spitzen z.B. bei dynamischen Bitraten können leichter ausgeglichen werden, dafür kanns aber beim start ein wenig länger dauern, bis die Puffer voll sind und die Sache losläuft.
Wie kann man Programmen eine höhere Download-Bandbreite zuordnen? Die mögliche Kapazität wird jedenfalls nicht ausgenutzt. Ich habe das mit KInternet -> Datenübertragungsrate ansehen... überprüft.
Dann kanns natürlich auch am Server liegen, wenn der keine Reserven mehr hat und mit der Datenlieferung nicht hinterher kommt.
Unter Windows auf dem selben Rechner ist der Puffer des jeweiligen Players jedenfalls immer gut gefüllt, so das ich Verbindungsprobleme zum jeweiligen Server wohl ausschließen kann.
Hm.
Beispiel-Stream (jposuki-TV): http://mullemeck.serveftp.org/jps_beta/listen.pls?ses_jpst=2512ee13d0 a94ddad3a260e1de84ecf1
Süßes Mädel ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Mittwoch, 18. Januar 2006 21:02 schrieb Manfred Tremmel:
Am Mittwoch, 18. Januar 2006 12:56 schrieb René Falk:
Welche xine-lib Version ist im Einsatz und welche SUSE Version?
Manchmal vergißt man die elementarsten Sachen. SuSE 9.3 libxine 1.1.1-0.pm.2-i686
Für 10.0 gibt es unter ftp://packman.iu-bremen.de/testing/xine-cvs immer die aktuellen CVS-Versionen, eventuell behebt die das Problem, ansonsten bitte einen Bugreport:
xine --bug-report http://mullemeck.serveftp.org/jps_beta/listen.pls?ses_jpst=2512ee13 d0a94ddad3a260e1de84ecf1
Und das Ergebnis an die xine Mailingliste. Hier läuft der erste Klipp auf jeden Fall durch mit der aktuellen CVS Version.
Ok, werde ich morgen machen, sobald ich wieder wach bin.
Der Puffer ist öfters auch schneller leer, als aus dem Netz nachgeladen werden kann, trotz DSL-Verbindung. -> Absturzgrund?
Unwahrscheinlich, dass das derartige Probleme hervorruft. Du kannst aber auf jeden Fall die Puffer hochsetzen (xine Einstellunge unter engine buffers.audio_num_buffers und buffers.video_num_buffers), dann wird mehr zwischengespeichert und Spitzen z.B. bei dynamischen Bitraten können leichter ausgeglichen werden, dafür kanns aber beim start ein wenig länger dauern, bis die Puffer voll sind und die Sache losläuft.
Werde ich morgen (Oh, Mist, ist ja schon wieder morgen ;-) ) mal mit herumexperementieren. Ich kann die Effekte inzwischen besser beschreiben: Der Puffer läuft auf Null, wird dann wieder geladen, ein paar Sekunden werden abgespielt, dann Absturz. Das ganze passiert zu 80% beim Wechsel von einem Video zum nächsten. Machmal gibt es bei so einem Wechsel auch für ein paar Sekunden ein psychedelisches Farbenspiel zu sehen, zum Glück bin ich kein Epileptiker.
Wie kann man Programmen eine höhere Download-Bandbreite zuordnen? Die mögliche Kapazität wird jedenfalls nicht ausgenutzt. Ich habe das mit KInternet -> Datenübertragungsrate ansehen... überprüft.
Dann kanns natürlich auch am Server liegen, wenn der keine Reserven mehr hat und mit der Datenlieferung nicht hinterher kommt.
Der Beispiel-Stream hat mehrere Mirrors in verschiedenen Ländern, und der Absturz passiert bei allen. Soweit sie denn funktionieren :-)
Süßes Mädel ;-)
J-Pop-Mädels sind häufig Kitsch mit Zuckerguss pur, das scheint eine Grundvoraussetzung bei denen zu sein, und die meisten können, im Gegensatz zu sehr vielen Deutschen oder US Tralala-Tussis, sogar auch noch richtig singen. Grüße René
participants (2)
-
Manfred Tremmel
-
René Falk