HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

    Schön,


    ich frag nur weil in deiner Signatur auch etwas von debian (ubuntu) steht.


    Kannst du vielleicht etwas zum Thema deinterleaciing sagen? Ich habs jetzt sowohl unter Linux mit vaapi als auch unter Windows mit dxva probiert. Ausser bei der Verwendung von xine wird nie Deinterleaced :/


    Nicht bei XBMC, nicht bei VLC , nicht bei mplayer VAAPI, etc. ...


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    Einmal editiert, zuletzt von Atechsystem ()


    vdr-sxfe --post tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1 --audio=alsa --video=xv --reconnect --aspect=default --fullscreen xvdr+tcp://192.168.10.19:37890 --tcp --config=/var/lib/vdr/.xine/config_xineliboutput --hud=xshape


    Deinterlacing wird nicht mit vaapi gemacht. Kann im moment auch nicht sagen ob das durch ffmpeg unterstüzt wird.

    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 ()

    Vielleicht hab ich mich falsch ausgedrückt. Ich meinte, dass nur bei xine mit den tvrime Deinterlacern bei mir in keiner anderen Anwedung Deinterlacing mit der vaapi möglich ist. Es gibt keine Option dafür oder es funktioniert einfach nicht. Unter Windows hab ichs auch nicht geschafft (OK, das ist Offtopicaber hat mich halt interessiert).


    PS: Alles klar, hast mich doch Verstanden ;) Danke

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    2 Mal editiert, zuletzt von Atechsystem ()

    So. Habe heute noch mal einen xserver 1.9.4 vom Scratch erstellt (Ubuntu 10.10 minimal) und mich an diese Anleitung gehalten:


    http://www.linuxfromscratch.or…iew/svn/x/installing.html



    Soweit so gut. Mit dem 2.14er Intel-Treiber bekomme ich nun immer folgende Fehlermeldung und diese ziemlich oft:


    Code
    (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: Invalid argument.


    Die Grafikausgabe sieht kaputt aus. Version 2.13 funktioniert. Google hat mir noch nicht die Erleuchtung gebracht, aber vielleicht habt ihr ja eine Idee.


    Christoph

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

    Damit das mit dem Intel Driverstack auch richtig funktioniert müssen mehr dinge erfüllt sein. Die Versionsnummer beziehen sich auf die von Archlinux. Mit denen funktioniert es bei mir.


    1.) kernel 2.6.37
    2.) libdrm 2.4.23
    3.) intel driver 2.14.0
    4.) mesa 7.10.0.git20110206-2
    5.) libva 1.0.8
    6.) xserver 1.9.4


    Ein einfaches updaten vom Intel Driver und dem Xserver ist leider nicht genug.


    lg


    ebsi


    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

    Zugegeben, meine Informationen waren etwas spärlich. Ich habe natürlich versucht den kompletten Stack zu bauen


    1)Kernel 2.6.35, 37 und 38 probiert
    2) libdrm 2.4.23 (git)
    3) intel driver 2.14.0
    4) mesa 7.10 (git)
    5) libva 1.0.10 (git)
    6) xserver 1.9.4



    Ich habe ja auch nichts geupdated....Hatte vorher keine xserver packages etc drauf, sondern alles from scratch gemacht. Wenn ich das richtig verstanden habe, ist für die Funktion des xservers ja eigentlich nur Punkt 1, 2, 3 und 6 relevant. Mesa und libva sollten den blanken xserver ja eigentlich nicht jucken. Mich irritiert halt, dass der 2.13er Treiber funktioniert. Gefühlt tippe ich ja auf irgendetwas mit dem Kernel bzw. den Kernelmodulen, aber selbst verschiedene Kernelversionen bringen da keine Besserung. Aber kann auch gut sein, dass ich irgendwo in der Kette noch was falsch gemacht habe.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

    In deiner Kernelconfig sollte für KMS das hier stehen:

    Code
    CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y

    Nähere Infos gibts dazu auch hier. Ich benutze z.B. den 2.6.35.10er. Den Rest hab ich alles aus dem git zusammengeklöppelt, inkl. Compiz.


    Im direkten Vergleich zu epsis Vorschlag ohne Compiz:

    Code
    vdr-sxfe --post tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1 --audio=alsa --video=xv --reconnect --aspect=default --fullscreen xvdr+tcp://192.168.10.19:37890 --tcp --config=/var/lib/vdr/.xine/config_xineliboutput --hud=xshape

    sehe ich bei meinem Startaufruf mit Compiz:

    Code
    LD_LIBRARY_PATH=/usr/lib /usr/bin/compiz --display :0 --replace ccp &
vdr-sxfe -f --hud --video=xv:80 --audio=alsa:default --buffers=1000 --post="autocrop:use_avards_analysis=1,overscan_compensate=30,soft_start=0,stabilize=1" "xvdr+udp://127.0.0.1:37890" --reconnect --verbose > /var/log/vdr-sxfe.log 2>&1

    außer dem transparenten Display und minimal stärkerem Ruckeln bei schnellen Laufschriften keinen Unterschied. Außerdem hakelt die Bedienung mittels FB mit Compiz nicht.


    Gruß
    iNOB

    Einmal editiert, zuletzt von iNOB ()

    Morgen zusammen,


    erstmal Danke an ebsi, genau das hätte ich dich noch gefragt. Verstehe ich das richtig, dass du mit dieser Kombination und dem geposteten xine Aufruf ein Bild frei von den hier genannten Problemen/Fehlern bekommst (die OSD Transparenz mal aussen vor gelassen)?


    Ich weiss, die vielen Fragen sind lästig wenn man noch am Testen ist. Aber wenn man absolut nicht weiterkommt klammert man sich an jede Versionsänderung im GIT oder svn ;)


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    Noch mal kurz zusammengefasst :


    meine Installation.


    Archlinux x86_64, heutiger stand. Die Pakete aus meinen archvdr repo.
    http://sourceforge.net/apps/trac/archvdr/


    Diese xorg.conf



    Diese grub.cfg :



    Dieser vdr-sxfe aufruf :


    Code
    vdr-sxfe --audio=alsa --video=xv --reconnect --aspect=default --fullscreen xvdr+tcp://192.168.10.19:37890 --tcp --config=/var/lib/vdr/.xine/config --hud=xshape --verbose


    Diese xineliboutput parameter :



    X starte ich als vdr user mit X &.


    Das sind im grossen und ganzen die Eckparameter.


    lg


    ebsi



    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

    Zitat

    Original von iNOB
    In deiner Kernelconfig sollte für KMS das hier stehen:

    Code
    CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y

    Nähere Infos gibts dazu auch hier. Ich benutze z.B. den 2.6.35.10er. Den Rest hab ich alles aus dem git zusammengeklöppelt, inkl. Compiz


    Wie schon vorher hier irgendwo geschrieben, sollte KMS in den neueren Kernel-Versionen per default aktiv sein. Bei mir werden die benötigten kernelmodule ja auch geladen und die Ausgaben im log deuten auch daraufhin, dass es funktioniert.

    Testsystem:
    Hardware: Lian Li C39, Core-i7-3632QM, Jetway NF9G-QM77, 4GB RAM, PicoPSU 160XT inkl 80W Morex, 3x 2,5" 1TB RAID5, 1xSamsung PM830 mSATA 128GB, 1x LG BDROM, 1x DD Cine CT (v6) + CI + Alphacrypt CAM
    Software: Ubuntu 13.04 mit 3.8 x64, VDR 2.0.1 + xbmc 12.2

    Danke ebsi,


    ich teste sobald ich wieder an den VDR kann :)


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    Servus ebsi,


    ich sehe gerade, dass es mit der libva-Integration in die xine-lib in deinem Repo fleissig weitergeht.


    Das ist super, danke dir.


    Wenn ich am Freitag mal wieder Zeit habe, bin leider immer noch auf Reha, dann schaue ich mir deine neuen Sachen mal an.


    Sag mal wäre es nicht Zeit mal das Repo auf eine neuere xine-lib-Version zu stellen, deine Basis ist halt schon 5 Monate alt?


    => bei mir kompiliert nämlich das vdr-xine-plugin nicht mehr, wenn man deinRepo als Basis nimmt. Er meckert eine alte /usr/include/xine/vdr.h an.


    Das hätte halt den absoluten Vorteil, die aktuellen vdpau-Geschichten in der xine-lib-1.2 drinnen zu haben, und eben auch die aktuellen Sourcen könnten gegen diese xine-lib bauen.


    Gruß
    Wolfgang

    Moin wbreu,


    dann sag ich mal gute Besserung :)


    Du kannst auch den VA-API Patch aus seinem Archvdr repro gegen die aktuelle xine-lib-1.2 compilieren:


    http://sourceforge.net/apps/tr…vdr/xine-lib-1.2?rev=1873


    Vielleicht ne Lösung?


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    Zum Patch ziehen ist es halt einfach. Ein einfaches :


    svn diff -r20:73 und du hast den (momentan) Aktuellsten Patch denn du gegen das xine HG anwenden kannst.


    lg


    ebsi


    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




    Nabend ebsi,


    das wäre mir schon klar, aber das svn kann man seit einiger Zeit nicht holen:



    Code
    notebook:~# svn co http://crystalhd.svn.sourceforge.net/viewvc/crystalhd/branches/xine-lib-1.2-vaapi/
svn: Repository moved temporarily to '/viewvc/crystalhd/branches/xine-lib-1.2-vaapi/'; please relocate


    und dann ist Ende.


    Keine Ahnung was da fehlt?


    Somit geht auch kein diff, und damit ist es auch nicht so einfach Neuerungen in die df-xine-lib-1.2 zu transportieren. Wäre toll, wenn du da mal schauen könntest, warum der "svn co" da ins Leere läuft.


    Aber ich habe die version 73 hier liegen, damit kommt mit dem vdr-xine-plugin kein Bild bei allen HD-Sendern (720P und 1080I), mit vdr-sxfe klappt es.


    Edit:


    Ok, habs gefunden:


    svn co http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/


    damit gehts.


    Gruß
    Wolfgang

    Ähm... da ich vor dem selben Problem stehe ins svn zu kommen, wäre ich über einen Hinweis hocherfreut, damit ich mich in den Kreis der Erleuchteten einreihen kann. Die oben geposteten Links sind allesamt gleich und führen zur oben genannten Fehlermeldung :schiel


    Gruß
    iNOB

    Einmal editiert, zuletzt von iNOB ()

    svn co https://crystalhd.svn.sourcefo…anches/xine-lib-1.2-vaapi


    das ist der richtige svn link.


    lg


    Ebsi

    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

    Zitat

    Original von wbreu
    Aber ich habe die version 73 hier liegen, damit kommt mit dem vdr-xine-plugin kein Bild bei allen HD-Sendern (720P und 1080I), mit vdr-sxfe klappt es.


    Nun sollte es auch wieder mit Xine klappen. Hab gestern so einiges im Source verbockt. Für Xine-ui eine HG Version <= 2978 verwenden. Neuere Versionen haben ein Thread locking problem.


    lg


    Ebsi

    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

    2 Mal editiert, zuletzt von ebsi ()

    Danke


    Gruß
    iNOB

    Mahlzeit,


    vorneweg, danke für die neue Version.


    Bei mir rennt jetzt die Version 77 mit aktueller xine-lib-1.2 mit den vdpauextension+aktuellen Patches dafür.
    Ne aktuelle Version kann ich aber erst heute Abend auf die Homepage stellen.


    Das vdr-xine-plugin gibt jetzt wieder ein Bild auf allen HD-Kanälen aus.


    Wobei ich jetzt mal mein Grundsetup geändert habe, => compiz ist komplett aus, und auch Composite ist auf "disabled" in der xorg.conf. Hintergrund ist, so kann man die ganzen Seiteneffekte die da mitkommen ausschliessen. Als Windower nutze ich fluxbox.


    Ergebnis:


    - Bei SD und HD - 720p kein Nachziehen mehr bei schnellen Kameraschwenks ist Ruhe, 1080i-Sender ruckelt grundsätzlich.

    Zwischendurch gibts leider immer Framedrops, das Log sagt das dazu:




    Die Fehlermeldungn im Log gibts auch mit vdr-sxfe, da Ruckelts dann ebenfalls kurz, ist aber klar, da ja Frames verworfen werden.



    Auschecken aus dem git klappt so, damit das mal sauber sichtbar ist:


    Code
    svn co https://crystalhd.svn.sourceforge.net/svnroot/crystalhd/branches/xine-lib-1.2-vaapi



    Diffen für Einzelpatch der vaapi-Geschichte, hier Version 77:


    Code
    svn diff -r20:77 > ffmpeg_vaapi_v77.diff



    Gruß
    Wolfgang

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden