[ANNOUNCE] xine-lib meets vaapi

Zitat

Original von micclass
Danke!

Leider wird dort auch nur auf die Ironlake Grafik verwiesen. Niemand redet von Sandybridge!

Nabend,

wenn du mir so eine CPU samt Board zukommen lässt, nehme ich die sandy's mit auf.

Also mal Spaß beiseite, seit einiger Zeit nehmen wir das xine-Plugin zum Testen.
Mit dem vdr-sxfe schau ich mal ob das im Moment überhaupt geht.

@Opp, die Intel-CPU hat keine Nvidia, die hat die Intel-GPU in der CPU mit drinnen!

Gruß
Wolfgang

ja stimmt ja hab inner schulung ja selber ne g45

Danke für die Antworten!

Mir ist schon klar, dass Sandbridge System noch rar sein dürften. Für 'nen reinen VDR wäre das System hier auch etwas Overkill. Das ist mein Arbeitsplatz PC (mit 16GB Speicher und 4TB Platten) auf dem immer 2-3 virtuelle Maschinen laufen, an dem 2 Monitore hängen und an dem eben auch mal via VDR etwas Glotze läuft (zumeist werden die Aufnahmen dabei von einem anderen vdr system via NFS gemountet).

Mein Problem des schwarzen Schirms (oder "scharzen Fensters" wenn nicht im Fullscreen mode) zieht sich mit vaapi über xine.-ui, xineliboutput und xine-plugin in der gleichen Weise. Ich gehe deshalb davon aus, dass etwas auf der xine-lib Schicht oder darunter schief läuft. Nachdem mplayer-vaapi mit -vo vaapi aber funktioniert, denke ich mal, dass drm, dri, und libva o.k. sein sollten. Hier bin ich mir jedoch nicht sicher. Verwendet mplayer-vaapi hier was anders, als die xine-lib Schiene?

Irgendwie such ich nach eriner Strategie wie ich das Problem auf (hoffentlich) eine Komponente einkreisen könnte.

Gruß Micha

Kurzes Update:

Problem gefixt:

engine.decoder_priorities.ffmpegvideo:1

in .xine/config_xineliboutput war mein Freund. Manchmal sind's doch die einfachen Dinge

Also zumindest kann ich nun bestätigen, dass vdr-1.7.17 mit xineliboutput auf einem Sandybridgesystem grundsätzlich funktioniert. Finetuning steht nun natürlich noch an.

Gruß Micha