[ANNOUNCE] xine-lib meets vaapi

  • Hi,


    Inspiriert von tbshl-vdr und seinen VAAPI experimenten habe ich mir mal die verschiedenen VAAPI Implementierungen angesehen. Es ist ein Patch für die xine-lib-1.2 ( development tree ) entstanden welcher das ffmpeg plugin um VAAPI unterstützung erweitert.
    Getestet wurde auf einem Core-I7 mit integrierter GPU. Intressant wäre, ob das ganze auch mit dem ATI(AMD) VAAPI backend funktioniert.


    Inspired by tbshl-vdr and his VAAPI experiments, i started to look at the different VAAPI implementations. The result is a patch for xine-lib-1.2 ( development tree ) which enhances the ffmpeg plugin with VAAPI support.
    The testing was done on a Core I7 with integrated GPU. Intresting would be, if the implementation also works with the ATI(AMD) VAAPI backend.


    Old PATCH :


    ffmpeg_vaapi.patch


    EDIT : VAAPI SVN


    VAAPI SVN


    happy Penguin


    Edgar (gimli) Hucek

    HW HD-VDR-1 : Foxconn H67S MiniITX, Intel G620T, 1x 80GB Intel Postvile X25 SSD, anysee E7 PS2 CI DVB-S2 intern, Gehäuse JCP MI 101, 2 GB DDR3 Ram.
    HW HD-VDR-2 : Zotac H61 MiniITX , Intel G440, 1x 320GB HDD, TeVII 470, Gehäuse Silverstone Sugo SG05, 4 GB DDR3 Ram.
    SW HD-VDR : archlinux 64bit mit archvdr Paketen ( http://archvdr.sf.net ) und VAAPI. Kernel 3.1.x, Rest bleeding edge :D
    xine-lib-1.2 VAAPI : https://github.com/huceke/xine-lib-vaapi/commits/vaapi + vdr-xine als Frontend

    Einmal editiert, zuletzt von ebsi ()

  • Wow. Klasse. Das sollte doch dann ermöglichen via ATI oder Intel Grafik und xineliboutput auszugeben?


    Wäre natürlich klasse, wenn da in Kooperation mit tbshl-vdr weiterentwickelt werden könnte.


    Ich kann das zwar nicht selber testen, möchte mich aber trotzdem bedanken. Sollte das stabil sein, bzw. in absehbarer Zeit stabil werden, dann wird so die Auswahl möglicher Grafikkarten unter Umständen vervielfacht...

  • Super, vielen Dank! Wäre echt klasse wenn VAAPI in Verbindung mit xineliboutput funktioneren würde.


    Habe gleich mal mit meinem Core i3 System ausprobiert. Bei SD-TV sprich MPEG-2 wird libva wohl nicht benutzt. Schalte ich auf eine HD-Sender (Das Erste HD) gibts ein grünes Bild und lauter Fehlermeldungen auf der Konsole. Kann ich im moment nicht kopieren, mache ich später noch. Spiele ich aber über "Wiedergabe" ein mkv mit HD Content ab (720p) läufts einwandfrei mit der libva...wobei die Prozessorlast allerdings bei 16% liegt, während mplayer-vaapi nur ca. 7% verursacht.

    Server: Intel Core i3 - MSI-H55M-E33 - CineS2 Dual-Tuner - VDR 1.7.22 auf Ubuntu 12.04
    Client1: Asrock ION330HT - 1x TT-S2-3600 USB - yaVDR 0.5
    Client2: Intel NUC mit XBMC und VNSI
    Client3: Asrock ION2 Barebone mit XBMC und VNSI

  • Check es neu aus. Ich hab einen workaround eingebaut.

    HW HD-VDR-1 : Foxconn H67S MiniITX, Intel G620T, 1x 80GB Intel Postvile X25 SSD, anysee E7 PS2 CI DVB-S2 intern, Gehäuse JCP MI 101, 2 GB DDR3 Ram.
    HW HD-VDR-2 : Zotac H61 MiniITX , Intel G440, 1x 320GB HDD, TeVII 470, Gehäuse Silverstone Sugo SG05, 4 GB DDR3 Ram.
    SW HD-VDR : archlinux 64bit mit archvdr Paketen ( http://archvdr.sf.net ) und VAAPI. Kernel 3.1.x, Rest bleeding edge :D
    xine-lib-1.2 VAAPI : https://github.com/huceke/xine-lib-vaapi/commits/vaapi + vdr-xine als Frontend

  • Danke!


    ZDF HD läuft jetzt flüssig, Prozessorlast ist allerdings bei 35% für vdr-sxfe und 15% für Xorg.

    Server: Intel Core i3 - MSI-H55M-E33 - CineS2 Dual-Tuner - VDR 1.7.22 auf Ubuntu 12.04
    Client1: Asrock ION330HT - 1x TT-S2-3600 USB - yaVDR 0.5
    Client2: Intel NUC mit XBMC und VNSI
    Client3: Asrock ION2 Barebone mit XBMC und VNSI

  • Die Prozessorlast ist unter xine höher als mit mplayer. Das liegt daran das ein indirektes rendern geamcht wird und nicht VAAPI als ausgabe benutzt wird. Das liegt an der architektur von xine und vaapi, das sich ein direktes rendering nicht so einfach bewerkstelligen lässt.

    HW HD-VDR-1 : Foxconn H67S MiniITX, Intel G620T, 1x 80GB Intel Postvile X25 SSD, anysee E7 PS2 CI DVB-S2 intern, Gehäuse JCP MI 101, 2 GB DDR3 Ram.
    HW HD-VDR-2 : Zotac H61 MiniITX , Intel G440, 1x 320GB HDD, TeVII 470, Gehäuse Silverstone Sugo SG05, 4 GB DDR3 Ram.
    SW HD-VDR : archlinux 64bit mit archvdr Paketen ( http://archvdr.sf.net ) und VAAPI. Kernel 3.1.x, Rest bleeding edge :D
    xine-lib-1.2 VAAPI : https://github.com/huceke/xine-lib-vaapi/commits/vaapi + vdr-xine als Frontend

  • Ach so, war schon am überlegen, wie das ganze jetzt gerendert wird, da man bei mplayer ja als vo vaapi angibgt während bei xine dann ja wohl xv zum einsatz kommt. Prozessorlast ist somit allerdings dann ähnlich hoch wie bei reinem CPU decoding.

    Server: Intel Core i3 - MSI-H55M-E33 - CineS2 Dual-Tuner - VDR 1.7.22 auf Ubuntu 12.04
    Client1: Asrock ION330HT - 1x TT-S2-3600 USB - yaVDR 0.5
    Client2: Intel NUC mit XBMC und VNSI
    Client3: Asrock ION2 Barebone mit XBMC und VNSI

  • Zitat

    Original von Frank612
    ZDF HD läuft jetzt flüssig, Prozessorlast ist allerdings bei 35% für vdr-sxfe und 15% für Xorg.


    Das entspricht ~ denselben Werten, die vlc+vaapi durch die gleiche Methode erzielt.


    @Frank: Bitte wirf einen Blick auf die CPU Core Voltage:

    Code
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies


    Entscheidend wäre: Die Core Voltage bleibt durchgehend auf dem niedrigsten Wert. Bei vlc+vaapi ist das gegeben, meiner Meinung nach ist damit das entscheidende Ziel bereits erreicht.; es verbleibt noch das Problem mit dem Deinterlacing.

    MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

  • Hallo,


    ich hab das ja prinzipiell am laufen, mit nvidia auch ganz gut. Was mich hier aufhält ist, dass es mit ATI nicht auch so läuft. Bei SW-Dekodierung gibts ein Problem, wo ich noch absolut nicht weiss, woran das liegt. Beim Suchen danach hab ich mal den letzten fglrx installiert (10.8 ). Da etliches am Source geändert, wollte ich vorhin nochmal HW-Dekodierung testen, und es ging so gut wie gar nix.
    Nachdem auch mplayer das selbe zeigte, hab ich wieder 10.7 installiert - und nun gehts auch wieder... :(
    Hab noch nicht gesucht - ist das nur bei mir so oder gibts da was dazu?


    Gruss,
    Thomas

  • Hallo Thomas


    Das entspricht dem was man bei phoronix zu fglrx 10.8 liest - mit 10.7 müsste es soweit laufen mit dem RS780 Chipset

    MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

  • Die Pfade zu cpufreq existieren auf meinem Debian sid System nicht. Habe jetzt mal cpufreq installiert und ein cpufreq-info gibt aus dass alle 4 CPUS auf 2.93 Ghz laufen, also Maximum.

    Server: Intel Core i3 - MSI-H55M-E33 - CineS2 Dual-Tuner - VDR 1.7.22 auf Ubuntu 12.04
    Client1: Asrock ION330HT - 1x TT-S2-3600 USB - yaVDR 0.5
    Client2: Intel NUC mit XBMC und VNSI
    Client3: Asrock ION2 Barebone mit XBMC und VNSI

  • Nein bleibt immer konstant bei 2.93 Ghz

    Server: Intel Core i3 - MSI-H55M-E33 - CineS2 Dual-Tuner - VDR 1.7.22 auf Ubuntu 12.04
    Client1: Asrock ION330HT - 1x TT-S2-3600 USB - yaVDR 0.5
    Client2: Intel NUC mit XBMC und VNSI
    Client3: Asrock ION2 Barebone mit XBMC und VNSI

  • Dann wird die Core Voltage nicht skaliert


    - muss im BIOS aktiv sein (Cool'nQuiet oder EIST auf enabled)
    - CPU Governor auf ONDEMAND

    MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

  • Habe ich alles gemacht, aber aus irgendeinem Grund, laufen alle Kerne konstant auf 2.93Ghz. Werde übers Wochenende mal das System neu aufsetzen...war eigentlich nur schnell für erste Tests mit VAAPI gedacht.


    Allgemein ist es aber trotzdem komisch, dass z.B. SDTV mit ungepatchter xinelib und xineliboutput etwa 11% Last verursacht und mit der vaapi gepatchten Version nie unter 22% kommt.

    Server: Intel Core i3 - MSI-H55M-E33 - CineS2 Dual-Tuner - VDR 1.7.22 auf Ubuntu 12.04
    Client1: Asrock ION330HT - 1x TT-S2-3600 USB - yaVDR 0.5
    Client2: Intel NUC mit XBMC und VNSI
    Client3: Asrock ION2 Barebone mit XBMC und VNSI

  • ganz persönlich hab ich hier mit Slackware64-13.1 das besondere Phänomen bei der gbeauchesne, das er libtool selber anlegt, aber nicht damit kompiliert.


    Die richtige Methode bei nicht Debiansystemen ist ja laut Website folgende.


    Alle patches aus dem debian-Verzeichnis patchen.


    danach autoreconf


    und danach configure


    nach dem configure liegt dann eine libtool im Source.


    ein nachfolgendes make sorgt für zich Fehler.


    Wenn ich aber dieses libtool lösche, und durch einen Symlink nach /usr/bin/libtool ersetzte kompiliert alles einwandfrei.



    Edit1: Die git-Variante kompiliert bei mir ebenfalls problemlos. Eigentlich sogar einfacher als die gbeauchesne, da das libtool-Chaos wegfällt

Jetzt mitmachen!

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