[patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

  • Zitat

    Original von gda
    BlueIcE
    Wieso compilierst du ein File bei dem das Patchen nicht funktioniert hat?


    Gerald


    Auf der Seite vorher stand sowas in der Richtung das es gehen könnte weil die Buffer Geschichte nur Doppelt im CVS ist...
    Aber ja, du hast recht.. nicht wirklich sinnvoll :)

    Ubuntu/Jaunty (Kernel 2.6.28-15) VDR 1.7.9 (im Aufbau), xineliboutput 1.0.90-CSV mit Xine-VDPAU r284 + durchflieger Patch | ASUS M3N78-EM, DVB-S Nexus 2.1, PSOne TFT, IR-Einschalter, Atmolight

  • Hi durchflieger,


    Zitat

    Originally posted by durchflieger
    im ersten Artikel des Thread steht jetzt der Patch gegen den aktuellen CVS Stand des xineliboutput sowie der Patch gegen xine-vdpau r284 bereit.
    Ist allerdings von mir nicht getestet.


    vielen Dank fuer die Patches:tup


    Meine Testumgebung:
    Graka: EN8400GS SILENT/HTP/512M
    NVIDIA-Linux-x86_64-185.18.36-pkg2.run
    xine-vdpau-r284
    vdr-xineliboutput-cvs-20090926163500
    xineliboutput-head-vdpau-support-v9.diff.gz
    xine-vdpau-r284-crop-v9.diff.gz


    Cropping funktioniert zumindest mit SD Material einwandfrei.


    - sparkie


    WICHTIG ist aber bei der derzeitigen CVS xineliboutput Version der Zusatzpatch im Anhang.
    Das SCR Handling, wie es sich derzeit im CVS befindet, funktioniert zusammen mit VDPAU nicht.
    Es kommt zu den vielzitierten Ton/Bildaussetzern bei Live-TV. Wiedergabe von Aufzeichnungen ist nicht betroffen.

  • Zitat

    Original von sparkie
    ...


    WICHTIG ist aber bei der derzeitigen CVS xineliboutput Version der Zusatzpatch im Anhang.
    Das SCR Handling, wie es sich derzeit im CVS befindet, funktioniert zusammen mit VDPAU nicht.
    Es kommt zu den vielzitierten Ton/Bildaussetzern bei Live-TV. Wiedergabe von Aufzeichnungen ist nicht betroffen.


    Kann man nicht alternativ das SCR Handling in der VDR setup.conf mit xineliboutput.Advanced.LiveModeSync = 0 einfach abschalten?


    Gruss
    durchflieger

  • Zitat

    Originally posted by durchflieger
    Kann man nicht alternativ das SCR Handling in der VDR setup.conf mit xineliboutput.Advanced.LiveModeSync = 0 einfach abschalten?


    sehr gut, daran habe ich gar nicht mehr gedacht.


    Sieht so aus, als wenn das alternativ ebenfalls (noch) funktioniert. Aber dann fehlt wieder
    jegliche Synchronisation mit dem Live-Stream. Was frueher oder spaeter ebenfalls zu Framedrops
    fuehren duerfte.


    Es muesste mal das gesamte Bufferhandling von xineliboutput im Live-Betrieb debugged werden. Es gibt da ja
    seit Monaten immer wieder Probleme.


    Mit FRC-VGA2SCART laeuft die CVS xineliboutput Version einwandfrei. Sowohl Live-TV als auch Wiedergabe von Aufzeichnungen.


    Jetzt, als ich mich zum ersten Mal mit VDPAU beschaeftige sehe ich aber , dass es mit VDPAU bei Live Betrieb wieder mal Buffer-Probleme gibt.


    Die sich fuer's erste aber, wie oben beschrieben, weitgehend kaschieren lassen.


    - sparkie

  • Zitat

    Original von durchflieger
    @Ioannis
    Bitte poste die Callstacks doch mal hier.


    Die Datei mit den ursprünglichen Callstacks habe ich versehentlich überschrieben, aber ich habe heute
    gleich ein paar neue produziert. Da tauchen jetzt zwar etwas andere Callstacks auf als die, die ich ursprünglich hatte, aber vieleicht kannst Du ja daraus trotzdem was erkennen.

  • So, ich habe jetzt mein System auch mal auf den aktuellen stand aktualisiert, d.h:
    nvidia-driver-185.18.36
    xine-vdpau-r284
    vdr-xineliboutput-cvs-20090926163500
    xineliboutput-head-vdpau-support-v9.diff
    xine-vdpau-r284-crop-v9.diff
    revert_src.patch


    Nach meinen ersten Zapping Testläufen schauts so aus:
    Es ist insgesammt schon stabiler geworden, anzahl der segfaults ist deutlich zurückgegangen.
    Konnte bisher nur zwei mir der neuen SW provozieren:

    Code
    #0  0x00007fb90a15d45e in _int_free (av=0x7fb90a430a00, mem=<value optimized out>) at malloc.c:4726 4726    malloc.c: No such file or directory.         in malloc.c (gdb)
    bt 
    #0  0x00007fb90a15d45e in _int_free (av=0x7fb90a430a00, mem=<value optimized out>) at malloc.c:4726
    #1  0x00007fb90a15f278 in _int_realloc (av=0x7fb90a430a00, oldmem=0x12b8ec0, bytes=<value optimized out>) at malloc.c:5107 
    #2  0x00007fb90a160851 in *__GI___libc_realloc (oldmem=0x12b8ec0, bytes=11752) at malloc.c:3708
    #3  0x00007fb8fbcdabbc in parse_code (this_gen=0xd41d50, buf=0xd3fad0 "", len=3525) at vdpau_mpeg12.c:515 
    #4  0x00007fb8fbcdaf53 in vdpau_mpeg12_decode_data (this_gen=0xd41d50, buf=<value optimized out>) at vdpau_mpeg12.c:814 
    #5  0x00007fb90a885213 in video_decoder_loop (stream_gen=<value optimized out>) at video_decoder.c:382 
    #6  0x00007fb909ed7097 in start_thread (arg=<value optimized out>) at pthread_create.c:297 
    #7  0x00007fb90a1b277d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #8  0x0000000000000000 in ?? () (gdb)


    Code
    #0  vdpau_gui_data_exchange (this_gen=0x0, data_type=<value optimized out>, data=0xd03d50) at video_out_vdpau.c:1990 1990	video_out_vdpau.c: No such file or directory. 	in video_out_vdpau.c (gdb)
     bt
    #0  vdpau_gui_data_exchange (this_gen=0x0, data_type=<value optimized out>, data=0xd03d50) at video_out_vdpau.c:1990 
    #1  0x00007f32d56590c9 in atmo_grab_loop (port_gen=0xc67620) at xine_post_atmo.c:576 
    #2  0x00007f32e1347097 in start_thread (arg=<value optimized out>) at pthread_create.c:297 
    #3  0x00007f32e162277d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 
    #4  0x0000000000000000 in ?? ()


    Dafür ist ein neues Fehlerbild hinzugekommen, da wo sonst die restlichen segfaults sonst zugeschlagen hätten, friert jetzt stattdessen das frontend vdr-sxfe ein. D.h. das letzte TV-Bild bleibt eingefroreren stehen und weiter passiert nix. Der VDR selber läuft 1a weiter und lässt sich dank graph-lcd am Parallelport auch noch prima bedienen. ;) Das Problem heilt sich wenn ich den vdr-sxfe thread kille und neustarte.


    Ich hab mich auch mal im eingefrorenen Zustand mit dem gdb an den Thread attached, das ist der Callstack dazu:

    Code
    0x00007f8799eaf5d6 in *__GI___poll (fds=0x7fffa410d5f0, nfds=1, timeout=50) at ../sysdeps/unix/sysv/linux/poll.c:87 87      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.         in ../sysdeps/unix/sysv/linux/poll.c (gdb) bt 
    #0  0x00007f8799eaf5d6 in *__GI___poll (fds=0x7fffa410d5f0, nfds=1, timeout=50) at ../sysdeps/unix/sysv/linux/poll.c:87 
    #1  0x00000000004071ee in sxfe_run (this_gen=<value optimized out>) at xine_sxfe_frontend.c:1595 
    #2  0x0000000000412631 in main (argc=<value optimized out>, argv=0x7fffa410dc58) at xine_frontend_main.c:811
  • Und noch ein paar vdr-sxfe Exceptions beim Zappen gehabt:


    Code
    #0  0x00007f31b9579205 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. 	in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0  0x00007f31b9579205 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 
    #1  0x00007f31b957a57e in *__GI_abort () at abort.c:88 
    #2  0x00007f31b95b2de7 in __libc_message (do_abort=2, fmt=0x7f31b965aba0 "*** glibc detected *** %s: %s: 0x%s ***\n")     at ../sysdeps/unix/sysv/linux/libc_fatal.c:170 
    #3  0x00007f31b95b80bd in malloc_printerr (action=2, str=0x7f31b9658142 "corrupted double-linked list",      ptr=<value optimized out>) at malloc.c:5994 
    #4  0x00007f31b95b947d in _int_free (av=0x7f31b988ca00, mem=<value optimized out>) at malloc.c:4726 
    #5  0x00007f31b95b9a76 in *__GI___libc_free (mem=0x6) at malloc.c:3625 
    #6  0x00007f31ad6453fc in atmo_grab_loop (port_gen=0xc66ff0) at xine_post_atmo.c:639 
    #7  0x00007f31b9333097 in start_thread (arg=<value optimized out>) at pthread_create.c:297 
    #8  0x00007f31b960e77d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 
    #9  0x0000000000000000 in ?? ()


  • @Ioannis


    erstmal danke für deine Analysen. Das Problem ist offenbar eine korrupierte Heap-Speicherverwaltung. Die eigentliche Fehlerquelle läst sich da leider nicht so einfach rausfinden. Man müsste den vdr-sxfe mal unter Kontrolle des valgrind Tool (oder ähnlichen) ausführen.
    Könntest du bitte mal den Test mit im Setup abgeschalteten autocrop und ohne das atmo-plugin ausführen um die Fehlerursache noch ein wenig einzugrenzen.


    Gruss
    durchflieger

  • @Ioannis


    so ich habe mal in meiner Testumgebung (xineliboutput v1.0.4, xine-vdpau r284) mit valgrind getestet und siehe da es gibt ein Problem im xine atmo plugin. Beim umschalten von Kanälen kommt es in dem Plugin zu Zugriffen auf bereits freigegebenen Speicher. Obwohl das hier bei mir nicht zu Segfaults führte (habe auch mal mit automatischer svdrp Kanalumschaltung bin Kanal 100 laufen lassen), kann es durchaus in deiner Umgebung zu abstürzen führen.
    Hier: Natives Xine Atmolight plugin findest du jetzt Version 0.2 des Plugin bei dem der Fehler gefixt ist.
    Wäre schön wenn du das nochmal testen könntest.


    Gruss durchflieger

  • Hallo,


    das ist ja klasse das Du was in der Richtung gefunden hast, werde ich gleich mal testen. :)


    Ich habe heute auch mal mit andern Konfiguration getestet, d.h. OHNE atmoplugin und das automatische 4:3->16:9 cropen AUS. Ergebnis: Läuft sehr stabil, test lief länger durch als alle anderen bisherigen tests zusammen. Anzahl Segfaults = 0. Picture freeze=1.


    Dann habe ich das automatische croppen wieder aktiviert. Das führte schon in kurzer Zeit zu: Segfaults = 3, Picture freeze=3.


    Das hier sind die dazugehörigen Backtraces:




    Ohne von dem vdpau code auch nur nen Hauch einer Ahnung zu haben, fällt mir hier auf das in jedem Callstack die Funktion vdpau_update_frame_format() auftaucht, und in zwei von dreien die Funktion autocrop_get_frame(). Das richt ja schon verdächtig danach das da in der Gegend auch noch ne Baustelle offen ist. ;)


    Ich werde jetzt erstmal das neue xine atmolight plugin testen (mit deaktiviertem 4:3/16:9 crop) und dann die Ergebnisse hier posten.

  • Zitat

    Original von durchflieger
    Hier: Natives Xine Atmolight plugin findest du jetzt Version 0.2 des Plugin bei dem der Fehler gefixt ist.
    Wäre schön wenn du das nochmal testen könntest.


    So, habs mal ordentlich gequäult und es sieht sehr gut aus, keinen einzigen segfault mit der neuen Version vom xine-atmolight-plugin gehabt. :)

  • @Ioannis


    deine Segfaults in Verbindung mit dem autocrop bekomme ich in meiner Testumgebung nicht reproduziert. Auch das valgrind zeigt keine Probleme auf.


    Könntest du mal bei dir das vdr-sxfe unter valgrind Kontrolle laufen lassen?


    Dazu das Paket valgrind installieren.
    Dann einfach:


    valgrind --log-file=sxfemem.log vdr-sxfe .....


    ausführen.
    Nach einem Segfault dann die Logdatei mal hier einstellen.
    Das vdr-sxfe und die xine-lib sollten mit "-g -O0" übersetzt sein.


    Gruss
    durchflieger

  • Hi,


    werde ich mal ausprobieren. Werde aber wohl zu ausgiebigen tests nicht vor Anfang nächster Woche kommen. Valgrind habe ich schon installiert und auch me ne unoptimierte debug version von xine-lib/vdr-sxfe gebaut und mal mit valgrind gestartet, meine fresse bremst das vdr-sxfe aus, ist dann ja nur noch ne verpixelte Standbildshow. Ich hoffe mal das sich das timing dadurch nicht so ändert das der Fehler nicht mehr auftritt, aber mal schauen. ;)

  • So, hab die -O0 -g gebaute xinelib/vdr-sxfe Variante jetzt stundenlang mit und ohne valgrind im Test gehabt, aber die Segfaults tretten in dieser Konfiguration nicht mehr auf. Was geblieben ist sind die "Hänger", also das vdr-sxfe nur ein Standbild produziert und neu gestartet werden muß damits wieder normal weitergeht.


    Und nun? Machts Sinn valgrind auf O2 optimierten Code loszulassen? Oder mal mit O1 probieren? Fragen über Fragen... :schiel

  • @Ioannis


    danke für die valgrind logs.
    Man kann erkennen das offenbar was schief läuft beim Zugriff auf die Frameinhalte. Das dürfte wohl der Auslöser für die Segfaults sein.
    Warum das bei dir passiert ist mir leider noch nicht klar. Es scheint wohl bei Frames zu passieren die im standard Frame-Format (yv12) vorliegen, also nicht durch den vdpau decoder generiert wurden.
    Ich habe da so einen "Verdacht" das evt. ungerade cropping Zeilen der Auslöser sein könnte. Im Anhang findest du einen Patch für die cvs Version des xineliboutput beim dem ungerade Zeilen vermieden werden.
    Wäre schön wenn du den mal ausprobieren könntest.


    Weiterhin benötige ich die beim Test verwendeten Einstellungen zum autocrop aus der setup.conf des VDR.


    Gruss
    durchflieger

  • Alles klar, ich werde dann mal das Diff einspielen und testen.
    Die Autocrop Einstellungen bei mir sind wie folgt:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!