softhdcuvid jetzt mit VAAPI und HDR support

  • weder mit der einen noch mit der anderen Erweiterung bekomme ich ein Bild auf den hdmi1 nach reboot, selbst wenn der TV an ist. - der vdr startet allerdings.

    Ich weiß gerade nicht, ob er das initramfs bei einem update-grub automatisch mitbaut - ansonsten vorher mal ein sudo update-initramfs -u machen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo zusammen,


    ich versuche schon seit Monaten vergeblich, meiner Intel-GPU eine feste Auflösung beim Booten zuzuweisen, denn ohne eingeschalteten Monitor beim Booten gibt es kein Bild vom X-Server (nach diesem Thread: Zusammenfassung Intel VAAPI & edid.bin).

    Dazu hatte ich auch die edid ausgelesen, sie mir aber jetzt erst mit edid-decode angeschaut. Und wundere mich gerade, dass max. Full-HD darin angegeben wird, obwohl ich (auch aktuell) mit 2560*1440 unterwegs bin - und diese Auflösung auch beim Booten generell eingestellt haben möchte, wie es bei eingeschaltetem Monitor automatisch geschieht ...


    Dies als Gegenbeweis, dass der Monitor mehr kann (aktuelle Auflösung):


    Hat hier jemand eine gute Idee, warum das so ist und wie ich das beheben könnte?

    Denn, wenn diese Werte wirklich nur in der EDID stehen, kann "natürlich" nicht beim Booten die 2560*1440er-Auflösung gesetzt werden.

    Entschuldigt bitte das Reingrätschen, die Diskussion passt aber gerade sehr gut auf das Problem ...


    Danke vielmals und viele Grüße,

    Chriss

    Einmal editiert, zuletzt von theonlychriss () aus folgendem Grund: xrandr output hinzugefügt

  • Und wundere mich gerade, dass max. Full-HD darin angegeben wird,

    Der Mode mit 2560x1440 ist schon dabei:

    Code
    Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm																								               2560 2608 2640 2720 hborder 0																								               1440 1443 1448 1481 vborder 0																								               +hsync -vsync 																								               VertFreq: 59 Hz, HorFreq: 88786 Hz

    Wie genau sehen deine Boot-Optionen aus?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hey Seahawk,


    ups - Wald und Bäume!? 8o Danke fürs Aufzeigen!

    Meine Boot-Parameter sind diese:

    Code
    linux   /boot/vmlinuz-5.3.0-26-generic root=UUID=22222222-2222-2222-2222-222222222222 ro  quiet splash video=DP-1:2560x1440@59.95D drm.edid_firmware=DP-1:edid/edid.bin $vt_handoff
    initrd  /boot/initrd.img-5.3.0-26-generic

    Ich habe auch das mit dem Einbinden der edid mit dem im o.g. Thread angegebenen Hook, samt update-grub schon mehrfach gemacht.



    Meine edid liegt an dieser Stelle:

    Code
    "Original":
    /lib/firmware/edid/edid.bin
    
    wird dann hierher kopiert:
    /usr/lib/firmware/edid/edid.bin


    Viele Grüße,

    Chriss

  • Ich weiß gerade nicht, ob er das initramfs bei einem update-grub automatisch mitbaut - ansonsten vorher mal ein sudo update-initramfs -u machen.

    tut er nicht aber es ändert auch nichts wenn ich die initrd vorher aktualisiere. :(


    ich teste das nochmal in Ruhe, denke ich muss das auch noch in die X11 Device Section wie bei fnu einsetzten. - vermutlich sitzt das Problem hier vor dem PC...

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    2 Mal editiert, zuletzt von CKone ()

  • Aber was mir auch aufgefallen ist, dein EDID ist Version 1.3 und das liest der Treiber nicht vollständig aus. Da wäre es besser du änderst es auf 1.4 und versorgst es per initram.

    da sagst du was, wie sollte ich die Version beeinflussen?

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Einmal editiert, zuletzt von CKone ()

  • Guten Tag,

    jojo61 danke für die Arbeit auf dem softhd plugin...

    Ich habe mich gestern den frischen vdr-plugin-softhdvaapi übersetzt. Gut dokumentiert, ohne probleme kompiliert. Nur bei dem ersten Start erhalte ich folgenden Fehler:

    Code
    vdr: /lib/libavfilter.so.7: symbol av_sscanf version LIBAVUTIL_56 not defined in file libavutil.so.56 with link time reference

    Ein bloßer ldconfig hat keinen Effekt.

    Libplacebo habe ich nicht einkompiliert. Die erforderlichen Libraries habe ich aus dem Debian 10 Repo installiert:

    aptitude install libglew-dev freeglut3-dev libglm-dev

    FFMPEG ist 4.2.1 von GIT-Quellen, lange vor den oben bemerkten Libs durch make install in das System eingebracht.

    VDR 2.4.1 und die frische VAAPI wurden auch von Quellen kompiliert (VAAPI aus dem GIT).


    Wann ich den vdr-plugin-vaapidevice anstatt vdr-plugin-softhdvaapi lade, startet VDR ohne jegliches Problem.

    Der ganze Script lautet

    Bash
    #!/bin/sh
    VDR_BIN='/usr/bin/vdr'
    VDR_PLUGINS_DIR='-L /usr/lib/vdr'
    export ALSA_DEVICE=default
    
    $VDR_BIN $VDR_PLUGINS_DIR --plugin="softhdvaapi -a pulse" --plugin=femon --plugin=wirbelscan

    Eher als ein Coder bin ich ein System-Klempner.

    Ich versuchte mit Google und auf dem vdr-portal.de zu suchen, aber es gibt keine passenden Ergebnisse.

    Leider habe ich die 20 Seiten dieses Threads nicht hindurch gelesen (TL;DR).

    Ich wäre dankbar für irgend einen Rat :)

  • video=DP-1:2560x1440@59.95D

    Da es nur eine Refreshrate für die Auflösung gibt würde ich mal video=DP-1:2560x1440e bzw. video=DP-1:e probieren (was nach meinem Verständnis genügen sollte, wenn 2560x1440 die bevorzugte Auflösung des Monitors ist) - nich dass es daran scheitert, dass er keinen passenden Mode für die "krumme" Refreshrate findet.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Nachdem bei mir immer noch kein OSD mit vaapi angezeigt wird habe ich mal drm ausprobiert und da bekomme ich das OSD angezeigt, aber nach kurzer Zeit ruckelt das Bild, es gibt Artefakte bis zur Unkenntlichkeit des Bildes und buffer overflows im Log. Die GPU ist zwar lt. gpu-top zu 25% mit rendern beschäftigt, aber offenbar wird ja ein Großteil der Arbeit von der CPU verrichtet. Wo wird das das konfiguriert, wo kann man da was nachsehen?

    Kann für das OSD mit vaapi irgendwo Testcode in das Plugin einbauen? Wenn ja wo?

  • Da stimmt etwas mit deiner ffmpeg installation nicht. libavfilter und libavutil vertragen sich nicht. Sind wohl aus unterschiedlichen ffmpeg versionen.

    Sie haben natürlich recht - Danke :)

    Noch zu dem Problem mit den Libs, strace hat folgendes gezeigt:

    Code
    openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavutil.so.56", O_RDONLY|O_CLOEXEC) = 4
    openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libavcodec.so.58", O_RDONLY|O_CLOEXEC) = 4
    openat(AT_FDCWD, "/lib/libavfilter.so.7", O_RDONLY|O_CLOEXEC) = 4
    openat(AT_FDCWD, "/lib/libavformat.so.58", O_RDONLY|O_CLOEXEC) = 4

    Hm. Es ist sicher meine eigene Schuld, daß ich Sachen direkt mit "make install" installiere, anstatt zuerst einen .DEB daraus zu machen.

    Die Version aus dem Debian Repo hat wahrscheinlich als eine Dependency mit manchem anderen Programm gekommen.

    Also als ein Workaround habe ich /lib auf die erste Zeile in /etc/ld.so.conf eingefügt, und ldconfig durchgeführt. Danach arbeitet das softhdvaapi schon normal - fast ausgezeichnet, eher :)

    Komisch ist, das danach vaapidevice nicht mehr arbeitet. VDR mit vaapidevice startet, aber ohne das Bild, nur mit Audio. Auch top sagt mir, daß die CPU-Kerne nicht so belastet sind, als wann es das Bild gibt. Wann ich die Zeile mit /lib aus ld.so.conf entnehme, startet vaapidevice wieder normal. Ich habe versucht, VDR und FFMPEG mit /lib in dem ld.so.conf wieder zu übersetzen und re-installieren, aber das hat gar keinen Effekt... vielleicht später kann ich das weiter forschen, jetzt gibt es keine Zeit mehr und ich habe schon einen arbeitenden Ausgangs-Plugin. Halelujah :)

  • Nachdem bei mir immer noch kein OSD mit vaapi angezeigt wird habe ich mal drm ausprobiert und da bekomme ich das OSD angezeigt, aber nach kurzer Zeit ruckelt das Bild, es gibt Artefakte bis zur Unkenntlichkeit des Bildes und buffer overflows im Log. Die GPU ist zwar lt. gpu-top zu 25% mit rendern beschäftigt, aber offenbar wird ja ein Großteil der Arbeit von der CPU verrichtet. Wo wird das das konfiguriert, wo kann man da was nachsehen?

    Kann für das OSD mit vaapi irgendwo Testcode in das Plugin einbauen? Wenn ja wo?

    Das DRM plugin nutzt ja auch vaapi als dekoder. Ich bin immer noch der Ansicht das die glew installation nicht sauber ist. DRM nutzt im OSD kein glew und VAAPI nutzt glew im OSD. Wenn man glew neu übersetzt und dann mit ldconfig lädt, dann übermangelt Suse es wieder mit der alten Version. Deswegen sollte man es nach usr/local/lib installieren und im ld.so.conf den Pfad /usr/local/lib nach vore legen. Dann nimmt er die neue glew zuerst.


    frr Schön wenn es nun läuft. Hast du das vaapidevice mal mit den neuen ld.so.conf einstellungen compiliert ??



    Wie geht es weiter:

    Ich bin immer noch am DETA/ATTA Problem der DRM Version am basteln. Ist komplizierter als angenommen aber wird sicher noch fertig.

    Dann kümmere ich mich um die UHD HDR Probleme mit dem Speicherverlust und OOM als folge. Da die meisten eh noch keinen lauffähigen HDR Kernel haben ist mit das DETA/ATTA Problem wichtiger.

    Wegen dem Aspektratio von CKone habe ich ein noch paar debugs eingebaut.


    mfg

    jojo61

  • frr Schön wenn es nun läuft. Hast du das vaapidevice mal mit den neuen ld.so.conf einstellungen compiliert ??

    jojo61 Danke daß Sie sich kümmern :)

    Das Mysterium rund um die Libs im vaapidevice ist mir kein großes Problem.

    Aber ja, das war sicher eine der ersten Sachen die ich versucht habe:

    Code
    cd /usr/src/vdr-2.4.1
    make clean
    make clean-plugins
    # ./configure --prefix=/usr  # gibt es eine? Bin ich nicht mehr sicher
    make -j 4
    make install

    Ich habe durch dem Log zurück gelesen, daß die Plugins wirklich neu kompiliert und linkt wurden und neu installiert.

    Anscheinend alle Dateien wurden erneuert, aber es hat nicht geholfen.

    Dasselbe habe ich später mit dem FFMPEG getan.

    Auch kein Unterschied.

    Vielleicht sollte ich noch kucken, welche headers die Kompilier-Stufe ladet? Die werden von dem ldconfig nicht umgeschaltet...

    Aber es ist mir jetzt etwas egal :)

    Ich könnte darauf noch mal wieder mit strace kucken - um manchen Unterschied in der Liste der geladenen Libs zu finden.

    Wichtig ist, das softhdvaapi für mich arbeitet, und daß ich auch vaapidevice anwenden kann, sollte ich mich dazu noch zurückkehren wollen.

  • Das DRM plugin nutzt ja auch vaapi als dekoder. Ich bin immer noch der Ansicht das die glew installation nicht sauber ist. DRM nutzt im OSD kein glew und VAAPI nutzt glew im OSD. Wenn man glew neu übersetzt und dann mit ldconfig lädt, dann übermangelt Suse es wieder mit der alten Version. Deswegen sollte man es nach usr/local/lib installieren und im ld.so.conf den Pfad /usr/local/lib nach vore legen. Dann nimmt er die neue glew zuerst.

    Da hast Du insofern Recht als dass in meinem selbstgebauten RPM noch ein Fehler drin war (beim install baute er es nochmal ohne EGL). Jetzt passt es aber:

    Code
    # ldconfig
    # ldd /usr/lib64/vdr/libvdr-softhdvaapi.so.2.4.1|grep -i glew
            libGLEW.so.2.1 => /usr/lib64/libGLEW.so.2.1 (0x00007fb7f3b3e000)
    # ldd /usr/lib64/libGLEW.so.2.1|grep -i egl
            libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fea10548000)

    Erfolg hat das aber nicht gebracht:

    Code
    vdr: [1808] oglThread thread started (pid=1724, tid=1808, prio=high)
    vdr: [1808] [softhddev]OpenGL using display :0
    vdr: [1808] [softhddev]glewInit failed with 'Missing GL version', aborting
    vdr: [1808] [softhddev]Could not initiate OpenGL Context
    vdr: [1808] [softhddev]OglThread cleanup
    vdr: [1808] oglThread thread ended (pid=1724, tid=1808)

    Ich habe schon versucht die GL Version zu setzen im Source Code oder mit MESA Umgebungsvariable, ohne Erfolg. Auch mit und ohne .drirc


    Update: Ein Testprogramm liefert jetzt ebenfalls bei glewInit() keine GL Version - ich versuche das mal zu debuggen

    Update2: in libglew schlägt eglInitialize() fehl, sowohl auf dem Nvidia-PC als auch auf dem Intel-PC. EGL Libs scheinen aber alle installiert zu sein

  • seahawk1986 So ich habe gerade einen Fix für das DETA/ATTA Problem mit drm eingecheckt. Wäre prima wenn du das mal testen könntest.

    Leider muss der vdr nun als root laufen weil die Funktion drmDropMaster das braucht.


    FireFly Ich denke du musst das glewinit mal debugen. Das Missing GL version kommt ja daher und da musst du mal in den Quellen schauen wo das erzeugt wird. Soweit ich das gesehen habe gibt es da eine Funktion die die aktuelle GL Version versucht zu ermitteln und das geht bei dir irgendwie schief. Da musst du mal ein paar debug prints reinbauen um zu sehen wo es hackt.


    mfg

    jojo61

  • FireFly Ich denke du musst das glewinit mal debugen. Das Missing GL version kommt ja daher und da musst du mal in den Quellen schauen wo das erzeugt wird. Soweit ich das gesehen habe gibt es da eine Funktion die die aktuelle GL Version versucht zu ermitteln und das geht bei dir irgendwie schief. Da musst du mal ein paar debug prints reinbauen um zu sehen wo es hackt.

    Ja, genau das habe ich ja gemacht. Allerdings kann er die GL Version in glewInit() ermitteln, aber anschließend ruft glewInit() die Funktion eglewInit() auf wo es dann fehlschlägt (das GLEW_ERROR_NO_GL_VERSION ist so ne Art Universalfehlmeldung wenn beim Init irgendetwas schief geht):

    Code
    /* Load necessary entry points */
      initialize = (PFNEGLINITIALIZEPROC)   glewGetProcAddress("eglInitialize");
      queryString = (PFNEGLQUERYSTRINGPROC) glewGetProcAddress("eglQueryString");
      if (!initialize || !queryString)
        return 1;                                       // <== das return wird nicht aufgerufen
    
      /* query EGK version */
      if (initialize(display, &major, &minor) != EGL_TRUE)  //<== das initialize (=eglInitialize) liefert EGL_FALSE zurück
        return 1;      // <== '1' == GLEW_ERROR_NO_GL_VERSION

    Das eglInitialize steht dann in libEGL, das wiederum Funktionen in libglnvd aufruft, was an die HW-spezifischen Treiber weiterleitet oder so. Das habe ich nicht weiter gedebuggt.

    Hast Du wirklich nur das ligGLEW selbst kompiliert? Mir kommt es so vor, als würde da bei mir noch was fehlen. Immerhin meldet das Beispielprogramm auch den Fehler, ist also reproduzierbar. Wenn man das return aber auskommentiert läuft es ohne sichtbare Probleme weiter :->

    Der OpenGL Benchmark glmark2-es2 bricht ebenfalls ab, glmark2 (ohne ES) funtkioniert. Geht das bei Dir?


    Was gibt bei Euch denn ein glxinfo | grep OpenGL aus? Ist das normal dass dort oben 4.5 als Core Profile steht, aber unten dann nur 3.0 als version string? Bei VAAPI scheint das "normal" zu sein, bei NVidia steht da die gleiche OpenGL version wie bei core Profile: OpenGL version string: 4.6.0 NVIDIA 390.132

    Code
    OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2
    ....
    OpenGL version string: 3.0 Mesa 18.3.2
  • Hi,

    I see another issue with the drm version here, not sure if it is fixable.

    I do use also the old mpv plugin, which I got working for softhdvaapi but did crash with drm.

    [470530.163338] oglThread[11576]: segfault at 7f8df626e980 ip 00007f8df626e980 sp 00007f8d92ffce08 error 14 in libglapi.so.0.0.0[7f8df6c0d000+b000]

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • vdr als root ist irgendwie uncool.


    Du hast sicherlich auch das hier gefunden:

    https://stackoverflow.com/ques…-requires-root-privileges


    Unten ist was zu lesen von fd schließen und wieder öffnen. Ob das hier hilft, root-Privilegien zu vermeiden?

Jetzt mitmachen!

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