Experimentelles Update: xine-lib git-Master, mit neuem alter-h264-decoder Patch

Hallo Zusammen,

ich hab meinen Beitrag noch mal etwas angepasst.
Zuerst mal eine Zusammenfassung, worum es geht.

Auf meinen ION-Systemen hatte ich immer Probleme mit dem OSD (träge Reaktion; Flackern, Zucken und Bildhänger beim Öffnen/Schließen des OSD und Srollen im OSD).
Mit älteren VDR-Versionen war die Reaktionszeit deutlich besser und dann mit vdr-1.7.22 (dank Ingo und Helmut) schon fast perfekt.
Ich hatte aber immer noch die anderen OSD Probleme, am schlimmsten bei ION2 und mit neuen nVidia-Treibern.
Aber auch mit nVidia 275.09.07 waren sie immer noch da, besonders nach längerer OSD-Inaktivität.
Bei Tests mit der aktuellen xine-lib waren mit dem dem git-Master all diese Probleme weg (auch mit dem aktuellen nVidia 290.10)
Da im xine-lib Master leider der alter-vdpau-h264-decoder fehlt, hat man wieder das kurzzeitig verpixelte Bild bei HD-Sendern (LiveTV - Umschalte; Wiedergabe - Spingen und Stop-Spulen).
Nach längerer Recherche hab ich einen neuen und optimierten alternativen h264-vdpau-decoder als patch gefunden.
Dieser stammt vom Entwickler des patches der im xine-lib df-osd-handling+alter-vdpau-h264-decoder branch verwendet wird.
Seit ich diesen Patch mit dem xine-lib Master verwende, hat sich bei meinen ION-Systemen das Reaktionsverhalten des OSD weiter verbessert und die anderen OSD-Probleme sind komplett weg.

Ich hoffe das ist kurz genug und wenn es nicht interessiert, braucht man ja nicht weiter zu lesen.

!!!Edit: Am 31.12.11 wurde genau dieser alter_h264 patch fest in den xine-lib Master integriert, weshalb man die xine-lib nicht mehr mit alter_h264.diff patchen muss/darf.
Außerdem ist am 03.01.12 der df-osd-handling in den Master gewandert.
Dank Ingos Hilfe, der einen revert-patch bereitgestellt hat, kann man den aber wieder aus dem Master heraus patchen.

!!!Edit 13.02.2012: Seit dem 16.01.2012 funktioniert der revert-patch leider nicht mehr.
Als Alternative kann man mit einem angepassten ebuild einen bestimmten Git-Stand verwenden.
Da bietet sich der Stand (12.01.) an, zu dem der revert-patch noch funktioniert hat.
Alternativ kann man den Stand vor der Integration des df-osd-handling am 03.01. verwenden, dann benötigt man den revert-patch nicht.

Mittlerweile sind auch mit dem df-extensions branch die OSD-Probleme weitgehend behoben.
Nur meine ION2-Systeme haben auch mit diesem branch, der das df-osd-handling enthält, weiterhin OSD Probleme, die mit dem Master ohne df-osd-handling komplett weg sind.
Bei OSD-Problemen sollte man auf jeden Fall den xine-lib Master ohne df-osd-handling nach dieser Anleitung testen.

Die Anleitung wurde angepasst.

Basis für diese Anleitung ist Gen2VDR V3 Release mit allen aktuellen Updates (bis Update9).
Im Rahmen des Updates wird auf den neuen vdr-1.7.22 mit dem speziellen ExtPatch von Helmut umgestellt.
Als Ausgabeplugin wird xine-0.9.4 verwendet.
Abhängig von der HW (weitere Infos in Abschnitt 1) wird der nVidia-Treiber 290.10 oder 275.09.07 verwendet.

Da ich nur mit begrenzter HW testen konnte, weise ich darauf hin, dass dies eine experimentelles Update ist, das jeder auf eigene Gefahr durchführt.
Bei mir laufen jedoch bisher 5 Systeme mit dieser Konfiguration seit einer Woche extrem stabil.
Ich habe hauptsächlich mit dem, von mir bevorzugten, xine-plugin getestet.
Daher kann ich nicht sagen, ob das Update auch bei xineliboutput Verbesserungen bringt und ob xineliboutput nach diesem Update noch stabil läuft.
Also am Besten vorher ein Backup anlegen, um ggf. den aktuellen Stand wiederherstellen zu können.

Vor Beginn des Updates sollte man im xine-plugin (Einstellungen-Plugins-xine) die "Anzeigerart für OSD" auf "Einpassen Auto" umstellen.
Durch das Weglassen des df-osd-handling Patches kann man die Standardeinstellung "Überlagern X11" nicht mehr vernünftig nutzen.
Bei meinen ION-Systemen war "Überlagern X11" jedoch schon vorher nicht wirklich nutzbar (Ruckeln/Hänger).

1. Falls noch nicht geschehen, den nVidia-Treiber updaten bzw. downgraden.
Als neuerer nVidia-Treiber hat sich bei mir der 290.10 für ION1 und auch leistungsfähigere HW, wie z.B. mein SandyBridge-System bewährt.
!!!Edit 08.03.2012: Mittlerweile hat sich bezüglich der nVidia-Treiber wieder einiges getan, daher hab ich diesen Abschnitt angepasst.
1.a Der derzeit (Stand 08.03.12) aktuellste Treiber ist 295.20.
Zur Stabilität dieser Treiber-Version kann ich jedoch noch nichts sagen.
Auf die nVidia-Treiber und -Settings 295.20 kann man wie folgt updaten:

1.b Auf den nVidia 290.10 kann man wie folgt updaten:

1.c Als sehr stabil hat sich aber der nVidia 275.09.07 erwiesen.
Bei meinen ION2-Systemen hatte ich mit dem 290.10 immer noch gelegentlich OSD-Probleme, wobei der xine-lib Master schon westliche Verbesserungen gebracht hatte.
Mit dem Nvidia 275.09.07 sind diese dann auch komplett weg.
Also bei ION2 und evtl. auch schwächeren Systemen (z.B. 8xxx), auf 275.09.07 downgraden.
Dabei muss man aktuell (08.03.2012) wie folgt vorgehen:

2. Vorbereitungen für das emergen der xine-lib aus dem master plus dem neuen alter_h264_decoder:
In der /etc/make.conf den git Master aktivieren:
Vor dem
#XINE_LIB_GIT_BRANCH="master"
das # entfernen und dafür unbedingt den aktiven Branch mit # kommentieren.
Vermutlich ist das der df-osd-handling+alter-vdpau-h264-decoder, was dann so ausschauen sollte:
#XINE_LIB_GIT_BRANCH="df-osd-handling+alter-vdpau-h264-decoder"
Es darf auf jeden Fall nur ein Branch aktiv sein, daher müssen alle Branches außer dem aktiven "master" mit # kommentiert sein!!!
Die Zeile mit dem Verweis auf den Speicherort des Patches muss so ausschauen
XINE_LIB_LOCAL_PATCHES="/usr/local/portage/patches/xine-lib/*.diff"
Unbedingt überprüfen!!!

Edit: Der Patch alter_h264.diff darf ab 01.01.2012 nicht mehr verwendet werden, da er seit dem 31.12.11 bereits im xine-lib Master enthalten ist!
Falls man das Update vorher schon einmal ausgeführt hat, muss man den patch vor einem Neubau der xine-lib unbedingt wieder entfernen, da sonst emerge mit Fehlermeldung abbricht!!

Edit 13.02.2012: Am 03.01.2012 wurde das df-osd-handling in den Master integriert.
Da der von Ingo bereitgestellte revert patch nach dem 12.01. leider nicht mehr funktioniert, hat man 2 Alternativen mit einem geänderten ebuild für einen dedizierten Git-Stand den df-osd-handling los zu werden.
Alternative1: Git-Stand vom 12.01. mit revert patch

Alternative2: Git-Stand vom 03.01. vor Integration des df-osd-handling
In der /etc/make.conf folgende Zeile Einfügen:
XINE_LIB_GIT_COMMIT="a863a70a167408ad1422c0fbcdfd7bf0c5bcf706"
und danach

Falls man das Update vorher schon einmal mit dem revert-patch ausgeführt hatte, diesen bei Alternative2 vor einem Neubau der xine-lib unbedingt wieder entfernen!!

Da ab Update8 ein neues ebuild für xine-lib verwendet wird, für das man die libbluray-xine entfernen muss (ist jetzt in der xine-lib integriert), sollte man auch die libbluray ohne die libbluray-xine neu bauen.
Das neue ebuild für die libbluray ist zwar auch in Update8 drin, nur werden noch zusätzliche Dateien benötigt, damit libbluray auch komplett gebaut wird.
Deshalb holen wir das komplette Paket von Ingo aus Ticket 473.

3. Jetzt kann libbluray-xine entfernt und xine-lib, xine-ui und libbluray neu gebaut werden (davor am Besten den vdr stoppen).
Wegen des Branch-Wechsels soll xine-lib 2x gebaut werden, also nicht wundern.

Danach die nicht mehr vorhandene libbluray-xine maskieren:

4. Dann den neuen vdr-1.7.22 holen

Und neu bauen.
Falls er bereits auf dem System installiert wurde, muss er trotzdem noch mal neu gebaut werden:

Edit: Alternativ kann man auch vdr 1.7.23 nach R2D2s Anleitung installieren

5. Wer auch xineliboutput testen möchte, sollte dann nochmal xineliboutput und xineliboutput/xine/BluRay/ neu bauen.

Edit Jan 2012: xineliboutput baut wieder problemlos mit den aktullen branches (master und df-extensions) der xine-lib.

Fertig!
Viel Erfolg beim Testen!!!

Gruß
Klaus

angehängte Datei ( Anzahl der Downloads: 166 )
 nv275_09_07_local.tgz

Hi franky,

bei mir musste ich in der "make.conf" einen Eintrag ändern.

Original sah er so aus: (was dazu führte dass er den xine-patch nicht ausführte)

Ich musste es folgendermaßen abändern:

Vielen Dank für das HowTo. Es läuft tatsächlich sehr gut mit meiner HW.

Gruß
ee

Ist ja jetzt sowieso hinfällig, da Anleitung geschrumpft!!

Obwohl ich weiß, dass franky immer gerne gähnend lange Beiträge postet, frage ich mich, wie so oft, nach den Sinn von diesem, denn die Anleitung zur Verwendung der xine-lib aus dem git wurde sowohl von mir, als auch von nvertigo schon gepostet... :rolleyes:

Hallo? :blink: Was soll denn das jetzt? :blink: Wenn Ihr zwei ein Problem miteinander habt macht das doch unter euch aus!!! Aber wieder was zu entfernen finde ich nicht so toll. Ich hätte es gerne mal durchgespielt. Und ich habe keinen Bock mir das irgendwo zusammenzulesen. :angry:

Sorry Zwick,

ich hab eigentlich kein Problem mit R2D2.

Nur wenn mir ein Foren-Moderator sagt, dass meine Beiträge gähnend lang und dieser hier eigentlich auch noch sinnlos ist, da sowieso schon Alles im Forum zu finden ist,

hab ich halt meine Konsequenzen gezogen und den Beitrag auf die wesentliche Aussage gekürzt.

Ich verstehe deinen Ärger.
Informationen, die der Moderator für überflüssig hält, wieder zu löschen ist zwar konsequent aber nicht fair gegenüber anderen Foren-Usern, die das interessiert.
Es war halt eine Affekthandlung.
Ich werde meinen ursprünglichen Beitrag wieder im Eröffnungsbeitrag ergänzen.

Gruß
Klaus

Hallo R2D2,

Was hast Du jetzt wieder fuer ein Problem ?

Wenn franky die Anleitung etwas ausfuehrlicher schreibt ist das doch gut so. Somit koennen auch weniger erfahrene User was damit anfangen.

Wenn es Dir zu ausfuehrlich ist dann schau halt einfach weg.

Gruss
ee

Kann es sein dass Dir Weihnachten komplett das letzte bischen normale Stimmung verhagelt hat ? Ein etwas freundlicherer Umgangston sollte fuer einen Moderator machbar sein, zumal ich Franky's ausfuehrliche Beitrage sehr schaetze.
Es gibt hier genuegend User die dadurch ein bischen mehr Wissen vermittelt bekommen.

Danke, Klaus !
Ich werd's morgen mal auf meinem Test-VDR ausprobieren. Bin mal gespannt, was sich tut, da ich xineliboutput verwende.

Welche Erfahrungen hast Du mit xine gemacht ?
Welche Probleme hattest Du vorher genau ?

mni tnx e 73 ...
NetWraith

@franky

Danke :D Und einfach nicht ärgern lassen ;) Ich finde Deine Beiträge nicht gähnend zu lang ;)

Grüße

Danke Franky,

du weißt doch wie er ist.
Und trotzdem mögen wir uns alle.

Kommt gut ins neue Jahr!!!!

Grüße
kaminkehrer

Kurzes Feedback zu diesem "gähnend langen" HowTo ;)

Einfach Traumhaft.
Habe jetzt VDR 1.7.22, NVidia 275.09.07 und xine aus diesem HowTo am Laufen.

Ich bin zumindest höchst zufrieden. Das erinnert mich bez. Stabilität an die alten FF-Zeiten.

Gruß
ee

Ich hab das Howto mal auf einer ZBOX HD-ND22 durchgepielt, mit neuem Nvidia Treiber, und kann mich meinem Vorredner nur anschließen :D Ich werde das am WE mal versuchen auf meinem VDR nachzuziehen. Danke für das Howto.

Grüße

Hallo NetWraith,

ich hab meinen Eröffnungsbeitrag noch mal etwas angepasst und zu Beginn eine Zusammenfassung über die Hintergründe für dieses HowTo geschrieben.
Damit wird vermutlich schon ein Teil deiner Fragen beantwortet.

Seit vdr-1.7.22 und Umstellung auf den xine-lib Master nach meiner Anleitung nur die besten.
Die Systeme laufen sehr stabil und es gibt keinerlei OSD-Zappeln und Flackern sowie keine Hänger nach längerer OSD-Inaktivität mehr.
Auch das Bild-Ruckeln beim Scrollen im OSD (beim At5IONT-I vorher besonders ausgeprägt) ist komplett weg.
Bei der Wiedergabe läuft auch Alles (Springen, Spulen, Bildrefresh beim Schneiden - auch bei 720p und 1080i Aufnahmen) perfekt.
Dabei hat an dieser optimalen Reaktionszeit im Wiedergabe-OSD natürlich auch der vdr-1.7.22 mit Helmuts SuperExt-Patch eine erhebliche Verbesserung gebracht.
Wenn einem der etwas lästige vdr-xine Schriftzug am xine plugin stört, kann man den auch noch in ein komplett schwarzes Bild Umwandeln.
Die 4:3 Sendungen kann man ja bei xine in 1% Abstufung (Breite und Höhe getrennt) bildfüllend anpassen, wodurch auch das OSD durch "Einpassen Auto" bei 4:3 nicht gestaucht wird.
Da fällt mir dann nur noch der Bluray-Support des xineliboutput plugin ein, der dem xine-plugin fehlt, den ich aber nicht brauche.

In der Zusammenfassung im Eröffnungsbeitrag hab ich die Probleme ja schon kurz beschrieben.
Eines der OSD-Probleme ist das OSD-Flackern, das z.B. Ingo hier beschrieben hat.
Immer wenn ich auf einem System diesen Effekt hatte, gab es mehr oder weniger ausgprägte Bild-Ruckler beim Scrollen im OSD (besonders beim AT5IONT-I).
Aber noch lästiger waren Bildhänger beim Öffnen oder Schließen des OSD aber auch häufig beim schnellen Scrollen durchs OSD (z.B. Programm-, Aufnahme Kanal-Liste).
Besonders auffällig und lang hatte ich diese Hänger nach längerer OSD-Inaktivität.
Dabei bleibt das Bild stehen, das OSD ist nicht mehr bedienbar (wenns beim Öffnen passiert) und Ton ist zeitversetzt nach einigen Sekunden weg.
Nach einigen Sekunden Stillstand läuft das Bild im Zeitraffer ab um quasi den Hänger wieder aufzuholen.
Bei längererer OSD-Inaktivität (über 1h) hatte es bis zu 20s gedauert, bis das Bild wieder stabil gelaufen ist.

Gruß
Klaus

Ich habe mich wohl wieder mal völlig falsch ausgedrückt.
Ich wollte ganz bestimmt Niemanden an die Karre fahren und es tut mir Leid.

Sorry
R2D2

Entschuldigung angenommen!

Ich versuch auch, mich künftig etwas kürzer auszudrücken.
Mal schauen, ob es mir gelingt. ;)

Der Titel "Experimentelles Update: xine-lib git-Master" kann natürlich auch zu Missverständnissen führen.
So ist es Dir vermutlich auch gegangen.
Wenn ich künftig in den Titel nicht alles Wichtige reinbringe, werde ich gleich zu Beginn des Beitrags eine Zusammenfassung schreiben, damit man sieht worum es überhaupt geht.

Gruß
Klaus

Hallo Klaus,

super Sache, ich hab für nen Kumpel auch nen AT5IONT-I am Laufen.
Nach Deinem Update geht da zum ersten mal das OSD Ruckelfrei.
Allerdings nur mit xine. Xineliboutput hatte ich auch getestet, aber da
ruckelts immernoch.
Wollte bloss Feedback loswerden.

VielenDank!

Gruss, Ralf

Hi Franky,

du bist mein persönlicher Held! :)

Vor der Durchführung deines Howtows war die Sache ja schon zu 99% rund. Aber das zucken beim verschwinden des OSD hat mich schon ein bisschen gestört.

Jetzt ist das mit dem nvidia 290.10 komplett weg. Und auch der neue h264 Patch scheint mir ein bisschen besser, gerade auf HD+ Sendern hatte ich ab und an mal leichte verpixelungen, die scheinen jetzt auch besser zu sein.

Vielen Dank für deine Bemühungen!

@R2D2: deine Entschuldigung finde ich gut...aber vielleicht solltest du das nächste mal vor dem Betätogen des "Add Reply" Buttons zumindest kurz darüber nachdenken, wie deine Antwort beim Gegenüber ankommen könnte...du bist nicht der Nabel der G2V Welt ;)

Ciao Louis

@Franky

Danke fuers HowTo !

Noch ne Frage: wie bist Du auf den neuen alter vdpau patch gekommen ?

Gern geschehen.

Angestachelt durch diesen Beitrag von Ingo https://www.gen2vdr.de/forum/index.php?showtopic=8912 hab ich nach einer Lösung für die OSD-Probleme gesucht.

So um den 16.12. hab ich dann entdeckt, dass die OSD-Probleme mit neueren nVidia-Treibern (beim ION2 auch mit älteren Treibern) offensichtlich durch den df-osd-handling patch entstehen.

Mit dem df-osd-handling branch waren alle OSD-Probleme noch massiver vorhanden als beim df-osd-handling+alter-vdpau-h264-decoder.
Mit dem Master (ohne df-osd-handling patch) waren die OSD-Probleme weg, aber durch das Fehlen des alter_h264 waren (wie beim df-osd-handling branch) die hässlichen Verpixelungen bei HD wieder da.

Deshalb hatte ich zuerst den patch gesucht, der im df-osd-handling+alter-vdpau-h264-decoder branch enthalten ist.
Ich bin dabei auf diesen Beitrag http://www.vdr-portal.de/board16-video-dis...pau-h264-alter/ im VDR-Portal gestoßen, wo es auch einen Downloadlink gab.
Nur leider funktioniert der Download vom Server des Entwicklers hftom nicht mehr.

Deshalb hab ich nach hftom und xine weiter gesucht und bin auf diesen http://marc.info/?l=xine-devel&m=132388760010700&w=2 Beitrag in der xine-devel mailing-list gestoßen.
Von dort wird auch der patch in meiner Anleitung per wget geholt.

Mittlerweile hab ich auch entdeckt, dass der neue patch den vorherigen patch im df-osd-handling+alter-vdpau-h264-decoder branch ersetzt hat.
Das Kombinieren des df-osd-handling branch mit dem neuen alter_h264.diff macht also keinen Sinn.

Gruß
Klaus