HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

habs mcli-plugin gestern durchlaufen lassen (wird auch vom vdr geladen)
leider startet der vdr nicht
hatte aber den vdr vorher auch noch nicht gestartet > werde das system also noch mal gaaaaaanz von vorne aufsetzen
(geht ja mit archvdr sehr gut und schnell )
hatte am Anfang vieles als root installiert vielleicht habe ich da etwas mit gekillt.

ansonsten wenn man manche filme zum ersten mal ruckelfrei sieht denkt man sich nur > Intel da habt ihr ne schöne hardware gebaut

der cpu-kühler bleibt eiskalt der lüfter geht erst gar nicht an

cpu-last xbmc max 5% im schnitt (1. kern 6% der 2. 4%) und das bei 1080p und 36mbit video-datenrate

muss nur noch den Stromverbrauch messen.

Hi Moorviper,

bevor du alles neu aufsetzt (auch wenn das dank der schmalen Struktur von Arch schnell geht) schau doch erstmal in die Logs rein. Dort bekommst du sicher einen Hinweis darauf warum der VDR nicht startet. Manchmal werden einfach ein oder mehrere Konfigurationsdateien nicht gefunden und der VDR beendet sich einfach wieder. Besonders wenn der VDR nach dem installieren eines Plugins nicht startet lohnt sich ein Blick in die Logdatei.

Gruß
Atech

hab schon drüberinstalliert bzw läuft

in den logs stand nichts brauchbares drin -> wenn man das Gefühl hatte er startet
stürzte er so "stark" ab das nichts geloggt wurde

edit: bei der frontend config muss ich ja

(/etc/default/vdrfrontend )
FRONTEND=xinevaapi

auswählen oder ???

Ja

Was muss ich machen, damit ich auf den vaapi-testing branch komme? Ich habe gemacht

git clone git://github.com/huceke/xine-lib-vaapi.git
cd xine-lib-vaapi
git checkout vaapi-testing

Bei letzterem Befehlt ist aber so wenig passiert, dass ich irgendwie daran zweifle, dass das ausreicht.

Christoph

Edit: Auf der anderen Seite läuft es und scheinbar recht ordentlich. Habe aber auch nur kurz getestet:

intel-vaapi-driver: git
libva: git
ffmpeg: git
xine-ui: cvs

Moin,

Passt schon, es gibt auch fähige Entwickler.
Mach einfach "git status", dann siehst welchen branch du hast.

Johns

Alles klar. Danke. Der Branch passt, auch wenn ich noch nicht ganz verstanden, wie GIT diesbzgl. tickt

Ich bin ja der Meinung, das sowohl bei SD und HD bei VAAPI-Sandy-Bridge der Deinterlacer läuft.

Hier noch mal der Link für die Deinterlacer Test Clips: http://www.avsforum.com/avs-vb/showthread.php?t=1157287

Müsste man eigentlich über xine <file> testen können?

Johns

Nur auf Sandy-Bridge? Was ist mit Clarkdale?

Hi Leute,

laut dieser Tabelle www.missingremote.com/guide/basic-overview-gpu-hd-video-processing+intel+clarkdale+deinterlace&cd=7&hl=de&ct=clnk&gl=de&client=firefox-a'] hier[/url] unterstützt intel HD Clarkdale das intel advanced motion-adaptive deinterlacing Verfahren. Da sich die Tabellen aber vermutlich auf die Windows Treiber beziehen gehe ich davon aus, das der Videotreiber für Linux das nicht unterstützt.

Vielleicht solltern wir mal einen eigenen Thread aufmachen. Ebsi wollte ja von der deinterlace Diskussion hier eigentlich nichts Wissen - nichts für ungut ebsi ;).

Gruß
Atech

Zitat von Flachzange

Nur auf Sandy-Bridge? Was ist mit Clarkdale?

Ich kann nur von Sandy Bridge sprechen, weil ich diese teste.
Und wollte nicht allgemein schreiben, damit kein falscher Eindruck entsteht.
Vorhanden sollte es sein, aber ob es funktioniert musst selber testen.

Deinterlacer arbeitet bei SD und HD. Zwischen vaapi_mpeg_softdec/vaapi_mpeg_softdec_deinterlace und video.output.vaapi_deinterlace
ist kein Unterschied. Sieht mir fast wie "Skip Field" Deinterlacer aus.

Xine Software Deinterlacer Greedy2Frame und GreedyH schauen besser aus.

Atechsystem
Dein link ist kaputt.

Johns

Hi,

ja da hat sich der Fehlerteufel eingeschlichen. Dann hier nochmal:

http://www.missingremote.com/g…w-gpu-hd-video-processing

Gruß
Atech

nabend, ich hatte mich nach der Update-Orgie in der letzten Wochen gewundert, warum die Umschaltzeiten recht hoch waren und xine beim Umschalten mit einer sehr hohen Wahrscheinlichkeit (> 50%) freezed. Heute hab ich dann mal rumgespielt und video.output.vaapi_guarded_render:0 gesetzt. Damit läufts ordentlich, keine Freezes und schnelles Umschalten. Gibt es irgendwelche Bedinungen (Treiber, Kernel, etc) damit es auch mit der guarded Render Methode läuft?

Zitat von Flachzange

nabend, ich hatte mich nach der Update-Orgie in der letzten Wochen gewundert, warum die Umschaltzeiten recht hoch waren und xine beim Umschalten mit einer sehr hohen Wahrscheinlichkeit (> 50%) freezed. Heute hab ich dann mal rumgespielt und video.output.vaapi_guarded_render:0 gesetzt. Damit läufts ordentlich, keine Freezes und schnelles Umschalten. Gibt es irgendwelche Bedinungen (Treiber, Kernel, etc) damit es auch mit der guarded Render Methode läuft?

Hi,

das hört sich noch dem libxcb Problem an. Ich musste libxcb patchen.

https://archvdr.svn.sourceforg…/xcb_wait_for_reply.patch

lg

ebsi

stimmt..hatte ich ja gerade letzte Woche selbst noch hier gelesen...blödes Kurzeitgedächtnis...*schäm*

Ich probiere es mal aus. Danke!

Edit: Scheint zu funktionieren...komisch

Zitat von Flachzange

stimmt..hatte ich ja gerade letzte Woche selbst noch hier gelesen...blödes Kurzeitgedächtnis...*schäm*

Ich probiere es mal aus. Danke!

Edit: Scheint zu funktionieren...komisch

Ach ja, das Kurzzeitgedächtnis. Funktioniert bei mir auch prima

lg

ebsi

Seltsam, dass hier nichts mehr gepostet wurde

Also ich hampel seit meinem letzten Post/seit Wochen leider immernoch mit dem gleichen Problem rum. Es lag offensichtlich nicht an der libxcb und hatte nur zufällig funktioniert. Das Umschalten ist nachwievor eine Katastrophe. Manchmal funktioniert es, manchmal funktioniert es ein paar Male, aber meistens geht es einfach gar nicht. Nach dem Umschalten hängt xine mit einem schwarzen Bild. Manchmal hilft dann einfach lange zu warten, manchmal läuft der vdr in einen Timeout, was aber immer witzigerweise funktioniert ist, das OSD-Menü aufzurufen. Dann wird der Kanal auch in xine umgeschaltet (mit angezeigtem OSD).

Anfang dieser Woche bin ich dann auf Ubuntu 11.10 mit 3.0er Kernel, aber es ist exakt das gleiche Verhalten wie vorher. Habe auch immer mal wieder treiber, libva, xinelib-vaapi aktualisiert. Alles ohne irgendetwas an dem Problem zu ändern.

Hat jemand eine Idee, wie ich das Debuggen könnte?

Grüße

Edit: Das ist zum Verrückwerden. Jetzt läuft es gerade astrein. Auch nach einem Neustart. Mir ist aufgefallen, dass ich mpeg2 softdecoding deaktiviert hatte und vaapi deinterlace aktiviert. Ob es daran liegt?

Vielleicht liegts daran das du den Vorgänger "Ironlake" hast?

Mit Sandy Bridge und media-libs/mesa media-libs/xine-lib x11-drivers/xf86-video-intel x11-libs/libdrm x11-libs/libva x11-libs/libxcb x11-libs/pixman x11-proto/xcb-proto GIT und xine-ui (0.99.6) ffmpeg (0.8.5) xorg-server(1.11.1) linux (3.0.6) vdr-xine (0.9.4) als normalen Release habe ich keine Umschalt Probleme.

Bugs:

• Deinterlacer ist nicht das Beste (liegt an libva)
• Scaler ist nicht der Beste (liegt an libva)
• Sobald ein GUI Fenster geöffnet wird, hängt die GPU
• xineliboutput hat die Umschalthänger
• OSD wird mit dem Videobild skaliert, wechselt die Größe bei 4:3 / 16:9

Johns

Nachdem ich jetzt auf mpeg2 softedecoding umgestellt habe, läuft es schon mehrere Tage ordentlich.

Jetzt habe ich aber auf Ubuntu 11.10 aktualisiert und sobald die vaapi-Sachen aktiviert werden (z.B. durch xine oder xbmc) schmiert irgendetwas im gnome bzw. unity ab, konkret gibt es einen Fehler in libpixman:

Oct 25 12:47:02 carla kernel: [  727.584766] do_trap: 30 callbacks suppressed
Oct 25 12:47:02 carla kernel: [  727.584770] bamfdaemon[1667] trap divide error ip:7f3c17967337 sp:7fff710deae8 error:0 in libpixman-1.so.0.23.6[7f3c17918000+84000]
Oct 25 12:47:02 carla kernel: [  727.734192] unity-2d-launch[1653] trap divide error ip:7fa7be4ae337 sp:7fff8db3de38 error:0 in libpixman-1.so.0.23.6[7fa7be45f000+84000]
Oct 25 12:47:02 carla kernel: [  727.734659] unity-2d-panel[1652] trap divide error ip:7f5c72720337 sp:7fff2edddd48 error:0 in libpixman-1.so.0.23.6[7f5c726d1000+84000]
Oct 25 12:47:02 carla gnome-session[1206]: WARNING: Application 'unity-2d-panel.desktop' killed by signal
Oct 25 12:47:02 carla kernel: [  727.940956] bamfdaemon[2407] trap divide error ip:7f7b896ac337 sp:7fff7e6cb348 error:0 in libpixman-1.so.0.23.6[7f7b8965d000+84000]
Oct 25 12:47:02 carla lircd-0.9.0[1222]: accepted new client on /var/run/lirc/lircd
Oct 25 12:47:02 carla lircd-0.9.0[1222]: removed client
Oct 25 12:47:02 carla kernel: [  728.103202] bamfdaemon[2424] trap divide error ip:7fe3afb99337 sp:7fff7a0c9df8 error:0 in libpixman-1.so.0.23.6[7fe3afb4a000+84000]
Oct 25 12:47:02 carla kernel: [  728.193559] bamfdaemon[2438] trap divide error ip:7f45aa6ab337 sp:7fff9d426308 error:0 in libpixman-1.so.0.23.6[7f45aa65c000+84000]
Oct 25 12:47:03 carla kernel: [  728.323971] bamfdaemon[2446] trap divide error ip:7f4af88d4337 sp:7fff2b142858 error:0 in libpixman-1.so.0.23.6[7f4af8885000+84000]
Oct 25 12:47:03 carla gnome-session[1206]: WARNING: Application 'unity-2d-launcher.desktop' killed by signal
Oct 25 12:47:03 carla kernel: [  728.584930] bamfdaemon[2449] trap divide error ip:7ff138161337 sp:7fff5ce33fa8 error:0 in libpixman-1.so.0.23.6[7ff138112000+84000]

Hat da jemand ähnliche Probleme?

Noch mal zur Ergänzung..der X Server läuft ganz normal weiter und auch xine etc funktioniert, aber das ganze gnome zeugs ist halt weg und lässt sich nicht mehr bedienen

So habe mal wieder einen Patch:

diff --git a/src/video_out/video_out_vaapi.c b/src/video_out/video_out_vaapi.c
index d5ad1bc..97fd3f1 100644
--- a/src/video_out/video_out_vaapi.c
+++ b/src/video_out/video_out_vaapi.c
@@ -3187,6 +3187,7 @@ static VAStatus vaapi_hardware_render_frame (vo_driver_t *this_gen, vo_frame_t *
       if(!vaapi_check_status(this_gen, vaStatus, "vaPutSurface()"))
         return vaStatus;
     }
+    usleep(1 * 1000);
   }
   return VA_STATUS_SUCCESS;
 }

Damit funktioniert nun vdr-xinelibout ohne dieses Problem:

[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 43825 at
 43814, next 43827)
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 43839 at
 43831, next 43841)
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 43852 at 43845, next 43854)
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 43866 at 43858, next 43868)
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 43880 at 43872, next 43882)

Scheinbar hat der Inteltreiber ein Problem, wenn die GPU zuviel zutun hat.

Johns