nVidia 8400 GS PCI VDPAU ruckeln mit geöffnetem OSD bei vdr-xine und xineliboutput

Hi kaminkehrer,

eben nochmal auf xineliboutput umgeschaltet mit der vdr-xine.sh von der beta4, also alles original:

So wird xineliboutput bei mir aufgerufen. Keine Angst wegen dem 4:3 aspect, teste hier an nem 4:3 Monitor mit 75Hz, ist durch 25 teilbar und somit nahezu so ruckelfrei wie mit 50 hz.

Zitat

Jan 13 01:49:35 [logger] /_config/bin/vdr-xine.sh - starte <vdr-sxfe --fullscreen --post tvtime:method=use_vo_driver --config=/root/.xine/config_xineliboutput --video=vdpau --audio=alsa --reconnect --aspect=4:3 xvdr://127.0.0.1>

Aber, xine läuft besser mit der Werterhöhung aus dem vorigen Post von mir.

Gruss Kai

Hi,

nochmal zum OSD Ruckeln - mit einer aktuelleren xinelib Version (xine-lib-vdpau-1.2 11349) und vdr-xine wieder das gleiche verhalten wie mit wesentlich älterer xine-lib-1.2.

Soll heissen:

Mit einer xinelib 1.2 vom November letzten Jahres hatte ich, wie bereits beschrieben, das Ruckeln nur noch wenn ich im Menü in ein neues Untermenü wechsel. Mit darauf folgenden Versionen hat es wieder bei jeder Änderung im Menü geruckelt. Jetzt mit oben genannter Version zeigt sich wieder das gleiche Verhalten wie mit der November Version.

Deckt sich also mit Björns Erfahrung:

Zitat

Hallo, ich melde mich dann auch mal zu dem Thema, hab ja auch nen PIII mit einer 8400GS hier stehen. Bis heute hatte ich mein System mit xine-vdpau am laufen und diese Ruckler eigentlich immer gehabt, sobald irgendeine OSD Anzeige geöffnet wurde. Nun habe ich auf xine-lib-1.2 (heute gezogen) umgestellt und seit dem sind diese Ruckler zu 99% weg. Nur wenn ich das Hauptmenü vom VDR öffne, ruckelt das Bild minimal. Wobei das wesentlich weniger auffällt als vorher. Ich muss das Ganze jetzt nochmal am richtigen TV testen aber bisher sieht das für mich nach einer Lösung aus.

Gruß
Atech

Hallo Atechsystem,

das passt soweit zu meinen Erkenntnissen.

Mit einer xine-lib aus November lief es bei mir auch ohne ruckeln.

Vermutlich war es diese:

Zitat

xine-lib-1.2-vdpau-r284.diff.bz2

Aktuell ist diese installiert:

Zitat

xine-lib-1.2-vdpau-r286.diff.bz2

und das Ruckeln ist vorhanden.

Wo holst du Deine Version her?
Mir ist dieser Link bekannt:

Zitat

http://www.jusst.de/vdpau/files/xine-lib-1.2/

Allerdings finde ich hier die von Dir genannte:

Zitat

xine-lib-vdpau-1.2 11349

NICHT.

Ich werde heute abend mal versuchen die:

Zitat

xine-lib-1.2-vdpau-r284.diff.bz2

wieder zu installieren.
Ich werde berichten.

Grüße
kaminkehrer

Hallo,

habe es gefunden

Zitat

http://hg.debian.org/hg/xine-l….2-vdpau/rev/162363b5d312

Zitat

author Julian Scheel <julian@jusst.de> Tue Jan 12 22:23:19 2010 +0100 (2 days ago) changeset 11349 162363b5d312 parent 11343 4523c5d3ce7d parent 11348 0f257680ded0 child 11350 4e98b0412b92

Somit ist die 11340 die changeset Nummer.

Der change kommt von Julian Scheel, er hat es aber leider noch nicht in seinem Entwicklungsstrang nachgezogen.
http://www.jusst.de/vdpau/listing.php?repname=xine-vdpau&path=%2F&

Ich werde das mal testen.
Das Ruckeln beim OSD ist das einzige was mich im Moment stört, HDTV ist mir noch nicht ganz so wichtig.
Erst mal möchte ich die maximale Bildqualität bei SD.

HDTV folgt dann später.

Grüße
kaminkehrer

Hi!

Ja die genannte Nummer ist die revision vom checkout. Ich weiss noch nicht ganz was du meinst, ein "diff" ist doch eigentlich nur ein Patch - oder verbessert deine genannte "xine-lib-1.2-vdpau-r284.diff.bz2" das OSD verhalten?

Habe grade nochmal kompiliert und werde weiter Testen....

Gruß
Atech

Servus Leute,

muß mich gerade mal mitteilen. Ich habe im Moment nur ein ganz ordinäres FF-System am laufen. Aber ich plane auch mit HDTV (siehe Sig.). Am Anfang hatte ich irgendwie keine Lust uf VDPAU und wollte meinen VDR mit neuester Core iX-Technologie pimpen und fertig wär der Lack. Aber als ich realisierte, was die GF 8400 GS für wenig Budget leisten kann... - sie liegt schon im Kofferraum.

Zu Euch:
Stark, ihr macht hier echt eine schöne detektivische Arbeit, von der ich demnächst profitieren kann - Danke.
Ein großes Danke sowieso an alle, die hier high definition Pionierarbeit leisten. Diejenigen, die gemeint sind, wissen das schon, daher verzichte ich mal auf's Aufzählen...

So long
Matthias

EDITH sagt: Hat jemand eine NTV-HD-Aufnahme o.ä., die man zum Testen runterladen kann? Leider habe ich noch keine DVB-S2.

Zitat

EDITH sagt: Hat jemand eine NTV-HD-Aufnahme o.ä., die man zum Testen runterladen kann? Leider habe ich noch keine DVB-S2.

Hi,

das wäre auch für mich Interessant. Ist der Sender schon auf Sendung?

Im xine 1.2 Zweig tut sich was der ist jetzt mit dem VDPAU Zweig gemerged. Man muss wohl noch auf verbesserungen warten aber vielleicht hilfts auch unseren Problemen.

Gruß
Atech

Hat sich hier schon eine Lösung ergeben? Bei mir ruckelt´s auch mit der 8400er...
Geringfügig besser wird es wenn ich die Ausgabe via xineliboutput nutze und das OSD Rendering auf Software stelle.
Dann ruckelt zwar das Bild, aber zumindest das OSD kann flüssig bedient werden.

SvenGWK

Nutzt Du einen Single-Core mit der 8400er? Xineliboutput hat seither bei Single-Core Maschinen Multithreading abgeschaltet, man findet dazu einen entsprechenden Eintrag im syslog. Bei eigenen Tests letzten Sommer, habe ich das Thema mit der Verwendung eines AMD X2 behoben, dann war das OSD bis 1080i auch mit einer 8400er flüssig zu bedienen, auch wenn das 1080i Bild selbst damals noch ruckelte ...

Was heißt geringfügig besser, wenn Du Du xineliboutput nutzt? Was ist dann schlechter?

Gruß
Frank

Schade, in die Kiste kann ich keinen dualcore Prozi packen - wird vom Board nicht unterstützt und andere passen da nicht rein.
Geringfügig besser soll heissen, das man zwar das Menü flüssig bedienen kann, es aber statt Stanbildern im Hintergrund komplett zu "zerrissenen" Bildern kommt.
Hat man quasi die Wahl zwischen Pest und Cholera.
Bin jetzt trotzdem wieder zurück bei xine, dann ruckelt es eben.

@SwenGWK

Das Interessante ist, das xine auch bei SingleCore Prozessoren soweit ich das nachvollziehen kann mit Multithreading arbeitet. Einer der Gründe warum ich xine lieber nutze, es gibt überhaupt keinen Grund das nicht zu tun, wie bei xineliboutput.

Welche OSD Skin nutzt Du, kann es sein das das evtl. damit zusammenhängt?

Gruß
Frank

Hallo Zusammen,

ich bin mittlerweile auch in die HD-Fraktion eingestiegen.
Nach längerem Hin und Her bin ich beim brandneuen yavdr gelandet. Dieser läuft eigentlich jetzt schon wunderbar. Aber auch ich habe Kontakt zu dem "Ruckeln". Das N-TV-Band läuft in SD einwandfrei.

Mein System ist in der Signatur. Der Prozessor hat schon Hyperthreading, das auch munter genutzt wird; also einen HT-Core.
Bei SD braucht mein System ca. 10 % und bei HD ca. 15-25 CPU-Leistung. Das scheint mir garnix zu sein.

Wenn ich das OSD öffne, dann kommt mit jedem Klick eine CPU-Spitze, die beim fortwährenden Scrollen bei rund 80 % (beide "Kerne" zusammen) landet. Gleichzeitig ruckelt auch bei mir das Live-Bild im Hintergrund.
Ganz besonders merkt man das Ruckeln beim Abspielen einer Aufnahme und zwar egal ob SD oder HD. Dann nämlich, wenn man bei der Wiedergabe den Fortschrittsbalken einblendet. Mit jedem Sekundensprung ruckelt das Bild. Die CPU geht dann von 10 % auf 30 - 40 %.

Gelesen habe ich hier mittlerweile schon viel und hoffe, daß an der xinelib noch weitergearbeitet wird. Allerdings bin ich dem ganz Compilieren nicht so vertraut. Gerne würde ich hier verschiedenes Testen, aber da müßte ich mich erst mal schlau machen - obwohl keine Berührungsängste (höchstens mein Weibchen fragt anstrengend nach, was jetzt schon wieder zu tun sei...:)

Trotzdem mal vorsichtshalber drei relevante confs. Vielleicht sieht ja doch jemand einen Kardinalsfehler....

Viele Grüße
Matthias

setup.conf xine-Abschnitt

xine.autoPrimaryDeviceMode = autoPrimaryDeviceOn
xine.image16:9.zoomX = 100
xine.image16:9.zoomY = 100
xine.image4:3.zoomX = 100
xine.image4:3.zoomY = 100
xine.interactWithEitScannerMode = interactWithEitScannerOff
xine.modeLiveTV.monitoringDuration = 10
xine.modeLiveTV.monitoringMode = monitoringOnce
xine.modeLiveTV.prebufferFramesAudio = 32
xine.modeLiveTV.prebufferFramesVideoHD = 32
xine.modeLiveTV.prebufferFramesVideoSD = 32
xine.modeLiveTV.prebufferHysteresis = 8
xine.muteMode = muteSimulate
xine.osdExtent.X = 1920
xine.osdExtent.Y = 1080
xine.osdGammaCorrection = 123
xine.osdMode = osdOverlay
xine.transparencyMode = transparencyOff
xine.volumeMode = volumeChangeHW
xineliboutput.OSD.Blending = 1
xineliboutput.OSD.BlendingLowRes = 1
xineliboutput.OSD.Height = 720
xineliboutput.OSD.Scaling = 1
xineliboutput.OSD.Size = 1920x1080
xineliboutput.OSD.Width = 1280

Gestern habe ich den Tatort in 60 Hz geguckt und mich die ganze Zeit gewundert, warum das Bild so "komisch" ist. Heut habe ich gemerkt, daß beim letzten apt-get upgrade die xorg überschrieben wurde. Hier meine aktuelle:

Hi,

Zitat

Wenn ich das OSD öffne, dann kommt mit jedem Klick eine CPU-Spitze, die beim fortwährenden Scrollen bei rund 80 % (beide "Kerne" zusammen) landet. Gleichzeitig ruckelt auch bei mir das Live-Bild im Hintergrund. Ganz besonders merkt man das Ruckeln beim Abspielen einer Aufnahme und zwar egal ob SD oder HD. Dann nämlich, wenn man bei der Wiedergabe den Fortschrittsbalken einblendet. Mit jedem Sekundensprung ruckelt das Bild. Die CPU geht dann von 10 % auf 30 - 40 %.

Ich habe eine xinelib Version (noch aus dem xine-lib-vdpau 1.2 Zweig) bei der dieses Verhalten nicht ist. Es liegt scheinbar tatsächlich an der xinelib Version. Leider habe ich auf meine Emails an die Entwickler keine Antworten erhalten. Ich denke einfach es betrifft zu wenig oder ist einfach zu speziell. Jedenfalls gibt es für dein Problem bei bewegten Balken oder Text eine Abhilfe - mit entsprechender xinelib Version. Hab leider im Moment keine Zeit da nochmal genauer zu Testen. Überlege daran mal meine Hardware zu erneuern obwohl ich immernoch davon überzeugt bin, dass es eigentlich garnicht an der Karte liegt.

Gruß
Atech

Zitat

Original von fnu
@SwenGWK

Das Interessante ist, das xine auch bei SingleCore Prozessoren soweit ich das nachvollziehen kann mit Multithreading arbeitet. Einer der Gründe warum ich xine lieber nutze, es gibt überhaupt keinen Grund das nicht zu tun, wie bei xineliboutput.

Welche OSD Skin nutzt Du, kann es sein das das evtl. damit zusammenhängt?

Gruß
Frank

Alles anzeigen

Ich bin auch eher für Xine, aber das die Sache nervt ist eben leider Tatsache.
Ich nutze Pearl HD...
Meine CPU sollte eigentlich auch Hyperthreading können, ist ein P4 Typ Prescott.

Wenn ich das Menü öffne, geht die CPU Belastung auf 100% - und bleibt dort auch hängen nachdem es geschlossen wurde...

Habe jetzt verschiedne Skins probiert, selbst mit dem "klassischen" klappt es nicht. Laut Logfile läuft der Puffer über, da kommt er nicht mehr klar bis eben umgeschaltet wird.

presskopf

Äh, könntest Du das nächste Mal evtl. als Datei anhängen?

@SwenGWK

Hmm, ist das Hyperthreading eingeschaltet? Wieviel Prozessoren zeigt z.B. "htop"?

Gruß
Frank

Gut das du mich darauf hinweist, ist nälich gar nicht aktiv.
Muss mal sehen wie ich das bei dem Grub 1.97 aktiviere...

Hmm, ich habe in der /etc/default/grub ein ht=on unter GRUB_CMDLINE_LINUX= eingefügt und update-grub ausgeführt.
Trotzdem bekomme ich nur eine CPU, auch bei htop.
HT-fähig muss sie doch aber sein, das Flag ist ja da.
Was mache ich falsch?

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 3
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 4
cpu MHz : 2793.126
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc up pebs bts p ni dtes64 monitor ds_cpl cid xtpr
bogomips : 5586.25
clflush size : 64
power management:

Mittlerweile kommt das ht=on in der Kernelzeile an, aber das stört meinen rechner nicht.

/var/log/messages :

SLUB: Genslabs=13, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1

CPU: Hyper-Threading is disabled

...und es bleibt bei einer CPU

evtl. muss ht noch im bios enabled werden

koennte sich bei virtualization verstecken.

-- randy