HD-VDR mit Intel HD Graphics - Testbericht zu vaapi

  • ebsi
    so ich mal wieder. Habe jetzt mit aktuellem xserver 1.10.1 testen können. Leider exakt das gleiche Problem. Habe ich in xine als video out driver vaapi aktiviert läuft es nicht wirklich (entweder kein bild oder nur sporadisch bei einigen Starts).


    Was mich jedoch stark wundert: Obwohl beispielsweise der vdr auf ARD HD mit h.264 hängt, initiiert die xine lib das MPEG2Profile der libva. Ich bezweifel mal, dass das so richtig ist. Hast du da irgendeine Idee?


    libva,intel treiber, lib drm, mesa lib sind frisch ausm git


    Wie bereits geschrieben, das Problem hab ich seit r190.


    Grüße
    Christoph


    Edit: Benutzt du eine spezielle Version des vdr xine plugins?

    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

    Einmal editiert, zuletzt von Flachzange ()

  • ebsi
    Dasselbe bei mir. Seit Wochen versuche ich, VAAPI stabil zum Laufen zu bekommen. Aktuell mit aktuellsten svn r225 von Dir, VAAPI 1.0.12 und xserver 1.10. SD startet sofort, bricht aber je nach Menge der surfaces ab (1-10 Sekunden). Mit



    Code
    video.output.vaapi_render_surfaces:2000


    läuft es etwas länger. Bei HD sieht es ähnlich auch, für ein paar Sekunden kommt ein Bild, dann hängt es.
    Mit mplayer-vaapi gibt es keine Probleme, der läuft rund.


    Btw, bis jetzt nutze ich immer noch xinelibout, bei xine bekomme ich immer:
    osd: can't find out current locale character set
    Wo kann ich den Font noch einstellen? Im VDR sind m.E. Standardfonts eingestellt.


    Zork

    System 1: Hardware : ASUS B150M-C, Intel Pentium G4560, DVB cineS2, 1x 2TB HDD, 1x 214GB SSD, Gehäuse Antec Remote Fusion Black, 8 GB DDR4 RAM.
    Software : Fedora 34, vdr 2.4.7, softhddevice GIT, Kernel 5.15.11
    System 2: Hardware : Intel NUC10i5FNK, Intel Core i5-10210U (Comet Lake), DVB TechnoTrend TT-connect S2-4600 USB, 1x 1TB NVMe, 32 GB DDR4 RAM.
    Software : Fedora 35, vdr 2.4.7, softhdcuvid, Kernel 5.15.11

  • Das mit dem MPEG2Profil ist richtig so. Das Startlogo das du in xine siehst ist ein mpeg Video.


    Für SD ( Mpeg ) wäre es besser Software decoding zu verwenden. Ich hatte immer wieder "GPU hangs" damit. video.processing.vaapi_mpeg_sofdec:1 in ~/.xine/config eintragen.


    Wie ist dein xine aufruf ? Eine grosse Hilfe wäre, wenn Du Revision für Revision testen könntest, somit können wird lokalisieren woran dein Problem liegt.


    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

    Einmal editiert, zuletzt von ebsi ()

  • xineliboutput geht nicht mit vaapi nicht zuverlässig. Es funktioniert nur vdr-xine. Die Anzahl der Surfaces sollte mit 30 ausreichend sein.

    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

  • Ich hab nen Zacate, nen i3 und nen SU2300 mit Gefore hier, kann also eig jedes Setting testen.


    Wichtig ist für mich nur, dass Deinterlacing auch bei SD Material stabil und gut funktioniert.


    Durch VAAPI sieht das bei dem Intel und Zacate noch schlecht aus. Mit meinem SU2300+Geforce läufts soweit am besten:




    Boot + Movies = http://www.youtube.com/watch?v=FZYUL0p0l8E
    Live TV = http://www.youtube.com/watch?v=OkRIiHBJe0M
    Music = http://www.youtube.com/watch?v=rvHg4V42ydI

  • Jetzt fängst du hier auch noch an zu spammen.....Entweder du lieferst qualitative Antworten zum Thema oder du lässt es. Deine Videos zu einer NVIDIA-Plattform haben hier nichts (und in den ganzen anderen Foren, in denen man dich sieht auch nicht) verloren, zumal es nun wirklich nichts neues ist, dass ein HTPC auf NVIDIA-Basis halbwegs rund läuft.

    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

  • ich wollte den Stand festhalten:


    VAAPI Deinterlacing meines Wissens bereits im Code aber noch nicht abrufbar? Was gehen kann ist Software Deinterlacing in Verbindung mit HD Beschl auf der iGP des i3? Oder?


    Gibt es generell groß Alternativen zu VAAPI, ich finde es ja schon gut das Intel und AMD beide über dieses VAAPI laufen damit es nachher einen einheitlichen Standard gibt für dieses HD Beschl. Thema, mit selben Deinterlacing Methoden. Wobei das ja optional ist.


    Wo Intel / AMD hinkommen müssen ist das was Nvidia bisher vormacht.


    Kann man bei dem i3 für MPEG2 Streams VAAPI disablen? Ich sehe keinen Vorteil darin da das niedrig auflösende MPEG 2 Material kaum CPU Last zieht.


    Bei AMD wird bei meinem Zacate System nur h264 beschleunigt, was den Vorteil hat, dass ich im XBMC unter SD TV Softwaredeinterlacing verwenden kann. Bei Intel ist es noch ein Geruckel bei interlaced SD Material, sofern ich VAAPI aktiviert habe. Dafür kommt es mit dem Level über 4.1 klar, bei dem grad meines Wissens bei AMD Sense ist. Ich hab eine handvoll Filme die dann Artefakte liefer ( auf AMDs VAAPI)


    In diesem Fall ist zumindest solange VA Deinterlacing nicht funktioniert weniger mehr.

  • Ich hab nen Zacate, nen i3 und nen SU2300 mit Gefore hier, kann also eig jedes Setting testen.


    Wichtig ist für mich nur, dass Deinterlacing auch bei SD Material stabil und gut funktioniert.


    Durch VAAPI sieht das bei dem Intel und Zacate noch schlecht aus. Mit meinem SU2300+Geforce läufts soweit am besten:

    Um mich auch einmal in diese dämliche Nvidia macht alles besser Diskussion einzuschalten. Wenn jemand der Meinung ist Nvidia ist so viel besser soll er dort bleiben und nicht dämlich rummotzen und Nvidia Werbung machen. Es stimmt das die Nvidia Deinterlacer besser sind. Leider konnte ich auf meinem 46" LED TV aus 3.5 Meter Betrachtungsabstand beim besten willen nicht sagen welche Deinterlacer besser arbeiten. Zumal man sich beim Filmgenuss nicht auf den Deinterlacer konzentriert und schon gar nicht im Abstand von 5cm vor dem Fernseher sitzt.
    Also liebe Nvidia Fraktion, bleibt diesem Thread fern sofern ihr nicht ernsthaft Interesse an einer Alternative habt. Mich kotz dieses meine Nvidia Grafikkarte macht alles besser Scheiße schon an.


    Zusätzliche Fakten :


    1.) Nvidia hat seit langer zeit Decoding hänger bei VAAPI. Wurden nie wirklich seitens Nvidia behoben. Das war der Auslöser warum ich mit VAAPI angefangen habe.
    2.) AMD hat mit xvba grundlegende Schwierigkeiten beim reinitialisieren der UVD Einheit. Stürzt eine Applikation ab oder der Prozess wird gekillt endet das in einen Neustart des Rechners.
    3.) Intel hat nur Deinterlacing für HD Content implementiert. VAAPI an sich hat auch seine Probleme und Design schwächen, der große Vorteil hier. Alles ist Open Source. Keine Closedsource Binary Blobs wo man nie wies ob die Hardware auch weiterhin unterstützt wird.



    Krautmaster : werd mit VDPAU glücklich, da hast Du den Besten Deinterlacer, der ja alles für dich ist.


    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

  • ebsi



    was soll dieser uncoole Tonfall?
    Ich vertrete nicht die Meinung dass die Deinterlacer besser sind.


    Im Gegenteil, mir würde sogar der Intel Deinterlacer vollkommen reichen, ich habe lieber die bessere CPU Power da die All Over Performance davon profitiert.
    Unterschied sehe auch ich keinen.


    Das Problem ist lediglich, dass ich bisher keinen Weg gefunden habe das CPU Deinterlacing zusammen mit der VAAPI HD beschl. unter XBMC zu nutzen.
    Ich seh auch kein Unterschied und persönlich finde ich das Nvidia Bild sogar an den Bildschirmrändern unruhiger als das es bei der Intel IGP der Fall wäre.


    Ich habe deswegen direkt geschrieben dass ich alle 3 Systeme hier habe zum Testen, nicht nur ein Nvidia (das ich übrigens zuletzte gekauft habe).


    Wie wärs wenn du eher auf meine Fragen bezüglich der Möglichkeit VAAPI für MPEG2 zu deaktivieren oder VAAPI + CPU Deinterlacing eingehst?

  • Wie wärs wenn du eher auf meine Fragen bezüglich der Möglichkeit VAAPI für MPEG2 zu deaktivieren oder VAAPI + CPU Deinterlacing eingehst?


    Genau das unterstützt doch die xine-lib von ebsi und um nichts anderes als den VDR (und damit xine-lib) geht es in diesem Thread. Für alles andere musst du dich an die xbmc Entwickler wenden.

    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

  • VDR an sich nutze ich genauso. Mit xine hatte ich bisher wenig zu tun aber in welcher Hinsicht hat xine vorteile gegenüber einer XBMC Integration?


    Prinzipiell muss es ja auch unabh. von xine oder XBMC umgesetzt sein, also direkt VAAPI oder?

  • Für mplayer brauchts eine spezielle vaapi-Version, der VDR braucht eine spezielle xine-lib-1.2-vaapi Version, dann wird wohl XBMC auch eine spezielle vaapi Version benötigen damit es funktioniert. Zumal hier noch erschwerend die Anbindung des VDRs über vnsi bzw. streamdev dazukommt, die von vaapi noch nix wissen. Bitte müll den Thread hier nicht mit sachfremden Fragen voll. Es geht hier einzig und allein um die Verwendung der vaapi mit dem VDR und dem xine-plugin!


    Gruß
    iNOB

  • ebsi. Ist schon klar. Aktuell versuche ich xine als frontend zu nutzen:


    Code
    xine --verbose --no-gui --no-logo -V vaapi --post vdr --post vdr_audio --post vdr_video netvdr://127.0.0.1



    Alles frisch ausgecheckt, inkl. Kernel und xorg-driver. Mich wundert das Verhalten, dass xine einfach nach ein paar Sekunden hängt. Das sind die Parameter aus der .xine/config:




    Code
    video.processing.ffmpeg_thread_count:4
    video.processing.vaapi_mpeg_sofdec:1
    video.processing.vaapi_mpeg_sofdec_deinterlace:1
    engine.decoder_priorities.ffmpegvideo:1



    mplayer-vaapi rennt ohne Probleme.


    Zork

    xineliboutput geht nicht mit vaapi nicht zuverlässig. Es funktioniert nur vdr-xine. Die Anzahl der Surfaces sollte mit 30 ausreichend sein.

    System 1: Hardware : ASUS B150M-C, Intel Pentium G4560, DVB cineS2, 1x 2TB HDD, 1x 214GB SSD, Gehäuse Antec Remote Fusion Black, 8 GB DDR4 RAM.
    Software : Fedora 34, vdr 2.4.7, softhddevice GIT, Kernel 5.15.11
    System 2: Hardware : Intel NUC10i5FNK, Intel Core i5-10210U (Comet Lake), DVB TechnoTrend TT-connect S2-4600 USB, 1x 1TB NVMe, 32 GB DDR4 RAM.
    Software : Fedora 35, vdr 2.4.7, softhdcuvid, Kernel 5.15.11

  • Lass mal die post parameter weg on stell sicher das die mpeg2 decoder priorität in der config auf 0 ist.


    lg

    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

  • Lass mal die post parameter weg on stell sicher das die mpeg2 decoder priorität in der config auf 0 ist.


    lg

    mpeg2 prio ist auf 0. Habe jetzt mal ein bisschen rumprobiert. xine(vaapi) und mplayer(vaapi) verhalten sich auch bei lokalen ts-Streams unterschiedlich in Bezug auf Fehlerhändling: mplayer nimmt alles ohne murren, xine bleibt beim ersten Fehler hängen. Hier mal ein Beispiel:




    und dasselbe mit xine




    SD/HD Material vollkommen egal, gleiches Fehlerbild.



    ebsi: Kannst Du mal das Debugging verbessern? Vielleich ist die Anzeige der benutzten Surfaces sinnvoll?


    Zork</pulseaudio>

    System 1: Hardware : ASUS B150M-C, Intel Pentium G4560, DVB cineS2, 1x 2TB HDD, 1x 214GB SSD, Gehäuse Antec Remote Fusion Black, 8 GB DDR4 RAM.
    Software : Fedora 34, vdr 2.4.7, softhddevice GIT, Kernel 5.15.11
    System 2: Hardware : Intel NUC10i5FNK, Intel Core i5-10210U (Comet Lake), DVB TechnoTrend TT-connect S2-4600 USB, 1x 1TB NVMe, 32 GB DDR4 RAM.
    Software : Fedora 35, vdr 2.4.7, softhdcuvid, Kernel 5.15.11

  • gut wäre wenn du einen gdb backtrace nachen könntest.


    Starte xine mit :


    gdb --args xine --no-logo --no-gui --verbose -V vaapi /srv/video/24/24/2010-09-25.23.13.40-0.rec/00001.ts


    wenn xine hängt einfach "strg +c" drücken. Danach im gdb "thread apply all bt" eingeben. Den backtace bitte posten.


    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


  • Yupp, anbei.




    Zork

    Dateien

    System 1: Hardware : ASUS B150M-C, Intel Pentium G4560, DVB cineS2, 1x 2TB HDD, 1x 214GB SSD, Gehäuse Antec Remote Fusion Black, 8 GB DDR4 RAM.
    Software : Fedora 34, vdr 2.4.7, softhddevice GIT, Kernel 5.15.11
    System 2: Hardware : Intel NUC10i5FNK, Intel Core i5-10210U (Comet Lake), DVB TechnoTrend TT-connect S2-4600 USB, 1x 1TB NVMe, 32 GB DDR4 RAM.
    Software : Fedora 35, vdr 2.4.7, softhdcuvid, Kernel 5.15.11

  • So ich hatte gerade mal Zeit ein paar Infos zusammenzutragen. Anbei meine config und drei logs.


    1) xinelog_190: Die Ausgaben mit r190. Die tuts bei mir ohne zu zucken, egal wie ich oft ich xine starte usw.
    2) xinelog_working: Ein Ausgabe der sehr seltenen Fälle, in denen es mit neueren Revision läuft (r225)
    3) xinelog_xinefreeze: Eine Ausgabe bei denen xine direkt nach dem Starten freezed und ich es killen muss.



    Ich starte xine so:

    Code
    /usr/bin/xine  -f --post vdr_video --post vdr_audio --post vdr --verbose=2 "vdr:/tmp/vdr-xine/stream#demux:mpeg_pes"



    Ich bin für jeden Tipp dankbar.

  • Mal so als Tip. Ich hatte genau das gleiche Problem, egal welche Version ich verwendete, das xine-0.9.4-plugin lieferte kein Bild. Letztendlich lag es daran, dass ich xine-lib-1.2 falsch konfiguriert hatte.

    Code
    ./autogen.sh --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --disable-musepack --enable-w32dll --with-w32-path=/usr/lib/win32

    Ich musste nur "--disable-dxr3 --disable-modplug" weglassen dann ging es. Außerdem hatte ich noch in "/var/lib/xine" (glaub ich) alte Dateileichen rumliegen, die gelöscht gehörten. Nach neuerlichem Bauen lief es dann.


    Gruß
    iNOB

  • Das hat leider nichts gebracht. Ist genau das gleiche Verhalten. Habe auch sicherheitshalber mal vorher alles gelöscht, was irgendwie mit xine zu tun hat.

    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

Jetzt mitmachen!

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