integration von vdpau in vdr

Zitat

Original von Brilwing

Danke für die Info.
Das Tearing ist jetzt weg, das composite abschalten hat geholfen. Die Klötzchen hab ich immer noch, aber nur im SD Programm, in HD nicht. Ich muss mal testen wie meine Signalqualität ist, vielleichts hats ja da was.

Hi nochmal,

schaut mal ins svn von xine-vdpau, da gab es mit der heutigen r248 eventuell ein Bugfix für das Problem.

Gruß
Wolfgang

Ich hatte schon vor einiger Zeit von diesen Problemen berichet - schön zu wissen, dass ich nicht alleine bin...

integration von vdpau in vdr

Zitat

Original von infinite
das klingt doch ganz gut.. welches svn ist gemeint?

svn co svn://jusst.de/xine-vdpau

Gruss

hemonu

Hallo bts100,

ich habe die von Dir geschilderten Problem nur beim Umschalten (SD), nach ca. 0.5 Sekunden ist alles wieder klar und bleibt dann auch so. Ist das bei Dir ebenso oder eher permanent?

Hi rkp,

bei mir ist das permanent. Allerdings hängt es auch vom Bildinhalt ab... Wenn sich viel ändert (Bewegung) oder ein Wechsel von dunkel auf weiss stattfindet, tritt der Fehler häufiger auf - das ist aber ein subjektiver Eindruck. Ich habe das aus Zeitgründen noch nicht evaluiert.

Das mit dem "nur beim Umschalten" habe ich wohl überlesen...

Mein Problem hört sich eher nach dem von Brilwing, ein paar Posts früher, an...

Ich habe auch noch nicht ganz ausgeschlossen, dass es sich bei mir um Bitfehler handelt - vielleicht ist die Fehlerbehandlung mit xv einfach besser als mit vdpau. Ich kann allerdings bei der xv-Ausgabe keinerlei kaputte Blöcke erkennen - femon zeigt ebenfalls keine Fehler an (wenn Blöcke kaputt gehen, sehe ich das normalerweise in femon).

Ich werde am Wochenende mal die neuste Version von xine-vdpau testen.

Hi,

nachdem ich ich es nun endlich geschafft habe xine-vdpau und das xine-plugin ans laufen zu bekommen, muss ich sagen, das ich von der Qualität nich sehr überzeugt bin.

- Die Umschaltvorgänge dauern länger
- Beim Umschalten habe ich "Knistern und Knacken" in den Lautsprechern
- Das OSD des VDR ändert ständig seine Größe
- Bei HD Kanälen dauert das bis zu 15 Sek. bis es "Klötzchenfrei" ist.

Als positiv muss ich vermerken, dass die CPU Last nie über 15% hinaus ging.

Du meinst von deiner Qualitaet

Deine Probleme habe ich (und andere auch) nicht.

bye

Zitat

Original von C-3PO
- Die Umschaltvorgänge dauern länger

Verglichen mit was? Eine FF hatte ich nie also kann ich damit auch nicht vergleichen. Zumindest sind die Umschaltzeiten kürzer als bei meinem Samsung Küchenfernseher mit eingebautem DVB-T-Tuner.

Zitat

Original von C-3PO
- Beim Umschalten habe ich "Knistern und Knacken" in den Lautsprechern

Keine Spur, überhaupt keine Störungen. Egal ob über HDMI, oder über Line-Out.

Zitat

Original von C-3PO
- Das OSD des VDR ändert ständig seine Größe

Kenne ich auch nicht, hört sich nach einer Fehlkonfiguration an.

Zitat

Original von C-3PO
- Bei HD Kanälen dauert das bis zu 15 Sek. bis es "Klötzchenfrei" ist.

Ich habe leider noch keine HD-Kanäle, aber da scheint es wohl tatsächlich noch ein Problem zu geben, wobei ich eine so lange Zeit noch nirgendwo gelesen habe.

Ich muss die Aussage allerdings relativieren. Ich habe das xine-plugin nur kurz ausprobiert und benutze jetzt xineliboutput mit xine-vdpau.

Gerald

Hi zusammen,

ich denke mal die Meisten hier "fahren", wie ich, mit xineliboutput, oder?

Solch ein Verhalten (wie C-3PO) schildert, kann ich in allen 4 angeführten Punkten nicht nachvollziehen.

- SD-Umschalten unter einer Sekunde

- S2-Umschalten, bis ruckelfrei ca. 3 Sekunden (abhängig vom Kanal)

- Sound beim Umschalten ohne Knacken oder sonstwas

- OSD naja, da hat sparkie mal einen Patch gebaut, der behebt das Zappeln beim xineliboutput, zudem ist bei mir das OSD auf 1920x1080 gepatcht im VDR => egal ob SD oder DVB-S2 immer gleiche Größe.

- Die Klötzchen dürften ne Einstellung in xine-Plugin mit den Buffern sein.

PS: ich würde dir, C-3PO, empfehlen xineliboutput zu Nutzen.

Gruß
Wolfgang

Zitat

Original von wbreu
- Sound beim Umschalten ohne Knacken oder sonstwas

- Die Klötzchen dürften ne Einstellung in xine-Plugin mit den Buffern sein.

Gruß
Wolfgang

Buffers hilft wahrscheinlich auch bei den Soundproblemen. Ich fahre auf drei verschiedenen Rechner mit xineliboutput. Am empfindlichsten ist bei mir Digitalsound-Wiedergabe über den DD-Receiver. Eine Erhöhung der AudioBuffers auf 5000 brachte aber deutlich Entspannung. Allerdings spielt der Audio-Dekoder im Receiver oder Fernseher auch eine Rolle. Es kommt immer zu einem Bruch im Soundsignal beim Kanalwechsel. Manche Receiver muten andere geben leider ein Knacksen wieder.

Gruss

hemonu

Zitat

Original von wbreu
Hi zusammen,

ich denke mal die Meisten hier "fahren", wie ich, mit xineliboutput, oder?...

Zitat

....PS: ich würde dir, C-3PO, empfehlen xineliboutput zu Nutzen....

Würde ich ja machen, aber leider konnte/wollte mit ja Niemand bei dieesem Problem helfen...
--> Ein paar Fragen zu xineliboutput
Das Lustige ist nur, wenn ich poste dass ich mit xineliboutput Probleme habe, dann wird mir empfohlen das xine-Plugin zu nehnem, - wenn ich nun aber Probleme mit dem xine-Plugin melde, dann heist es , "nimm xineliboutput???

Mit persönlich ist es egal, was zur Ausgabe verwendet wird, - nur laufen sollte halt es irgrndwann mal....

Zitat

Original von gda
Verglichen mit was? ...

Verglichen mit der eHD.

Nun, ich bin nicht der Profi, was X und xine angeht, aber wenn es wirklich nur an den Settings liegt, dann ist die Sache doch sicherlich in der Griff zu bekommen, oder?

Die Frage ist nun, was und wo ist denn einzustellen, um es zu optimieren?

Gibt es denn irgendwo eine Übersicht/Zusammenfassung der empfohlenen Einstellungen?

Leider sind die Threads, die vdpau betreffeen alles so angeschwollen und unübersichtlich geworden.
Wenn es bei mir jemals sauber laufsollte, dann bin ich auch bereit eineZusammenfassung zu posten.

Zitat

Originally posted by Hemonu
Die xine-vdpau 1.16 aus dem svn ist ein Debian-Quellpaket. Zumindest unter Ubuntu 8.10 kann man alle Abhängigkeiten auflösen und dann mit dpkg-buildpackage ein Debian-Paket bauen. Unter Lenny habe ich mir allerdings die Zähne ausgebissen:(
Paket installieren, xineliboutput neu kompilieren (geht auch mit dem Hanno/etobi Quellpaket), installieren und voila.

hemonu

danke, habs nach ein bisschen geraffel auch unter lenny zum bauen gebracht:

cd /usr/src
mkdir vdpau
cd vdpau
apt-get install automake cvs autoconf subversion w32codecs
apt-get build-dep libxine1
svn co svn://jusst.de/xine-vdpau
cd xine-vdpau
touch config.rpath
autoreconf -f -i
nano debian/control
-> dort bei Build-Depends den automake eintrag entfernen (oder nur die versionsnummer)
nano debian/rules
-> dort bei CONFIGURE_FLAGS folgendes ergaenzen (zwischen --enable-ipv6 \ und $(DEB_BUILD_CONFIG_OPTIONS) \):
        --enable-vdpau \
        --enable-w32dll \
        --with-w32-path=/usr/lib/win32 \
nano debian/shlibdeps.sh
-> dort beim dpkg-shlibdeps aufruf --ignore-missing-info hinzufuegen
nano debian/changelog
-> dort den namen anpassen an 1.1.16 (ohne ~hg-0, dann meckert xineliboutput nicht)
dpkg-buildpackage -tc


cd ..
et voila - die debs :)

allerdings noch nicht getestet - muss nachher gleich mal meine 9300GE einbauen

infini

Hallo

Zitat

Original von C-3PO

...aber wenn es wirklich nur an den Settings liegt, dann ist die Sache doch sicherlich in der Griff zu bekommen, oder?

eigentlich schon.

Hier läuft seit drei Wochen ein Rechner mit vdpau übers xine-plugin sehr zuverlässig und ohne die von dir beschriebenen Probleme.

Zitat

Original von C-3PO

Die Frage ist nun, was und wo ist denn einzustellen, um es zu optimieren?

Außer

engine.buffers.video_num_frames:22

und

# device used for mono output
# string, default: default
audio.device.alsa_default_device:hdmi


# device used for stereo output
# string, default: plug:front:default
audio.device.alsa_front_device:hdmi

habe ich in der .xine.config nichts angepasst. Die Einstellungen für die Soundausgabe gelten für onboardgrafik mit Ausgabe über hdmi, bei Ausgabe über eine Graka sollten die defaults funktionieren.

Meine xine-plugineinstellungen sehen so aus:

xine.autoPrimaryDeviceMode = autoPrimaryDeviceOn
xine.image16:9.zoomX = 105
xine.image16:9.zoomY = 105
xine.image4:3.zoomX = 115
xine.image4:3.zoomY = 115
xine.interactWithEitScannerMode = interactWithEitScannerOff
xine.modeLiveTV.monitoringDuration = 60
xine.modeLiveTV.monitoringMode = monitoringOnce
xine.modeLiveTV.prebufferFrames = 4
xine.modeLiveTV.prebufferHysteresis = 4
xine.muteMode = muteSimulate
xine.osdGammaCorrection = 250
xine.osdMode = osdBlendScaledSHQ
xine.transparencyMode = transparencyOn
xine.volumeMode = volumeChangeSW

Aufgerufen wird xine (ohne laufendes X) mit

xinit -e xine --bug-report -V vdpau -f -g --no-splash --post vdr_video --post vdr_audio vdr://tmp/vdr-xine/stream#demux:mpeg_pes

dabei loggt die Option --bug-report in die Datei /BUG-REPORT.TXT was xine so treibt;)

Der 4850e@1.80GHz idelt dann im Schnitt um die 96% vor sich hin, ob HD oder SD macht da kaum einen Unterschied.

Zitat

top - 10:04:55 up 1:50, 2 users, load average: 0.00, 0.02, 0.00
Tasks: 80 total, 1 running, 79 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 1.0%sy, 0.5%ni, 97.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1544552k total, 504680k used, 1039872k free, 172608k buffers
Swap: 1951888k total, 0k used, 1951888k free, 121336k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3453 root 20 0 493m 39m 9.9m S 4 2.6 6:27.90 xine
3418 root 20 0 362m 32m 7552 S 2 2.2 3:35.95 vdr

Alles anzeigen

Gruß, tomas

Zitat

Original von wbreu
[..]
- S2-Umschalten, bis ruckelfrei ca. 3 Sekunden (abhängig vom Kanal)
[..]

hallo,

das dauert hier leider etwas länger - von 20 sec. bis zu 1 minute (bei den zwei 1080i sendern am astra 19E). ist aber nicht soo tragisch ..

gruß, ciax

Zitat

Original von ciax

hallo,

das dauert hier leider etwas länger - von 20 sec. bis zu 1 minute (bei den zwei 1080i sendern am astra 19E). ist aber nicht soo tragisch ..

gruß, ciax

Alles anzeigen

hmm...

Bei der eHD gibt es diese Probleme nicht.

Woran liegt das, -an xine?

Hi,
bei mir geht das umschalten auch auf 1080i sender zackig.

Die eHD macht meiner meinung aber noch ein viel besseres bild.

Ich werde meine Qualitätseinstellungen nochmal überprüfen...

Gruß,
Chris

Zitat

Original von C-3PO

hmm...

Bei der eHD gibt es diese Probleme nicht.

Woran liegt das, -an xine?

Alles anzeigen

Hallo,

das liegt an der Geschwindigkeit des Erkennens welches Format der Sender im Moment ausstrahlt.

Der Erkennalgorithmus ist in xine-vdapu integriert.

Wenn du mal xine mitloggst, evtl. auf der Konsole, sieht man was der VDR/xine macht, wenn umgeschaltet wird.

Genau dieser Pufferalgo braucht noch ein bisschen Finetuning sowohl bei NVidia - xine-vdpau - xine - xineliboutput.

Wenn man die letzten Änderungen im SVN ansieht, kann man gut Erkennen, dass die Programmierer intensiv daran arbeiten!

Hier in dem Thread habe ich schonmal ein Post gemacht, der zeigt, was beim umschalten abgeht und wie schnell es bereits geworden ist. Ist glaube ein Anhang mit dem ganzen Log.

Gruß
Wolfgang

Sorry wenn ich hier eine vielleicht OT - Frage stelle . Die ersten Seiten habe ich mit verfolgt nur mittlerweile ist der Thread... etwas gewachsen

Ist die VDPAU + VDR Geschichte soweit, dass sie entsprechend eingerichtet auf einen "nur-Benutzer"

losgelassen werden kann? Also sprich SDTV und HDTV sieht vernünftig aus ohne Ausetzer oder der

gleichen, Aufnahmen wiedergeben funktionieren und das ganze ohne dass es Abstürtze gibt? ... sprich

ist die Lösung schon so perfekt, dass sie im Alltag läuft?

Wer irgendwie zuviel Zeit hat kann mir ja auch ne PN schreiben, würde mich freuen.

Sorry das ich die Frage unterbreche, aber folgendes Problem will ich noch loswerden - es gibt auch Bilder

Der Tipp von Wolfgang bzgl. Deinterlacing funktioniert nun - allerdings fällt mir dabei auf, dass es damit (IMHO höchste Stufe temporal_spatial) anfängt mit Ruckeln, kann das sein? Ich dachte immer, entweder temporal_spatial geht, oder es geht nicht - oder ist es so, dass es geht, aber auch von der HW abhängig ist, sprich "ruckeln" bei langsamer HW?

Neben dem Ruckeln, habe ich vor allem bei Anixe HD, folgenden Streifen-Effekt (schon oft von mir beschrieben hier):

[Blockierte Grafik: http://img9.imageshack.us/img9/745/snapshot20090320232840.jpg] oder [Blockierte Grafik: http://img9.imageshack.us/img9/8897/snapshot20090320232941.jpg]

Kennt das jemand auch und weiss ggf. woher das kommt? (Zur Info: es ist eine Handyaufnahme des Bildschirms, die Streifen sind m.E. gut sichtbar, um die es geht - diese treten recht häufig auf, vor allem bei bewegten Bildern).

Meine Vermutungen:

- AMD CPU/Speicherproblem wie schon beschrieben - behebar? indem man die CPU nicht heruntertaktet
- Deinterlacing wie oben angesprochen
- eine Kombination aus beiden?

Gruss
Marcus

Hallo Marcus,

nimm nur temporal.

Damit hast du keine Probleme mit verlorenen Frames.

Sag mal hast du kein Log in dem man das sieht, wenn Frames gedroppt werden?

Wolfgang