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

In diesem Thread habe ich einen Patch gepostet, mit dem man die Untertitel beim media-player über die Fernbedienung abschalten kann.

Hallo Durchflieger,
wir haben festgestellt, dass wir OSD Probleme (hohe CPU Last von 100% und Ruckeln im LiveBild bei geöffnetem OSD) auf den Ion2 Boards haben, wenn Deine Patche genutzt werden. (Xine-lib 1.20)
z.T, aber selten scheint das auch bei den G84 und manchmal bei Ion1 Boards der Fall zu sein. Die Ion2 (AT5ION-T) leiden da extrem drunter. Es wird praktisch unbrauchbar bei aktivem OSD.

Hast Du dazu eine Idee?

Wer hat ein ION Board und hat keine Full-HD OSD Probleme?

Gruß

Ich hab das Ruckeln auch auf besser ausgestatteten VDR's (kein Atom, siehe Signatur). Dabei ist die Grafikkarte völlig unerheblich. Es liegt eindeutig an dem Patch für die xine-lib-1.2. Habs gestern extra mal ohne xine-lib-1.2 Patch versucht und da klappt das Scrollen ohne Ruckeln. Dafür fehlt mir dann allerdings wieder die Bildskalierung....grrr. Den Streamstart-Patch musste ich auch rauswerfen, da er reproduzierbar Spulen und Schneiden von HD-Material verhindert.

[Flennmodus ON] Läßt sich da nicht noch was drehen? [Flennmodus OFF]

Gruß
iNOB

Ähm... ich habe gerade mal den 260.19.12er NVidia Treiber installiert. Soweit ich das bis jetzt berurteilen kann, ist das Ruckeln weg

Wie gesagt mit dem Patch gegen xine-lib-1.2! Wäre schön wenn das einer mit Atom-Board mal gegenchecken könnte...

Gruß
iNOB

iNOB,
Das ist interessant zu wissen. Hast Du nach der Installation vom Nvida die xine-lib neu bauen müssen? oder einfach auf bestehende Installation den nvidia aktualisiert?

Hab nur den Treiber installiert und sonst nix gemacht. Allerdings ist mir bei meinen Versuchen aufgefallen, dass bei eingeschaltetem "bewegter Text" in SkinEnigmaNG das Ruckeln wieder da ist. Schaltet man das Hin- und Her im Hauptmenü aus, funktionierts problemlos wie oben beschrieben.

Gruß
iNOB

Hallo Durchflieger,
habe mal auch das x-ubuntu ppa Update auf den stable Nvidia eingespielt. Mit Deinen Patchen und xine-lib 1.20 sind unter hardwarebeschleunigtem OSD (ehgal ob xine oder vdr-sxfe) weiterhin massive Störungen und CPU Last zu verzeichnen.

Unter Software gerendertem OSD allerdings habe ich auch den Eindruck dass es geringfügig weniger stört. Nur ist da die OSD Qualität halt eingeschränkt.

Ich hatte schon mal an anderer Stelle geschrieben, das ich denke, dass der Fehler in der Hardwarebeschleunigung liegt. Von dieser kann nämlich keine Rede sein. Sie findet praktisch gar nicht statt. Leider weiß ich keinen Weg die GPU Last zu messen, aber es ist ja schon sehr merkwürdig, dass bei gleicher Auflösung 1920*1080 bei hardwarebeschleunigter Anzeige die CPU Last höher ist als bei Software. Das ist ein Wiederspruch in sich und ich denke hier kann man ansetzen.

hier mal meine Messungen von Top über putty mit Lirc repeat delay = 150 und repeat freq. 150 mit der MCE USB und auf ZDF HD, SkinenigmaNG ohne Scrolling:

top - 23:35:02 up  1:12,  1 user,  load average: 1.47, 1.22, 1.05
Tasks: 152 total,   2 running, 150 sleeping,   0 stopped,   0 zombie
Cpu(s): 28.6%us,  8.2%sy,  0.0%ni, 62.4%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
Mem:   1995608k total,   534336k used,  1461272k free,    38472k buffers
Swap:  2016248k total,        0k used,  2016248k free,   173228k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2167 root      20   0 1108m 164m 9056 S  118  8.5   5:39.09 vdr-sxfe
  805 root      20   0  255m  26m 7832 R   32  1.4   5:16.36 vdr

Hier ist Blending Software aktiv, es wurde das Hauptmenü geöffnet und auf der FB permanent die Up oder down Taste gedrückt. Man kann das auch mit der Tastatur simulieren, da tritt der Effekt auch auf, sogar etwas stärker, da die Wiederholrate höher ist.

jetzt das ganze mit Blending Hardware:

top - 23:31:28 up  1:09,  1 user,  load average: 0.97, 1.08, 0.98
Tasks: 152 total,   2 running, 150 sleeping,   0 stopped,   0 zombie
Cpu(s): 28.7%us,  7.9%sy,  0.2%ni, 62.4%id,  0.0%wa,  0.1%hi,  0.7%si,  0.0%st
Mem:   1995608k total,   534832k used,  1460776k free,    38116k buffers
Swap:  2016248k total,        0k used,  2016248k free,   170104k cached


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2167 root      20   0 1112m 168m 9048 S  105  8.6   4:31.26 vdr-sxfe
  805 root      20   0  255m  26m 7832 R   39  1.4   4:50.56 vdr

Das ganze auf dem AT5ION-T mit der ATOM 525 und ION2.

Ich vermute u.a. dass nicht alle CPU Kerne (derer sind 2 +HT) genutzt werden, kann dies aber leider im Moment nicht sehen, da vom Desktop aus der Aufruf vom sxfe nicht funktioniert.
Auch wenn der Top dies nicht zeigt, das Bild wird deutlich stärker gestört bei Blending Hardware.

Mein größtes Problem besteht aber darin nicht zu wissen, wo die Ursache drin liegt. Und an wen man den Fehler nun melden sollte.

Ich habe auch mal die Version 260.19.12 gestern ausprobiert

zusammen mit xine-lib und xineliboutput aus den Repos, allerdings mit dem 32er Kernel.
Sobald ich versuche das OSD anzuzeigen (also durch drucken von i-einer Taste, schmiert mit das vdr-sxfe)
ab.

Kennt jemand Abhilfe vielleicht? 34er Kernel?

Ich denke mal, das hat nichts mit dem Patch zu tun.
260.19.04 (beta) for Linux x86/x86_64 released
Einige User haben offenbar das gleiche Problem wie Du.

mahlzeit durchflieger,

Super das du dir das nochmal anguckst. Wäre es möglich den Patch in 2 - 3 teile zuteilen ?
zb.
- osd
- grab
- extended vdpau options

so wäre es einfacher rauszufinden welches der übertäter ist und die chance ist größer das es in die xine-lib-1.2 einfließt.

@ Durchflieger,
danke für Dein Engagement und die Erklärung. Jetzt verstehe ich es in den Grundzügen auch
Die Hin und Herwandlung hört sich allerdings sehr unsinnig an und frißt unnötige Resourcen. Auch das Rendern des kompletten OSDs ist nicht erforderlich.
Beim ION2 bleibt nicht viel GPU Performance übrig wenn vdpau läuft, obwohl alle Deinterlacerstufen ohne sichtbare Probleme laufen. Hier liegt auch möglicherweise ein Grund drin, dass auf Hardware das noch schlechter wird?
Obwohl ich mit bob die Probleme genauso habe.

Habe ich das denn richtig in Erinnerung, dass nur ein CPU Kern genutzt wird? Wenn ja, könnte man das irgendwie ändern?

Ich bin gespannt was es bringen wird. Danke schon mal für Deine Hilfe.

@ Durchflieger,
nein ich denke ich habe das nicht verwechselt.
Meine Überlegung war unter der Prämisse, dass ich auf HD Sendern temporal_spatial fahre. Das schafft der Ion2 ohne dass ich Bildhänger oder Probleme erkennen kann, solange das OSD nicht geöffnet wird.
Da aber aufgrund der 16 Streamprozessoren und geringeren Taktrate als die GT220 wir früher eigentlich davon ausgegangen sind, dass es nicht funktioniert, ist nun mein Umkehrschluß daraus, dass es die GPU Leistung bis an die Grenzen fährt. Meßtechnisch kann ich das nicht erfassen, abgesehen vom qvdpautest (Siehe hier), der aber mir nicht offenbart wieviel Reserve im Vergleich zu anderen Systemen noch übrigbleibt. Zumindest kann ich die Framediffernez nicht direkt als Maß für die GPU Last verstehen.
Da ich aber bemerkt habe, das bei X11 oder Hardware die Auswirkungen noch stärker sind, vermute ich also dass es irgendwie mit der Anbindung des ION2 (nur 4 Lanes) zusammenhängt, oder die GPU einfach keine Reserven mehr hat, wenn das OSD auch noch von der GPU entlastet werden soll. Auffällig bei den Messungen ist nämlich :

SURFACE GET BITS: 192.854 M/s
SURFACE PUT BITS: 160.288 M/s

Da gibts bei der GT220 ein vielfaches als Ergebniss ...

Da ich nur ein Laie bin, mag ich damit natürlich vollkommen daneben liegen, aber es klingt zumindest für mich logisch

Nichtsdestotrotz werden Deine Vorschläge mit Sicherheit sich spürbar bemerkbar machen. Ich schätze mal alleine dass Teilrendern macht je nach Skin gut 90% weniger Last aus.
Und die Pollrate der FB läßt sich ja etwas reduzieren, nicht jeder hat meine Reaktionszeit um einen durchrasenden Cursor zu erkennen und das reduziert ebenfalls die Systemlast.

An dem Problem der schlechteren OSD Qualität bei Software trotz gleich hoher Auflösung läßt sich vermutlich nichts drehen? Denn trotz 1920*1080 sieht das OSD eher nach 1280*786 aus, und auch unschön ist (nur bei Xine) ,dass es bei 4:3 Sendungen auch nur die Breite von 4:3 einnimmt. Aber dass ist vermutlich eine andere Baustelle?

Ansonsten bin ich schon schwer begeistert davon wie flott mit Xine das Zappen geht, ohne Pixelfehler und HD ist nicht langsamer als SD mittlerweile, besser als bei den Loewe LCD´s und das ist schon was tolles, was da auf die Beine gestellt wurde von Dir. Eine Schande, das dies nicht in die Entwicklung von Xine-Lib einfließt. Vielleicht haben sich noch einfach nicht genügend Fürsprecher gefunden. Denn bis auf Probleme beim HD Spulen sind mir keine wirklichen Fehler durch den Patch bekannt.

Gruß