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

So hier kommt Teil 2...

Einmal der Patch (xine-lib-1.2-vdpau-extensions-v11-20100127.diff) für xine-lib aus dem cvs (02.03.2010). Und zum zweiten der Patch (xineliboutput-cvs-20100302-vdpau-extensions-v11+sosd.diff) für xineliboutput aus dem cvs (02.03.2010).

Außerdem hab ich noch genommen:
xine-ui-cvs-20090412200000.tar.bz2
vdr-xine-0.9.3.tgz
ffmpeg-cvs
Nvidia v195.36.08

[EDIT] Als Skin benutze ich skinenigmaNG aus dem cvs... [/EDIT]

Gruß
iNOB

iNOB

Zitat

Dann liegt das aber nicht an dem Patch.

Das Problem tritt (bei mir) aber nur in Verbindung mit dem Patch auf.
Muss vdr-xine-0.9.3 eigentlich auch immer noch gepatched werden?

Ich benutze vdr-xine-0.9.3 ungepatched. Der dort enthaltene Patch für die xine-lib ist in meinen Patch schon enthalten, also bitte weglassen.

Wie gesagt, bei mir rennt die Kombination anstandslos. Selbst heftiges Zappen alle 3 sec. zwischen HD Sendern bringt das Frontend nicht zu Absturz. Hab das gestern extra nochmal probiert und das mehr als 10 Mal hintereinander...

Gruß
iNOB

Mein vdr-xine ist auch ungepatched, dachte nur, dass das vielleicht das Problem war. Seltsam, am atmo POST Plugin liegt es auch nicht, die Abstürze beim Umschalten kommen auch ohne POST Plugin.

Zitat

Original von iNOB
So hier kommt Teil 2...

Einmal der Patch (xine-lib-1.2-vdpau-extensions-v11-20100127.diff) für xine-lib aus dem cvs (02.03.2010). Und zum zweiten der Patch (xineliboutput-cvs-20100302-vdpau-extensions-v11+sosd.diff) für xineliboutput aus dem cvs (02.03.2010).

Gruß
iNOB

Hi iNOB,

erstmal vielen Dank für die Patches. Schickst Du die Pacthes eigentlich auch gleich an die Entwickler von xine-lib und xineliboutput Plugin? Die könnten diesen doch gleich ins CVS mit aufnehmen was meinst Du dazu?

mapovi
Auch wenn man nur das vdr-xine Plugin benutzt, muss das xineliboutput Plugin installiert und gepatched sein! Einschalten darf man es natürlich nicht, bei Benutzung von xine als Frontend. Xine verwendet nämlich Teile von xineliboutput für das Cropping!!!

Eventuell ist ja das dein Denkfehler...

@sewn
ich bin kein Programmierer, deswegen kommt da von mir auch nix

Gruß
iNOB

Zitat

Eventuell ist ja das dein Denkfehler...

Der Denkfehler liegt definitiv vor. Ich werde mir jetzt mal meine xineliboutput Installation anschauen...

EDIT: xineliboutput ist korrekt gepatched, war aber aktiviert. Habe es deaktiviert, es hat sich aber nichts an der Problematik geändert.

Ich habe jetzt festgestellt, dass es bei mir scheinbar auch mit der Verwendung von text2skin und PearlHD zu tun hat. Ich vermute es läuft etwas mit der Skalierung falsch. Der Fehler tritt aber nur in Verbindung mit dem Patch auf.

Zitat

Original von iNOB
mapovi
Auch wenn man nur das vdr-xine Plugin benutzt, muss das xineliboutput Plugin installiert und gepatched sein! Einschalten darf man es natürlich nicht, bei Benutzung von xine als Frontend. Xine verwendet nämlich Teile von xineliboutput für das Cropping!!!
Eventuell ist ja das dein Denkfehler...

Das verstehe ich jetzt nicht so recht. Wozu ist das patchen des xineliboutput-plugins nötig damit das xine-plugin funktioniert? Verwendet das vdr-xine Plugin irgendwelche Libs die erst generiert werden wenn man auch das vdr-xineliboutput plugin gebaut hat?

ich habe bisher einfach nur das vdr-xine plugin gebaut&geladen und dann halt xine als Frontend gestartet. Das vdr-xineliboutput plugin wird in dem Fall überhaupt nicht von mir gestartet.
Ich habe jetzt mal die CVS xine-lib mit dem zu letzt geposteten xine-lib patch gebaut und habe auch das xine atmolight addon aktiviert. Jetzt schmiert das ganze bei Kanalwechsel sporadisch ab, das hier ist der Backtrace:

0 0x00007fd3f8537315 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 0x00007fd3f8537315 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fd3f8538811 in *__GI_abort () at abort.c:88
#2 0x0000000000498b71 in xitk_signal_handler ()
#3 <signal handler called>
#4 *__GI___libc_free (mem=0x20) at malloc.c:3687
#5 0x00007fd3e7be9da6 in vdpau_gui_data_exchange (this_gen=0x843310, data_type=<value optimized out>, data=0x125a410)
at video_out_vdpau.c:1927
#6 0x00007fd3e9cda970 in atmo_grab_loop (port_gen=<value optimized out>) at xine_post_atmo.c:571
#7 0x00007fd3f8865297 in start_thread (arg=<value optimized out>) at pthread_create.c:297
#8 0x00007fd3f85d58cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9 0x0000000000000000 in ?? ()

Zitat

Original von mapovi

Der Denkfehler liegt definitiv vor. Ich werde mir jetzt mal meine xineliboutput Installation anschauen...

EDIT: xineliboutput ist korrekt gepatched, war aber aktiviert. Habe es deaktiviert, es hat sich aber nichts an der Problematik geändert.

Ich habe jetzt festgestellt, dass es bei mir scheinbar auch mit der Verwendung von text2skin und PearlHD zu tun hat. Ich vermute es läuft etwas mit der Skalierung falsch. Der Fehler tritt aber nur in Verbindung mit dem Patch auf.

Alles anzeigen

.. warum stellst du nicht auf vdr-xine-0.9.3 um? das autocrop feature von durchflieger (xineplug_post_autocrop.so --> zB. /usr/local/lib/xine/plugins/1.25/post/xineplug_post_autocrop.so) nimmst du aus dem kompiliertem xineliboutput. das funktioniert hier sehr gut! (mit vdr-1.7.0 und jetzt 1.7.12 -- xinelib ist bei mir halt noch die aus der sig. und das autocrop auch noch von der alten xineliboutput-stable 1.0.4 ..)

gruß, ciax

Nabend zusammen,

mal kurz ein paar Fesstellungen von meiner Seite:

- mit der alten xine-vdpau-r286 und den df-patches auf xine-vdpau und xineliboutput und Verwendung von text2skin mit paerlHD und 2 weiteren internen Skins + vdr-xine-0.9.3 + grab-Patch => Absturz ab und zu beim Senderwechsel

Beim skinenigmanng gabs nie einen Absturz in der obigen Kombi

- mit neuer xine-lib-1.2 inkl. vdpau und den Patches von Inob auf die xine-lib und xineliboutput bei Verwendung von text2skin mit paerlHD und 2 weiteren internen Skins + vdr-xine-0.9.3 + grab-Patch => Absturz ab und zu beim Senderwechsel

Beim skinenigmanng gabs nie einen Absturz in der obigen Kombi

- mit neuer xine-lib-1.2 inkl. vdpau ohne die Patches von inob und ohne grab-Patch bei vdr-xine-0.9.3 => absolut rockstabel sowohl mit text2skin+paerlHd+2 weiteren internen Skins

Es liegt also an den Patches für die xine-lib. Ich habe auch schon versucht einen bt zu machen, aber der bringt kein fertiges Ergebnis, da der core nicht ganz geschrieben wird...

Noch ein bisschen Aufklärung, xineliboutput ist nötig, damit xine das Post-Plugin des xineliboutput zum Autocropping nutzen kann.

Ich hoffe mal mapovi findet den Fehler im text2skin, denn die beiden internen Skins haben auch das Absturzverhalten des PaerlHD. Die beiden Skins sind frisch aufgebaut in einer bisschen anderen sauberen Logik.

Gruß
Wolfgang

Hi

Ich hab hier genuegen backtraces von text2skin Abstuerzen, falls jemand Interesse hat
Das ist derzeit nicht zu gebrauchen

wbreu
schöne Zusammenfassung Hab mich schon die ganze Zeit gewundert, dass das bei mir funktioniert und bei euch nicht. text2skin ist zwar bei mir auch eingeschaltet, wird aber von keinem Skin benutzt, da ich wie bereits erwähnt lediglich den SkinenigmaNG verwende.

Fragt mich jetzt aber bitte nicht, ob die Abstürze von text2skin oder dem Cropping-Patch kommen...

Gruß
iNOB

Hallo,

wenn ich PearlHD/text2skin mit dem System in der Sig nutze, habe ich auch dauernd Abstürze beim mehrmaligen Wechsel von einem HD-Sender zu einem anderen.
Mit den beim VDR mitgelieferten Skins tritt das nie auf.

Gruß
goldbär

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.

Ich teste zur Zeit mal wieder xineliboutput mit vdpau zur Bildausgabe, die angesprochenen Probleme treten bei mir auch mit aktuellen Versionen statt.
Ist das Problem mit dem SCR Handling weiterhin vorhanden?

Edit: Hab den Patch mal auf die aktuellere Version angepasst. Ob er wirklich benötigt wird und was bringt teste ich gerade

Ob der Patch noch benötigt wird, wage ich zu bezweifeln. Ich glaube irgendwo gelesen zu haben, dass die Änderungen schon in den Code eingeflossen sind...

Gruß
iNOB

Ob mit oder ohne Patch weiterhin die gleichen Probleme, ich werde aber mal probieren das SCR-Tuning komplett zu deaktivieren bei Live-TV.

Das komplette deaktivieren der scr scheint was zu bringen, zumindest läufts hier gerade schon ca. 2 Stunden ohne Probleme.

Wenn das jemand testen möchte, hier der Patch dazu.

Hmm, der Patch macht es zwar um längen besser mit der Ausgabe, aber ein Problem ist mir gerade noch aufgefallen nach mehreren Stunden gucken.

Der Buffer läuft bei Szenen mit erhöhten Datenraten kurzzeitig voll, was sich dann in kurzer Klötzchenbildung auf dem TV äussert, bzw. auch zu einem hängenbleiben von vdr-sxfe führen kann. Das ist aber wenn ich mich richtig erinnere auch ab und an ohne den Patch aufgetreten.

Das sollte sich ja durch weiteres erhöhen von media.xvdr.num_buffers_hd lösen lassen. Allerdings startet die Ausgabe leider erst bei einem Buffer Füllstand von 66%, bei mir steht der Wert zur Zeit auf 2500, was schon eine recht lange Umschaltzeit bedeutet. Wenn ich aber die Buffer-Nutzung im laufenden Betrieb so beobachte, sollte dort eigentlich auch 10-15% ausreichen, um die Wiedergabe zu starten.

Ich suche auch gerade schon verzweifelt die Stelle im Code wo die 66% festgelegt sind
Mal sehen obs was bringt.

Edit: Gefunden, Zeile 619 das dort vorhandene

if (num_used/2 > num_free

ändern in

if (num_used > num_free/5

Dann startet er bei 16% Buffer, dazu hab ich media.xvdr.num_buffers_hd auf 10000 gesetzt. Jetzt wird getestet

Zauberhaft !

Der patch und die letzte änderung machen das zappen mehr als zwei mal schneller, ohne abstürze!

Auch HD läuft ohne probleme.

Vielen dank,

Carel

Hallo,

Nutzt Ihr xineliboutput cvs mit oder ohne den durchflieger patch ?

P.S. Am 20.3. hat sich im xineliboutput repository etwas bezueglich scr geaendert.
Genuegt somit evtl nur der kleine letzte Patch ?