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

  • :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 :doof

  • 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

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

    --
    Dipl.-Inform. (FH) Reinhard Nissl
    mailto:rnissl@gmx.de

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von rnissl ()

  • 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
    1. 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

    "Backups are for whimps. Real men upload their stuff on the Internet
    and let the world mirror it".


    --Linus Torvalds

  • 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

  • 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

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

    Dateien

    • xinelog.txt

      (34,67 kB, 109 Mal heruntergeladen, zuletzt: )
    • xinelog2.txt

      (40,83 kB, 118 Mal heruntergeladen, zuletzt: )

    Board: ASUS AT5IONT-I, 4 GB Ram
    DVB Karte: Tevii S480
    40 GB ssd als boot/systemplatte (2,5" Wechelrahmen, um auf einer anderen Platte ein Testsystem zu installieren)
    3x2TB hdd für /media
    Medion X10 Fernbedienung
    yaVDR 0.5
    Samsung UE46D5700

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von duc ()

  • 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
    1. buffer usage: 1, 0, 0, 17, 0x8585988
    2. 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
    1. set_speed 125000
    2. set_speed 1000000
    3. 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
    1. buffer usage: 498, 0, 0, 0, 0x8585988
    2. video_out: Verwerfe Bild mit pts 1088051, weil es zu alt ist (Unterschied: 3696).
    3. 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
    1. configure ... --arch=i686 --cpu=pentium4 ...

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

    Code
    1. case "$arch" in
    2. i386|i486|i586|i686|i86pc|BePC)
    3. arch="x86_32"
    4. enable fast_unaligned
    5. ;;
    6. x86_64|amd64)

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

    Code
    1. pentium4, pentium4m
    2. Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set support.
    3. prescott
    4. Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3 instruction set support.
    5. nocona
    6. 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
    1. 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.

  • 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+

  • 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

    Board: ASUS AT5IONT-I, 4 GB Ram
    DVB Karte: Tevii S480
    40 GB ssd als boot/systemplatte (2,5" Wechelrahmen, um auf einer anderen Platte ein Testsystem zu installieren)
    3x2TB hdd für /media
    Medion X10 Fernbedienung
    yaVDR 0.5
    Samsung UE46D5700

  • 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

    Hardware: Asus P5VD2-X, Core2Duo 2.4 Ghz, 1GB Ram, Geforce 7600 GS, 1x ATA 150, 1x ATA 400GB, 1x SATA 400GB, 1x SATA 500GB, 2x USB 400 GB, 1x TT 1500-C, 2x TT Skystar HD, 1x Reel Extension HD
    FB: Artic IR-Einschalter mit Topfield 5000 Fernbedienung
    Software: Ubuntu 2.6.22-15, VDR 1.7.0 mit Extensions-Patch-62, Multiproto
    TV: Philips 32PF9966/10

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

  • 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
    1. model name : Intel(R) Pentium(R) D CPU 3.00GHz


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


    Bye.

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

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Uwe ()

  • 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 :(

    TV VDR: GigaByte 965DS3, Intel C2D 2,4GHz, 1GB RAM, HD Ext, 2x TT PCI S-3200 DVB-S2, ATI Radeon HD2600, VDR 1.6.0-HDTV, Gentoo 2007.1, Kernel 2.6.24
    TV VDR: AOpen 945 GTM-VHL, Intel C2D-M 1,83GHz, 2GB RAM, HD Ext, 1x TT PCI S-3200 DVB-S2, Intel GMA950, VDR 1.6.0-HDTV, Gentoo 2007.1, Kernel 2.6.24
    VDR Server: Supermicro 370DE6, 2x Intel P3 866 MHz, 2GB RAM, TT-DVB-s Rev. 1.3, TT S1100 budget, KNC1 budget, TT S1401, 2x 500GB WD HDs, 1x 9GB U160 SCSI

  • Zitat

    Original von rnissl
    Das Log zeigt unter anderem:

    Code
    1. 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.

    Board: ASUS AT5IONT-I, 4 GB Ram
    DVB Karte: Tevii S480
    40 GB ssd als boot/systemplatte (2,5" Wechelrahmen, um auf einer anderen Platte ein Testsystem zu installieren)
    3x2TB hdd für /media
    Medion X10 Fernbedienung
    yaVDR 0.5
    Samsung UE46D5700

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von duc ()

  • 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
    1. ./autogen.sh noconfig && ./configure ...

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


    Bye.

  • 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! :D
    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 ;)

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

  • 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