Wie sehe ich, dass vdpau läuft?

    Hallo,


    ich habe testhalber VDR mit Xine-Plugin und xine-vdpau aufgesetzt. Ausgabe auf der Grafikkarte funktioniert soweit.


    Ich habe eine CPU-Last um die 10% trotz VDPAU (SDTV). Wenn ich den Grafik-Treiber auf vesa stelle, dann steigt die CPU-Last auf 30%.


    Was mich stört ist, dass auch, wenn ich xine mit "--verbose" starte, keinerlei Hinweise auf VDPAU auftauchen.


    Wie stelle ich sicher fest, dass VDPAU läuft?


    Wie kann ich eigentlich den gewünschten Deinterlacer wählen? In Verwendung ist, wie gesagt, das Xine-Plugin. Angezeigt wird via xine-ui.

    Hallo,


    die Ausgabe des benutzen Videotreibers sollte eigentlich angezeigt werden. Hier z.B. bei xv


    Code
    $ xine -V xv --verbose
.....
load_plugins: Plugin /usr/lib/xine/plugins/1.25/xineplug_inp_mms.so gefunden
load_plugins: Plugin /usr/lib/xine/plugins/1.25/xineplug_vo_out_raw.so gefunden
load_plugins: Plugin /usr/lib/xine/plugins/1.25/xineplug_vo_out_syncfb.so gefunden
video_out_xv: Benutze Xv-Port 227 von Adapter NV17 Video Texture for Hardware-Farbraumtransformation und Skalierung.
video_out_xv: ignoring broken XV_HUE settings on NVidia cards
video_out_xv: Adapter unterstützt YUY2 Format.
video_out_xv: Adapter unterstützt YV12 Format.
.......


    bzw. vdpau (natürlich nur, wenn ein entsprecheder NVIDIA-Treiber geladen ist)


    Code
    .....
load_plugins: Plugin /usr/lib/xine/plugins/1.25/xineplug_inp_mms.so gefunden                                                                                          
load_plugins: Plugin /usr/lib/xine/plugins/1.25/xineplug_vo_out_raw.so gefunden                                                                                       
load_plugins: Plugin /usr/lib/xine/plugins/1.25/xineplug_vo_out_syncfb.so gefunden                                                                                    
vo_vdpau: vdpau API version : 0                                                                                                                                       
vo_vdpau: vdpau implementation description : NVIDIA VDPAU Driver Shared Library  185.18.36  Fri Aug 14 18:28:21 PDT 2009 
.....


    typisch bei vdpau sind dann noch solche Blöcke beim Umschalten:


    Code
    ...
vdpau_set_property: property=0, value=1
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: enabled features: inverse_telecine=1
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0,000000, saturation=1,000000, contrast=1,000000, brightness=0,000000, color_standard=0
....


    Bei SD wird immer temporal_spatial als Deinterlacer verwendet, es sei denn man schaltet den Deinterlacer in der ~/.xine/config komplett aus:


    Code
    # Deinterlacing automatisch aktivieren
# bool, default: 0
#gui.deinterlace_by_default:0


    Im laufenden Betrieb kann man den Deinterlacer bei angeschlossener Tastatur auch mit *i* ein- und ausschalten


    Bei HD hat man die Auswahl z.B.


    Code
    # vdpau: HD deinterlace method
# { bob  half temporal  half temporal_spatial  temporal  temporal_spatial }, default: 3
video.output.vdpau_deinterlace_method:bob


    btw: was verstehst du unter *Xine-Plugin*? Viele die vom xine-plugin schreiben meinen xineliboutput. Zur Unterscheidung wäre es vielleicht ganz gut, wenn man sich auf die Bezeichnungen *xineliboutput* und *vdr-xine* einigen könnte:)


    Gruß, tomas

    Das würde dann zwangsweise bedeuten, dass bei mir kein VDPAU läuft, da das Wort "vdpau" nirgends in der Ausgabe von "xine --verbose" auftaucht.


    Frage ist nur *warum* es nicht läuft. NVIDIA-Treiber läuft natürlich. Ich habe den aktuellen Beta-Treiber verwendet.


    xine-vdpau habe ich aus dem SVN ausgecheckt und mit folgenden Optionen gebaut:


    ./autogen.sh \
    --prefix=/usr \
    --mandir=/usr/man \
    --with-w32-path=/usr/lib/codecs \
    --disable-nosefart \
    --without-speex \
    --without-imagemagick \
    --disable-aalib \
    --without-caca


    Ich verwende "vdr-xine".

    nabend Mreimer


    du "musst" vdpau auch erstmal aktivieren, dazu klick einfach mal die rechte maustaste im xine-ui fenster, dann auf einstellungen. dort stellt du wo "beginner" steht, auf "master of universe" aktivierst "deinterleacing by default" und unter video, video driver "vdpau" und je nach grafik chip auf deinterleasing methode "temporal_spartial"


    P.S.: wenn sich vdpau nicht auswählen lässt dann stimmt was mit xinelib ned

    MfG


    bex


    server -> Asus p8h67-i -Intel 2100T - Cine CT v6

    client 1 -> Asus p5n7a-vm -Intel E5200 - Technisat Cablestar HD 2

    client 2+3 -> Raspberry Pi - Openelec

    Einmal editiert, zuletzt von bexbier ()

    Problem (hoffentlich) gefunden. Ich habe xine-vdpau gebaut, während der Nvidia-Treiber auf der Build-Maschine nicht installiert war. Folglich wurde das VDPAU-Ausgabemodul garnicht mit gebaut und ich habe ein "normales" Xine. Mal sehen was passiert, wenn ich mit installiertem Treiber neu baue.

    Jetzt läuft VDPAU. Allerdings habe ich jetzt Crashes, wenn ich das VT wechseln will (Strg + Alt + F...). Im Einsatz ist der aktuelle Stable-Treiber von Nvidia mit der Onboard-Grafik des EM3N78-EM Mainboards (8300).


    Mit X-Server via runvdr-extreme aufgestartet sorgt das nur dafür, dass sich der VDR beim VT-Wechsel beendet. Wenn ich aber via "init 4" einen Login-Manager starte, dann sorgt der Bug dafür, dass ich das VT garnicht mehr wechseln kann (X-Server startet beim Wechseln des VT neu und wechselt so immer wieder zum X-Server-VT).


    Sorry, aber das bestätigt nur mal wieder meine Meinung, dass Closed Source Treiber *SCHEIßE* sind!


    Eine 9500er Karte ist bestellt. Mal sehen ob sich das Problem dann bessert. Sollte es immer noch Probleme geben, dann geht die 9500er postwendend zurück und eine eHD wird bestellt...

    Ganz einfach, weil das Problem mit keinem anderen Treiber, den ich mit der verfügbaren On-Board-Karte nutzen kann, auftritt. Crashs gibt es nur mit Nvidia-Treiber.


    Wenn ich mich bei dem "tollen" nvnews-Board anmelden will, dann wird meine Mailadresse abgelehnt. Sorry, aber ich habe nur eine Freemailer-Adresse. Kann ich ja nichts für, wenn die keine anständige Lösung für das Abwehren von Bots einrichten können.


    Umstieg auf 9500er Grafikkarte war ohnehin geplant. Ich hoffe nur, dass ich die Onboard-Karte halbwegs sicher tot kriege, sodass der Nvidia-Treiber dann nur noch auf der eingesteckten Karte rumfuhrwerkt und so hoffentlich nicht mehr crasht.

    Hallo,


    vielleicht sollte man erst mal versuchen das Problem einzugrenzen und solange die *Unschuldsvermutung* gelten lassen;)


    Ich hab da mal etwas rumprobiert:


    M3N78-EM, NVIDIA-185.18.36


    Start von VDR mit vdr-xine und xine-ui (-V vdpau) über runvdr-extreme


    Beim Wechsel vom *X-VT* zu einem anderen VT: Der Ton vom VDR ist noch zwei bis drei Sekunden zu hören, dann bricht er weg xine hängt - X und VDR laufen weiter!


    xine-log:



    Wenn ich in diesem Stadium xine-ui kille und neu starte, wird problemlos eine Verbindung mit dem noch laufenden VDR aufgebaut und xine-ui startet auf dem VT mit dem noch laufenden X-Server.



    Für mich sieht das mehr nach einem Problem mit xine-vdpau aus.....



    Gruß, tomas

    Mit dem aktuellen Stable-Treiber braucht es bei mir nichtmal VDPAU. Es reicht aus, wenn ich einen Login-Screen (xdm) aufstarte, indem ich in Runlevel 4 schalte. Wenn ich vom offenen Login-Screen auf ein anderes Terminal schalten will, dann crasht der X-Server, wird neu gestartet und ich bin wieder beim Login-Screen. Einzige Möglichkeit diesen Teufelskreis zu verlassen ist dann, sich tatsächlich anzumelden und in einem xterm ein "init 3" abzusetzen.


    Mit dem aktuellen Beta-Treiber bekomme ich aber einen Effekt, der deinem in Etwa gleicht. Auch hier braucht es aber kein VDPAU. Xine-VDPAU hängt sich auch auf, wenn XV für die Ausgabe genutzt wird. Allerdings nur, wenn das Xine-Plugin "NO SIGNAL" anzeigt. Mit angeschlossenem Sat-Kabel ist die XV-Ausgabe stabil.


    Alles in allem scheint mir das doch recht fummelig... :(

    Zitat

    Original von Mreimer
    Mit dem aktuellen Stable-Treiber braucht es bei mir nichtmal VDPAU. Es reicht aus, wenn ich einen Login-Screen (xdm) aufstarte, indem ich in Runlevel 4 schalte. Wenn ich vom offenen Login-Screen auf ein anderes Terminal schalten will, dann crasht der X-Server, wird neu gestartet und ich bin wieder beim Login-Screen. Einzige Möglichkeit diesen Teufelskreis zu verlassen ist dann, sich tatsächlich anzumelden und in einem xterm ein "init 3" abzusetzen.


    Das kann ich hier nicht reproduzieren.


    Bei Ausgabe über xv gibt es hier keinerlei Probleme, weder beim Start über runvdr-extreme (ohne Desktopmanager) noch wenn ich aus KDE heraus den VDR und xine-ui laufen lasse. Wechsel zu VTs und zurück zu X führen zu keinen Hängern. Wechsel des runlevels von 2 (kde) nach 3 (nur VDR mit xine-ui) und zurück funktioniert auch. Der betreffende Rechner hat keine DVB-Karte und wird z. Zt. auch nicht von einem Streamdev-server bedient, also auch "NO SIGNAL"!


    Ich hab gerade festgestellt, dass wenn ich xine-ui in der oben geschilderten Situation ein wenig Zeit gebe sich zu fangen , erholt es die wieder und die Ausgabe geht weiter......

    Also. Nach langem hin und her hat sich herausgestellt, dass der X-Server zumindest nicht unschuldig ist. Es ist einfach saumäßig dämlich einen Crash zu produzieren, wenn der HAL-Daemon nicht läuft! Das ist auf jedem Fall ein Bug-Report für X wert. Besonders dämlich ist das vor allem, weil ich HAL in der xorg.conf abgestellt habe.


    Nun habe ich gute Lust den X-Server vorbei an der Distribution neu zu kompilieren. Diesmal aber ohne HAL-Support. Mal sehen wie viel Aufwand das bedeutet.


    Ich bin dann auch soweit, dass alles soweit stabil läuft, aber Xine sich komplett aufhängt, wenn ich einen VT-Switch mache (ein normales "kill" reicht dann nicht mehr. Es muss schon der "Dampfhammer" "kill -9" her).


    Frage ist nun letztlich, wer hier schuld ist. Ist das ein bekanntes Problem? Tritt sowas in der Form auch mit xineliboutput auf?


    Nachtrag: Bugreport für X:
    https://bugs.freedesktop.org/show_bug.cgi?id=23850


    Nachtrag2:
    http://lists.kafic.ba/pipermai…009-September/000096.html

    nabend,


    hab grad mal auf meinem wz vdr versucht auf den nvidia treiber 185.18.36 und xine-lib-1.2 mit r278patch upzudaten. mit dem ergebnis das xine (xine-ui) einfriert und nur per killall beendet werden kann. also genau das was Mreimer geschrieben hat.
    Die lösung war zurück auf nvidia driver 180.51und in der src/video-out/video-out-vdpau.c "#define LOCKDISPLAY" zu aktivieren.
    Danach lief alles wieder wunderbar.


    scheint so als hätte sich irgendwas bei den neuen treibern geändert was in dem xine-lib-1.2-r178 patch nicht berücksichtigt bzw. nicht aktualisiert wurde. xine bieb immer mit der meldung "emergency exit" hängen. Beim zweiten aufruf von xine (mit laufenden vdr) ging dann der erste sender, beim umschalten blieb xine dann aber wieder mit selbiger meldung hängen.

    Hallo,


    also hier läuft es jetzt mit folgender Konstellation:


    NVIDIA-Linux-x86_64-185.18.36 und NVIDIA-Linux-x86_64-190.32, xine-vdpau-r281 mit deaktiviertem LOCKDISPLAY.


    Einziger Haken ist, dass beim Wechsel auf ein anderes VT xine auf einem Kern 70 bis 80% CPU-Last erzeugt, die aber beim Wechsel zum *xine-VT* wieder auf normal zurückgeht.


    Die hohe CPU-Last resultiert wohl aus massenweise


    Code
    vo_vdpau: Can't create presentation queue !! : The display was pre-empted, or a fatal error occurred.
vo_vdpau: vdp_video_mixer_render error : An invalid handle value was provided.
vo_vdpau: vdp_video_mixer_render error : An invalid handle value was provided.
vo_vdpau: VDPAU was pre-empted. Reinit.
vo_vdpau: Can't create presentation queue !! : The display was pre-empted, or a fatal error occurred.
vo_vdpau: vdp_video_mixer_render error : An invalid handle value was provided.
vo_vdpau: vdp_video_mixer_render error : An invalid handle value was provided.
vo_vdpau: VDPAU was pre-empted. Reinit.


    nach dem Umshalten zum *xine-VT* .....*vo_vdpau: Reinit done.*:


    Code
    vo_vdpau: deinterlace: temporal_spatial
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=1
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0,000000, saturation=1,000000, contrast=1,000000, brightness=0,000000, color_standard=0
vo_vdpau: skip_chroma = 0
vo_vdpau: Reinit done.


    Gruß, tomas

    Schade, dass das Einrichten der eHD wohl nicht ganz so trivial ist. Ansonsten hätte ich den Grafikkarten-Kram lange aufgegeben...


    Um das Problem einigermaßen zu entschärfen habe ich mir in die "runvdr.conf" (runvdr-extreme) eine Schleife programmiert, die ständig das aktuelle VT ermittelt (gebremst mit sleep 5) und bei Wechsel auf ein VT ungleich X-Server xine-ui wegkillt, bzw. bei Wechsel zum X-Server ein neues xine-ui hochstartet. So läuft das ganze jetzt zwar stabil, aber es bleibt ein Hack...

    tomas: Wie bzw. wo kommt man an solche Logausgaben zu VDPAU?

    MLD 5.5 mit VDR 2.6.4 & Kodi 19.4 - Gigabyte GA-F2A88XM-HD3 - AMD A8-7600 - 4 Gb RAM - Ausgabe via MSI N220GT-MD1GZ mit softhddevice & vdpau - 19.2E & 28.2E Empfang via Linux4Media L4M-Twin S2 ver 6.5 - Terratec Aureon 5.1 Fun TTP8 - Crucial m4 CT064M4SSD2 - Seagate Exos 7E8 in Scythe Quiet Drive SQD-1000 - Medion X10 RF Remote Control 20016398

    Einmal editiert, zuletzt von villeneuve ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden