VDR Portal

Hi,

Quoted

Original von reufer
Ich danke Dir ausserdem für die Hinweise bezüglich dem ffmpeg-Problem! Da heisst es nun also warten... entweder auf nen Patch oder auf den UPS-Mann der mir Morgen meine HDe bringt. Mal schauen, was eher funktioniert.

wer mag, kann ja mal den beiliegenden FFmpeg-Patch (EDIT: Patch entfernt, weil nun bereits in FFmpeg enthalten) ausprobieren. Ich bin mir zwar nicht sicher, ob der Patch zu 100 % korrekt ist, aber zumindest bleiben nach kurzer Zeit die "B picture" Meldungen bei multithreaded decoding aus.

Es sieht aber danach aus, als ob noch ein paar B pictures zuviel verworfen würden, die eigentlich schon ordnungsgemäß dekodiert hätten werden können. Aber um das zu lösen kenne ich mich in FFmpeg nicht gut genug aus.

Bye.

Hi,

Quoted

Original von duc
reicht es, wenn ich ffmpeg nach dem patch neu übersetze und installiere oder muss ich xine-lib und xine-ui auch neu backen?

Wenn durch den Patch die von xine-lib verwendeten Datenstrukturen und Schnittstellen nicht betroffen sind (vgl. ABI und API in Wikipedia), dann reicht es aus, nur FFmpeg neu zu bauen.

Im allgemeinen ist es wohl schwierig, diese Eigenschaft in den Änderungen erkennen zu können, und von daher ist es sinnvoll, zumindest xine-lib neu zu bauen, um etwaigen Abstürzen aufgrund geänderter ABI aus dem Weg zu gehen.

Im konkreten Fall wurde die ABI nicht angetastet. Somit reichte es aus, nur FFmpeg zu übersetzen (weder "make clean" noch "configure" waren notwendig).

Quoted

Original von duc
das bildruckeln ist zwar besser geworden, aber der ton geht immer noch nach wenigen sekunden weg.

ich häng mal noch das xine log /2 teile, weil einer zu gross war)mit dran. es geht vom start bis zu dem punkt, an dem der ton weg geht.

Mir ist klar, dass sich dieses Verhalten auf meiner Maschine zeigt, weil mein P4 2.8 GHz HT definitiv zu langsam ist, aber deine Maschine sollte doch eigentlich schnell genug dafür sein.

Der erste Teil des Logs zeigt kurz vor Ende ein "set_speed 125000", d. h. die Abspielgeschwindigkeit wird auf 1/8 der normalen Geschwindigkeit gesetzt. Ab diesem Zeitpunkt ist der Ton natürlich stumm, sonst würde er stark verzerrt.

Sinn und Zweck dieser Geschwindigkeitsänderung ist folgender: da der Stream mit 8/8 (also normaler Geschwindigkeit) vom Satelliten kommt, baut sich so ein Puffer auf, der benötigt wird, um später Latenzzeiten in der Verarbeitungskette von SAT-Karte bis Grafikkarte ausgleichen zu können. Wenn der Puffer groß genug ist, wird dann die Wiedergabegeschwindigkeit wieder auf normal gesetzt. Ab dann sollte eigentlich wieder der Ton zu hören sein.

Im zweiten Teil des Logs tauchen z. B. folgende Zeilen auf:

Hier wird also auf normale Geschwindigkeit geschaltet, doch leider liegen zu diesem Zeitpunkt nur Audiodaten vor. Die Ausgabe "buffer usage:" ist dabei wie folgt zu interpretieren: InVid, InAud, OutVid, OutAud, stream. Die ersten beiden Felder geben also darüber Auskunft, wieviele gefüllte Datenpuffer darauf warten, dekodiert zu werden. Folglich handelt es sich bei den nächsten beiden Feldern um die Anzahl an dekodierten Frames, welche auf die Wiedergabe warten.

Dass man den Ton jedoch nicht hört, liegt wohl daran, dass xine bereits jede Menge "bad (video) frames" mitbekommen hat und diese gegen die "audio frames" synchronisieren möchte. Dass es zu diesem Zeitpunkt bad frames gibt, ist normal -- schließlich steigen wir mitten in den Videostream ein, und die erfolgreiche Dekodierung kann erst mit einem I-Frame beginnen.

Dann folgt eine Stelle mit folgenden Zeilen:

und danach sieht man, dass die Anzahl dekodierter Videoframes zunimmt. Für eine flüssige Wiedergabe müssen durchgehend mindestens 3 Frames vorliegen. Doch leider fallen nun die Zahlen der dekodierten Frames wieder ab, bis schließlich Zeilen wie auftauchen.

Das ist ein Indiz dafür, dass der Rechner wohl zu langsam ist. Laut Aufruf von xine ist der Deinterlacer eingeschaltet. Kannst du ihn mal durch Drücken der Taste "i" deaktivieren und das Szenario nochmals durchspielen?

Was auch noch was bringen dürfte: man sollte für die eingesetzte CPU optimieren lassen. Im Falle von FFmpeg schaut das für meinen P4 so aus:. Was für "--arch" möglich ist, steht in configure:Für "--cpu" muss man in "man gcc" nachschauen (suche nach "pentium4"):

Mitunter macht es auch Sinn, xine-lib (und weil wir schon dabei sind, auch xine-ui) ebenfalls zu optimieren. Hier lautet die Vorgehensweise (wieder am Beispiel für meinen P4): wobei für "-march" der Wert verwendet werden kann, welcher bei FFmpeg für "--cpu" angegeben wurde.

Bye.

Hi,

Quoted

Original von tomsat
Was ich nicht ganz verstanden habe, ist wie oder wo man die CPU-Optimierungen bei Xine-Lib und Xine-Ui vornimmt. - Vielleicht kann mir da jemand weiterhelfen.

Das Beispiel von oben bedeutet, dass dem bekannten Aufruf von configure einfach das Setzen der Umgebungsvariablen voranzustellen ist.

Quoted

Original von tomsat
Beim Kompilieren von FFmpeg wird mir unter Audio 'oss-muxer' angezeigt. Ist das korrekt? Müsste da nicht was von Alsa stehen? Soweit ich mich erinnere hab ich mal 'Alsa-base' (Debian) deinstalliert, evt. benötige ich das ja?

Das ist für unsere Zwecke nicht relevant, da xine in diesem Fall FFmpeg nur für Video (H.264) hernimmt.

Bye.

Hi,

Quoted

Original von duc
ich häng mal noch das xine log /2 teile, weil einer zu gross war)mit dran. es geht vom start bis zu dem punkt, an dem der ton weg geht.

Das Log zeigt unter anderem:

Meldet sich eine "core2" CPU wirklich als "Pentium D"?

Bye.

Hi,

Quoted

Original von duc
ach ja, wegen xine bauen. im wiki steht für xine-lib folgendes drin:
./autogen.sh --with-external-ffmpeg --disable-dxr3 && make && make install && ldconfig

und für xine-ui:
./autogen.sh --enable-vdr-keys && make && make install

da kann ich den parameter -march= nicht angeben, erzeugt nen fehler.

Gut, autogen.sh ruft abschließend configure auf. Von daher kann man die Umgebungsvariablen auch autogen.sh voranstellen.

Oder man ruft autogen.sh nur mit 'noconfig' auf und anschließend configure mit den restlichen Argumenten. Also in etwa so: Die Umgebungsvariablen müssten dann zwischen '&&' und './configure' eingetragen werden.

Bye.

Hi,

Quoted

Original von Uwe
Nun geht HDTV mit Bild und Ton ... Probleme gibt es teilweise, wenn man das Menu öffnet, da scheint fürs OSD noch recht viel Prozessor Power drauf zu gehen

Nun, das 720x576 OSD von VDR ist natürlich vollflächig "dirty" und muss komplett hochskaliert werden auf 1920x1080. Das Verschieben des Cursors erzeugt nur eine kleinen Bereich, der aktualisiert werden muss. Scrollen verursacht wieder einen großen :-(

Daneben muss natürlich auch das "riesen" OSD (mit Deinterlacer: 50 mal pro Sekunde) in das Videobild geblendet werden (erzeugt die 5-fache Last eines SD-OSD).

Quoted

Original von Uwe
Zumindest scheint es der richtige Weg zu sein, vorhandene Cores zu nutzen, wenn es möglich ist

Falls sich ein Core noch langweilt: auf der xine-ML wurde mal ein Post-Plugin vorgestellt, welches andere Post-Plugins in einem eigenen Thread ablaufen lässt. Das würde den Video-Dekoderthread entlasten, in dem normalweise das Deinterlacing durchgeführt wird.

http://www.nabble.com/Threading-of-post-…to10632990.html

BTW: die Angabe von '-D...' an xines Kommandozeile kann auch als '--post ...' geschrieben werden. Bei aktiviertem Deinterlacer baut xine implizit das Deinterlace Plugin am Anfang der Postprocess-Kette ein, und obiges "multithreading" Plugin könnte nicht wirken.

Bye.