Posts by jojo61

    Ich habe jetzt mal auf die Pakete aus focal und focal-security gepinnt (damit die neueren mesa-Pakete aus focal-updates entfernt werden) und die libplacebo lokal neu gebaut - damit crasht er sichtbar im Thread für das OpenGL-OSD:

    Wen nich mir das so anschaue dann sehe ich da keinen Fehler im OSD. Kannst du mal das Log anhängen ob evtl. das compilieren der Shader fehlschlägt ? Evtl. auch mal den ganzen Backtrace. ich kann nicht shen wo das DrawArrays herkommt.

    ich verwende softhdvaapi und den Update-Stand von seahawk1986 von gestern (18.08.2021)... Aber mein Treiber ist wie geschrieben der i915 - warum weiß ich nicht recht...

    Auf deinem NUC8 sollte der iHD Treiber funktionieren. Da nutze ich den auch. Und das geht bei mir ohne Probleme.

    Wenn ich mir den Absturz so ansehe dann wundere ich mich was das plugin damit zu hat. Das bitmap das da crasht könnte der OSD Fensterrahmen sein.


    Hast du mal mit dem iHD Treiber versucht ? Mesa 21.3 ist ja recht neu evtl. gibt es da noch Probleme mit dem intel i965 Treiber.

    Hier der Pacth so wie ich ihn eingebaut habe. Es betrifft die Datei src/gpu.c

    Dieser Patch behebt diesen Fehler:

    Code
    1. Aug 12 20:34:03 ubuntu-nuc3 vdr[1126]: error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2146)
    2. Aug 12 20:34:03 ubuntu-nuc3 vdr[1126]: error: DRM modifier INTEL 0x2 not available for format rg8. Available modifiers:
    3. Aug 12 20:34:03 ubuntu-nuc3 vdr[1126]: error: INVALID

    Die Haswell warnings sind wohl nicht schlimm weil ich diese Formate nicht nutze. Aber ich frage mich wo er das BadDrawable wirft. Das ist immer schwer zu finden weil es da keine Linenummer und keinen Dump gibt. Evtl. kannst du mal mit DEBUG bauen und den kompletten Log posten.


    Ich nutze den iHD Treiber.

    Code
    1. export MESA_LOADER_DRIVER_OVERRIDE=iris
    2. export LIBVA_DRIVER_NAME=iHD
    3. export LIBVA_DRIVERS_PATH=/usr/local/lib64/dri


    Was sagt denn glxinfo | grep OpenGL

    Ich habe mir das nun mal auf meinem NUC angesehen. Dazu habe ich erstmal die libplacebo auf Version 157 aktualisiert ohne sonstige updates.

    Das ganz läuft dort mit dem libplacebo patch wie oben beschrieben.


    Dann habe ich das System updated und da wurde dann auch die libGLEW aktualisiert auf Version 2.2. Damit lief es nur noch ohne OSD.

    Dieses Problem habe ich nun behoben und im GIT aktualisiert.


    Das Problem mit der mesa_vulkan kann ich leider nicht reproduzieren. Da ich OpenSuse nutze scheint das dann wohl nur bei debian zu existieren.

    Ich hoffe das seahawk1986 das dort findet.

    Bei softhdvaapi habe ich ohne dann zwar Bild aber mit dem Ton passt dann irgendwas nicht, habe dann Tonaussetzer und im Log steht dann immer sowas mit "Audio Delay 100ms"

    Das sieht dann danach aus als ob er mit dem Bild nicht nachkommt. Dann hält er den Ton an. Das sind die Aussetzer die du hörst. Nur warum das Bild so langsam ist wundert mich. Ich werde mir das nächste Woche mal auf meinem NUC ansehen. Vielleicht ist ja auch etwas mit dem X Server. Zumindest im Log von Seahawk sieht es danach aus,

    Heute kann ich das Problem mit softhdvaapi und der gepatchten Libplacebo interessanterweise auf meinem System nachstellen, der VDR crasht da munter vor sich hin - im Log fällt dabei sowas auf:

    Da ist wohl noch mehr kaputt als nur der nötige patch von libplacebo. Mit der API Version 157 habe ich auch noch nicht getestet. Kannst du mal ohne libplacebo testen ob es da geht. Damit zumindest mal sicher ist das es libplacebo ist ? Und dann probier doch mal eine ältere Version von vor dem 3 Mai 2021.

    Aug 4 18:16:36 vdr vdr[998]: error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2084)
    Aug 4 18:16:36 vdr vdr[998]: Fehler beim export VAAPI Handle

    Ich vermute das Problem liegt an der libplacebo. Ich hatte das hier schonmal beschrieben. Leider muss man eine ältere libplacebo nutzen oder die libplacebo patchen. Da sich an dem Problem bisher nichts getan hat werde ich wohl einen patch für die libplacebo mitliefern müssen.


    Man muss in der Datei src/gpu.c in der Funktion check_mod (etwa Zeile 578) einfach einen harten return true; einbauen.


    Wenn es das nicht ist schaue ich mir das mal auf dem NUC nächste Woche an. Bin grad im Urlaub :-)

    Mit der LUT (Lookuptable) werden im Ausgang die Farben korrigiert die dann letztlich an den Fernseher ausgegeben werden. Normalerweise wird die LUT vom Treiber gesetzt und ist linear. D.h. Eingang gleich Augang. Bei NVIDIA scheint mir das aber nicht der Fall und dort werden per default die Farben aufgebessert. Damit sieht das Bild dann schöner aus. Das ganze kann man aber auch im Plugin machen und dort hat man dann die möglichleit eine LUT nach eigenen Wünschen zu verwenden. Google mal nach Korben 214 LUT und du wirst einiges dazu finden.

    Beim plugin softhdvaapi mit placebo kann man eigene LUTs verwenden. Ist im README beschrieben.

    Ich habe diverse Einstellungen von Kontrast, Sättigung etc. durchprobiert aber es blieb immer unter dem gewohnten Niveau von der Nvidia-Karte.

    Ich habe beides. NVIDIA und NUC und kann die Erfahrungen mit Intel nicht nachvollziehen. Ja das Bild bei Intel ist bei den Farben etwas flauer, aber das liegt an der verwendeten LUT. Mit dem Plugin softhdvaapi und einer besseren LUT ist das Problem sofort weg.

    Inhaltlich sind die Bilder bei beiden gleich. was ich bei digitalem Bild auch erwarten würde :-)

    Ich verwende die LUT Korben 214 falls es jemand wissen will.


    mfg

    joj61

    Hallo


    ich bin mal wieder dazu gekommen mit meinem NUC das softhdvaapi zu testen. Dabei ist mir aufgefallen das libplacebo wieder kaputt ist und auf Intel nicht funktioniert.

    Wer also libplacebo mit Intel Grafik nutzen will braucht libplacebo von vor dem 3 Mai 2021. Ich habe nun einen Issue eingestellt und hoffe Haasn wird es beheben.


    Wer es selber compilieren will, ich habe einen Patch für libplacebo das den Fehler behebt. (Ist im Issue zu finden).


    Ausserdem musste ich das plugin noch anpassen. Wird in Kürze ins GIT geladen.


    mfg

    jojo61

    Im Ausgabedevice ist die Sache nicht so einfach. Letzlich hole ich beim decoder einfach nur decodierte Frames ab. Wenn die aber defekt sind (so wie das hier aussieht) dann bekomme ich das nicht mit. Es gibt da keinen Status ob das Frame ok ist oder nicht. Also zumindest kenne ich keine Stelle wo ich sehen kann ob es einen Decoderfehler gegeben hat oder nicht.