HDTV (DVB-S2 und h264) mit VDR und Xine-Plugin

ollo · 19. Dezember 2007

:moin,

danke Reinhard!

Hat sonst noch jemand die Probleme mit der aspect ratio / den Eierköpfen bei anamorph sendenden Kanälen?

Gruß, ollo

*Edit*

Hat sich erledigt, lag an den Einstellungen von Xine

reufer · 19. Dezember 2007

Hallo Reinhard

Zitat

Original von rnissl
Ne, mit externem Audio-Dekoder. Ich habe nun die prinzipielle Funktionsfähigkeit meines externen Dekoders über SPDIF hergestellt und wäre für weitere Tests gerüstet. Es ist ja bereits bekannt, dass sich vdr_audio und upmix_mono nicht mit "speaker arragement = pass through" vertragen. Das werde ich wohl demnächst beheben.

Achso. Nein, bei meinem Testrechner hängt kein DD-Decoder dran, das Signal greife ich ganz ordinär analog ab - mein Problem mit dem Ton bezieht sich auf 2.0 Stereo. DD habe ich im VDR-Setup abgestellt, da ich 5.1 gar nicht intern decodieren will.

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.

Gruss
Thomas

rnissl · 19. Dezember 2007

Hi,

Zitat

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.

Quacks · 20. Dezember 2007

Zitat

wer mag, kann ja mal den beiliegenden FFmpeg-Patch 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.

Ich habe gerade einmal ffmpeg mittels:

Code

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg-cvs-20-12-2007

ausgecheckt und den Patch anwenden wollen. Dieser wurde rejected, aber ich hab das ganze dann einfach ohne Patch probiert und bekomme nun die ersten 1-5 Sekunden noch die Fehler, anschließend sind diese dann weg und ich bekomme nur noch die Buffer Usage angezeigt. Lediglich bei heftigen Bildwechseln bremst mein System aus, dies liegt aber vermutlich daran, das der C2D mit 1,8 GHz zu langsam ist.

Getestet habe ich das ganze mit einem DVB-C VDR-1.5.12 inkl. h.264 Patch.

cu,

Quacks

QBert · 20. Dezember 2007

Reinhards Patch (h264-skip_b_picture_multithreaded.diff) ist seit heute im FFMPEG CVS:
http://lists.mplayerhq.hu/pipe…2007-December/010783.html

Erhöht bei mir um einiges die Bildstabilität (Vielen Dank Reinhard).
Nur starke Bewegtbilder ruckeln noch (auf AMDX2 6000, 1GB RAM).
Ton setzt dann auch ab und zu aus.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11487 tv01 20 0 251m 113m 63m S 146 11.2 23:33.07 vdr-sxfe
11457 vdr 20 0 198m 36m 7432 S 13 3.6 2:04.00 vdr
11479 root 20 0 93524 76m 64m S 8 7.5 1:22.11 Xorg
11744 root 20 0 2308 1084 848 R 0 0.1 0:00.12 top

Gruss
QBert

reufer · 21. Dezember 2007

Hallo Reinhard

Zitat

Original von rnissl
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.

Vielen Dank für Deine Arbeit, das Problem mit den Bildstörungen ist behoben!
Allerdings scheint auch bei mir mein Athlon X2 6000 bei schnellen Bildfolgen ein wenig überfordert zu sein...

Gruss
Thomas

duc · 21. Dezember 2007

frage:
reicht es, wenn ich ffmpeg nach dem patch neu übersetze und installiere oder muss ich xine-lib und xine-ui auch neu backen?
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.

rnissl · 21. Dezember 2007

Hi,

Zitat

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).

Zitat

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:

Code

buffer usage:   1,  0,  0, 17, 0x8585988
set_speed 1000000

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:

Code

set_speed 125000
set_speed 1000000
audio_out: inserting 14484 0-frames to fill a gap of 27166 pts

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

Code

buffer usage: 498,  0,  0,  0, 0x8585988
video_out: Verwerfe Bild mit pts 1088051, weil es zu alt ist (Unterschied: 3696).
buffer usage: 498,  0,  0,  0, 0x8585988

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:

Code

configure ... --arch=i686 --cpu=pentium4 ...

. Was für "--arch" möglich ist, steht in configure:

Code

case "$arch" in
    i386|i486|i586|i686|i86pc|BePC)
        arch="x86_32"
        enable fast_unaligned
    ;;
    x86_64|amd64)

Für "--cpu" muss man in "man gcc" nachschauen (suche nach "pentium4"):

Code

pentium4, pentium4m
               Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set support.


           prescott
               Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3 instruction set support.


           nocona
               Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support.

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):

Code

CFLAGS='-g3 -O3 -march=pentium4' /path/to/configure ...

wobei für "-march" der Wert verwendet werden kann, welcher bei FFmpeg für "--cpu" angegeben wurde.

Bye.

billi · 21. Dezember 2007

Hallo

ich habe mein System akutalisiert.

xinelib auf den 20.12.2007
ffmpg auf den 20.12.2007
xne-ui auf das gleiche Datum
vdr auf 1.5.12 mit den Patches von Reinhard

Danach in meiner Homedir die Directory von .xine gelöscht
vdr gestartet und xine gestartet

Danach 2 Einträge geändert

Einstellungen Audio

synchronsation.slow_fast_audio bitte Haken Setzen

Einstellung video (ffmpeg) wie schon reinhard berichtet hat.

Ich habe dadurch keine Tonaussetzer mehr.

Nur noch Probleme mt ASTRA HD und ASTRAHD+

duc · 23. Dezember 2007

hallo,

herzlichen dank für die super erklärung. jetzt verstehe ich etwas besser wie das ganze zusammenspiel funktioniert. ich habe gestern abend mal ffmpeg mit den entsprechenden optimierungen neu gebaut und bei der gelegenheit auch xine-lib und xine-ui. es wurde etwas besser, dauert jetzt etwas länger bis der ton verschwindet, aber es passiert nach wie vor. entweder sind die codecs noch nicht effinzient genug oder ich muss mich damit abfinden, dass meine hardware doch nicht genug leistung hat.
ich weiss noch nicht, ob ich noch dazu komme weitere tests durchzuführen und log files zu erstellen, ist jedes mal ein heidenaufwand für mich. muss den rechner aus dem arbeitszimmer rüber ins wohnzimmer schleppen, alles umstöpseln und so weiter. mein "produktiver" vdr hat leider erst recht nicht genug leistung, deshalb muss ich das mit meinem arbeitsrechner testen...

bin ab donnerstag eh erst mal für 5 wochen im urlaub, vielleicht gibts bis ich wieder da bin ja auch was neues auf dem gebiet.

schöne grüße,
duc

tomsat · 23. Dezember 2007

Hallo zusammen,
ich möchte mich auch erstmal für eueren unermüdlichen Einsatz danken! Hab auch alles neu kompiliert und inzwischen auch Alsa wieder zum laufen gekriegt. Jetzt läuft alles viel besser! Bei Pro7 HD hab ich jetzt Ton - zumindest bis jetzt Bei Anixe und Sat1 HD hab ich allerdings nur kurz Ton. Bei Suisse HD gar kein Ton. Wenn der Ton weg ist so kommt er beim Umschalten auf z.B. Sat1 HD jetzt wieder. - Das war bis anhin nicht der Fall. Auch bei nicht HD Sendern scheint der Ton jetzt zu funktionieren.

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.

Die aktuelle Xine-Ui habe ich übrigens nicht kompilieren können. -Mit einem Error abgebrochen. Mit einer ein paar Tage älteren Version ging's dann doch noch..

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?

Gruss und erholsame Feiertage!

tomsat

rnissl · 23. Dezember 2007

Hi,

Zitat

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.

Zitat

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.

rnissl · 23. Dezember 2007

Hi,

Zitat

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:

Code

model name      : Intel(R) Pentium(R) D CPU 3.00GHz

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

Bye.

Uwe · 23. Dezember 2007

Hallo,

ich kann nun auf einem AMD X2 4200+ und durch die Optimierungen von FFMPEG mit xine Pro7HD, SAT1HD und Anixe darstellen. Der Prozessor scheint aber immer noch ein wenig zu langsam zu sein.
Könnte man nun durch Verwendung eines Quad Core eine Verbesserung erwarten? Wenn ich das richtig verstanden habe, scheint ein Quad Core bzw Dual Core bei Suisse HD nix zu bringen ...
Oder würde eine andere Grafikkarte was bringen? Derzeit verwende ich eine Onboard Grafik NVidia 7050 ...

Konni__ · 23. Dezember 2007

Meines wissens unterstüzt unter Linux bisher keine Grafikkarte die H264 Beschleunigung

Find ich recht ärgerlich, da unter Win HDTV (mit DVB Viewer und Cyberlinkcodec auf einer Radeon 2600) mit ollen 6 % Auslastung läuft

duc · 24. Dezember 2007

Zitat
Original von rnissl
Das Log zeigt unter anderem:
Code
model name      : Intel(R) Pentium(R) D CPU 3.00GHz
Meldet sich eine "core2" CPU wirklich als "Pentium D"?

ja, das ist ein pentium D. das war soweit ich weiss der erste dualcore prozessor von intel. die kiste ist ja auch schon wieder zwei jahre alt...

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.

rnissl · 24. Dezember 2007

Hi,

Zitat

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:

Code

./autogen.sh noconfig && ./configure ...

Die Umgebungsvariablen müssten dann zwischen '&&' und './configure' eingetragen werden.

Bye.

Uwe · 24. Dezember 2007

Zitat

Original von Uwe
ich kann nun auf einem AMD X2 4200+ und durch die Optimierungen von FFMPEG mit xine Pro7HD, SAT1HD und Anixe darstellen. Der Prozessor scheint aber immer noch ein wenig zu langsam zu sein.
Könnte man nun durch Verwendung eines Quad Core eine Verbesserung erwarten?
...

Nabend,

gesagt getan!
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
Na mal die Tage mir das ganze ein wenig anschauen.
Zumindest scheint es der richtige Weg zu sein, vorhandene Cores zu nutzen, wenn es möglich ist

rnissl · 25. Dezember 2007

Hi,

Zitat

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).

Zitat

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/Threadin…t-plugins-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.

mentox · 25. Dezember 2007

Moin,

nur mal so zur info, auf pro7 hd kam letztens ladykiller .. ich glaube gestern ... das lief auf meinem pentium D 3ghz super fluessieg mit noch luft.. frueher hats gehackt.. also da habt ihr (alle entwickler die da drann sitzen) supi arbeit geleistet ...

lg mentox

HDTV (DVB-S2 und h264) mit VDR und Xine-Plugin

Jetzt mitmachen!

Teilen