softhdcuvid/softhdvaapi/softhddrm with hevc and UHD

Ich habe den Patch mal ins skindesigner-git übernommen.

Grüsse

kamel5

Hallo,

im aktuellen git kommt es beim deta zu diesem Fehler und Absturz VDR,

checkCudaErrors() Driver API error = 0219 "CUDA_ERROR_INVALID_GRAPHICS_CONTEXT" from file <video.c>, line 1602.

Git aktuell, nvidia 430 / cuvid 10.1/ opengl / ohne libplacebo / skindesigner mit opengl patch

Gruß

moz

Zitat von kamel5

Ich habe den Patch mal ins skindesigner-git übernommen.

Vielen Dank.

Zitat von mamomoz

im aktuellen git kommt es beim deta zu diesem Fehler und Absturz VDR,

Das Problem habe ich auch beim ausschalten.

Gruß

Murry

Zitat von jojo61

Code

video: fatal i/o error

Wenn du das im Log hast dann gab es einen fatalen Fehler mit dem Window und das Plugin stellt seine arbeit ein.

Könnte schon sein das cecremote da mit hineinspielt. Versuche es halt erst mal ohne zusätzliche Plugins. Dann kannst du es besser einkreisen.

mfg

jojo61

Endlich bin ich einen Schritt nach vorne weiter gekommen! Cecremote Plugin war maßgeblich für Abstürze verantwortlich, nach dem update scheint jetzt erstmals softhdcuvid bei mir stabil zu laufen. Ich werde mit dem maintainer des arch-AUR pakets in kontakt treten.

Momentan habe ich softhdcuvid (CUDA, 1030) ohne libplacebo. Beim Versuch, libplacebo reinzukomplilieren, bekomme ich beim start Fehlermeldung "No support for dma_buf import in Vulkan" und anschließend verabschiedet vdr sich mit einem segfault. Ist das "normal"? In welche Richtung muss ich suchen?

Momentan (nach allen unerklärlichen Effekten davor) habe ich bei mir nvidia Driver 430.40 aktiv und nicht mehr die aktuellere 435.21. Kann das damit etwas zu tun haben?

Andere Frage: mich hat natürlich gleich auch das Thema 4K gereizt, schließlich war das der Auslöser überhaupt mich mit dem neuen Ausgabeplugin zu beschäftigen. Also, fashion One 4K, erstmals in 1920x1080. GPU Utilization 33%, bild "normal", aber manchmal habe ich das Gefühl, das es "mikrorückler" auftreten, bin mir aber nicht sicher.

Dann auf 3840x2160 hochgeschaltet. Dort ist der Effekt viel stärker, so als ob immer wieder teile des Frames nicht ausgegeben worden sind oder tearing auftritt oder einfach teil eines Frames verschoben ist … GPU load maximal bei 44% Irgendwelche Ideen?

Und noch mal vielen Dank für die Tolle Unterstützung!

Wegen dem segfault schaue ich später nach und reich die info nach, danke. Deine nächste Änderungen versuche ich im laufe der Woche zu testen.

Meine Karte läuft nicht mit x16, zumindest laut lspci (ausgabe komplett in der Anlage):

-----

LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <1us, L1 <4us

ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+

LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+

ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-

LnkSta: Speed 8GT/s (ok), Width x4 (ok)

TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

---------

Wenn ich richtig verstehe, die Karte läuft mit PCIe 3.0 x4

nvidia-settings zeigt das gleiche Bild, anscheinend ist die karte 4x...

Wenn ich richtig gegoogelt habe, sind alle 1030 4x

Zitat von jojo61

"No support for dma_buf import in Vulkan" ist bei Cuda normal und kein Fehler. Der segfault danach muss also woanders her kommen. Da musst du mal im coredump einen BackTrace machen.

Habe beim Absturz folgendes backtrace:

-----------

Thread 1 "vdr" received signal SIGSEGV, Segmentation fault.

0x0000000000000000 in ?? ()

(gdb) bt

#0 0x0000000000000000 in ?? ()

#1 0x00007fffcb601150 in ?? () from /usr/lib/libnvidia-eglcore.so.430.40

#2 0x00007fffcb5f57ea in ?? () from /usr/lib/libnvidia-eglcore.so.430.40

#3 0x00007fffcb5f58a9 in ?? () from /usr/lib/libnvidia-eglcore.so.430.40

#4 0x00007ffff4853b07 in pl_vulkan_create_swapchain () from /usr/lib/libplacebo.so.18

#5 0x00007ffff66bf547 in InitPlacebo () at video.c:5280

#6 0x00007ffff66c2642 in VideoInit (display_name=<optimized out>) at video.c:6796

#7 0x00007ffff66ba194 in StartVideo () at softhddev.c:3253

#8 Start () at softhddev.c:3253

#9 0x00007ffff66b0373 in cPluginSoftHdDevice::Start (this=<optimized out>) at softhdcuvid.cpp:3095

#10 0x0000555555671d2c in cPluginManager::StartPlugins() ()

#11 0x00005555555f1211 in main ()

(gdb)

-----------

Irgend eine Idee? Danke im Voraus!

Zitat von jojo61

Da stimmt etwas mit der Vulkan installation nicht. Ich habe im lspci.txt etwas vom nouveau Treiber gelesen. Hast du das richtig blacklisted ?

nouveau ist zumindest nicht geladen: "lsmod | grep nouv" bleibt leer. /usr/lib/modprobe.d enthält nvidia-dkms.conf mit folgendem Inhalt:

---

blacklist nouveau

---

Woraus besteht die vulkan-Installation bzw. wie lässt es sich prüfen? Gibt es irgend ein "üblicher" test?

Zitat von jojo61

Poste mal was vulkaninfo so sagt.

Habe angehängt.

Sieht auch ohne andere Plugins nicht anders aus:

---

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] VDR version 2.4.1 started

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] switched to user 'vdr'

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] codeset is 'UTF-8' - known

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] override character table is 'ISO-8859-15'

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading plugin: /usr/lib/vdr/plugins/libvdr-softhdcuvid.so.2.4.1

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/setup.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/sources.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/diseqc.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/scr.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/channels.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/timers.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/svdrphosts.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/remote.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/keymacros.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/camresponses.conf

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] DVB API version is 0x050B (VDR was built with 0x050B)

Oct 26 09:41:32 vdrmain vdr[7415]: [7415] frontend 0/0 provides DVB-S,DVB-S2 with QPSK ("Montage Technology M88RS6000")

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] frontend 1/0 provides DVB-S,DVB-S2 with QPSK ("Montage Technology M88RS6000")

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] found 2 DVB devices

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] initializing plugin: softhdcuvid (2.1.0-GIT9003bee): A software and GPU emulated UHD device

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] setting primary device to 3

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] setting current skin to "lcars"

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] loading /var/lib/vdr/themes/lcars-default.theme

Oct 26 09:41:33 vdrmain vdr[7415]: [7415] starting plugin: softhdcuvid

Oct 26 09:41:33 vdrmain vdr[7415]: video: visual 0x21 depth 24

Oct 26 09:41:33 vdrmain vdr[7415]: Create Window at 0,0

Oct 26 09:41:33 vdrmain vdr[7415]: video: window prepared

Oct 26 09:41:33 vdrmain vdr[7415]: video: screen saver extension present

Oct 26 09:41:33 vdrmain vdr[7415]: Init Placebo

Oct 26 09:41:34 vdrmain vdr[7415]: No support for dma_buf import in Vulkan

----

Thread 1 "vdr" received signal SIGSEGV, Segmentation fault.

0x0000000000000000 in ?? ()

(gdb) bt

#0 0x0000000000000000 in ?? ()

#1 0x00007fffd8867150 in ?? () from /usr/lib/libnvidia-eglcore.so.430.40

#2 0x00007fffd885b7ea in ?? () from /usr/lib/libnvidia-eglcore.so.430.40

#3 0x00007fffd885b8a9 in ?? () from /usr/lib/libnvidia-eglcore.so.430.40

#4 0x00007ffff4a4ab07 in pl_vulkan_create_swapchain () from /usr/lib/libplacebo.so.18

#5 0x00007ffff6a3a547 in InitPlacebo () at video.c:5280

#6 0x00007ffff6a3d642 in VideoInit (display_name=<optimized out>) at video.c:6796

#7 0x00007ffff6a35194 in StartVideo () at softhddev.c:3253

#8 Start () at softhddev.c:3253

#9 0x00007ffff6a2b373 in cPluginSoftHdDevice::Start (this=<optimized out>) at softhdcuvid.cpp:3095

#10 0x0000555555671d2c in cPluginManager::StartPlugins() ()

#11 0x00005555555f1211 in main ()

(gdb)

------

Bei mir ist libglvnd installiert, ist das ok?

Aaarg, nach dem letzten Arch "distupgrade" meine heute morgen lässt sich das Plugin nicht mehr kompilieren Hat jemand n Top in welche Richtung ich forschen muss?

Lars

[vdr@vdr vdr-softhdcuvid]$ makepkg -c -r -s -f
==> WARNUNG: PACKAGER should have the format 'Example Name <email@address.invalid>'
==> Erstelle Paket: vdr-softhdcuvid 1.1.0.r16.gfae0d3a-2 (Sa 26 Okt 2019 12:16:51 CEST)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Prüfe Buildtime-Abhängigkeiten...
==> Empfange Quellen...
-> Aktualisiere das vdr-plugin-softhdcuvid git Repo...
Fordere an von origin
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Entpacke Objekte: 100% (4/4), Fertig.
Von https://github.com/jojo61/vdr-plugin-softhdcuvid
* [neue Referenz]   refs/pull/7/head  -> refs/pull/7/head
* [neue Referenz]   refs/pull/7/merge -> refs/pull/7/merge
-> 50-softhdcuvid.conf gefunden
==> Überprüfe source Dateien mit sha512sums...
vdr-plugin-softhdcuvid ... Übersprungen
50-softhdcuvid.conf ... Durchgelaufen
==> Entpacke Quellen...
-> Erstelle Arbeitskopie des vdr-plugin-softhdcuvid git Repos...
Klone nach 'vdr-plugin-softhdcuvid' ...
Fertig.
Zu neuem Branch 'makepkg' gewechselt
==> Beginne prepare()...
==> Beginne pkgver()...
==> Beginne build()...
g++ -march=broadwell -mtune=intel -O2 -pipe -fstack-protector-strong -fno-plt -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE     -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include        -I/opt/cuda/include  -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG  -DCUVID			 -DHAVE_GL			 -DAV_INFO -DAV_INFO_TIME=3000	 -DUSE_PIP			 -DUSE_MPEG_COMPLETE		 -DH264_EOS_TRICKSPEED		 -DUSE_VDR_SPU			 -DUSE_ALSA -DUSE_OPENGLOSD -DUSE_GLX -DUSE_SCREENSAVER -DUSE_SWRESAMPLE  -DGIT_REV='"fae0d3a"'  -g  -Wextra -Winit-self -Werror=overloaded-virtual -std=c++0x  -D_FORTIFY_SOURCE=2  -c -o softhdcuvid.o softhdcuvid.cpp
cc -march=broadwell -mtune=intel -O2 -pipe -fstack-protector-strong -fno-plt -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE      -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include        -I/opt/cuda/include  -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG  -DCUVID			 -DHAVE_GL			 -DAV_INFO -DAV_INFO_TIME=3000	 -DUSE_PIP			 -DUSE_MPEG_COMPLETE		 -DH264_EOS_TRICKSPEED		 -DUSE_VDR_SPU			 -DUSE_ALSA -DUSE_OPENGLOSD -DUSE_GLX -DUSE_SCREENSAVER -DUSE_SWRESAMPLE  -DGIT_REV='"fae0d3a"'  -g -W  -Wextra -Winit-self -Wdeclaration-after-statement -D_FORTIFY_SOURCE=2  -c -o softhddev.o softhddev.c
cc -march=broadwell -mtune=intel -O2 -pipe -fstack-protector-strong -fno-plt -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE      -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include        -I/opt/cuda/include  -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG  -DCUVID			 -DHAVE_GL			 -DAV_INFO -DAV_INFO_TIME=3000	 -DUSE_PIP			 -DUSE_MPEG_COMPLETE		 -DH264_EOS_TRICKSPEED		 -DUSE_VDR_SPU			 -DUSE_ALSA -DUSE_OPENGLOSD -DUSE_GLX -DUSE_SCREENSAVER -DUSE_SWRESAMPLE  -DGIT_REV='"fae0d3a"'  -g -W  -Wextra -Winit-self -Wdeclaration-after-statement -D_FORTIFY_SOURCE=2  -c -o video.o video.c
cc -march=broadwell -mtune=intel -O2 -pipe -fstack-protector-strong -fno-plt -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE      -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include        -I/opt/cuda/include  -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG  -DCUVID			 -DHAVE_GL			 -DAV_INFO -DAV_INFO_TIME=3000	 -DUSE_PIP			 -DUSE_MPEG_COMPLETE		 -DH264_EOS_TRICKSPEED		 -DUSE_VDR_SPU			 -DUSE_ALSA -DUSE_OPENGLOSD -DUSE_GLX -DUSE_SCREENSAVER -DUSE_SWRESAMPLE  -DGIT_REV='"fae0d3a"'  -g -W  -Wextra -Winit-self -Wdeclaration-after-statement -D_FORTIFY_SOURCE=2  -c -o audio.o audio.c
audio.c: In Funktion »AudioInit«:
audio.c:2959:7: Warnung: diese Anweisung könnte durchfallen [-Wimplicit-fallthrough=]
2959 |    if (AudioChannelsInHw[4]) {
|       ^
audio.c:2963:7: Anmerkung: hier
2963 |       case 4:
|       ^~~~
audio.c:2964:7: Warnung: diese Anweisung könnte durchfallen [-Wimplicit-fallthrough=]
2964 |    if (AudioChannelsInHw[5]) {
|       ^
audio.c:2968:7: Anmerkung: hier
2968 |       case 5:
|       ^~~~
audio.c:2969:7: Warnung: diese Anweisung könnte durchfallen [-Wimplicit-fallthrough=]
2969 |    if (AudioChannelsInHw[6]) {
|       ^
audio.c:2973:7: Anmerkung: hier
2973 |       case 6:
|       ^~~~
audio.c:2974:7: Warnung: diese Anweisung könnte durchfallen [-Wimplicit-fallthrough=]
2974 |    if (AudioChannelsInHw[7]) {
|       ^
audio.c:2978:7: Anmerkung: hier
2978 |       case 7:
|       ^~~~
audio.c:2979:7: Warnung: diese Anweisung könnte durchfallen [-Wimplicit-fallthrough=]
2979 |    if (AudioChannelsInHw[8]) {
|       ^
audio.c:2983:7: Anmerkung: hier
2983 |       case 8:
|       ^~~~
video.c:515:10: Fehler: In Konflikt stehende Typen für »gettid«
515 | uint64_t gettid()
|          ^~~~~~
In Datei, eingebunden von /usr/include/unistd.h:1170,
von video.c:69:
/usr/include/bits/unistd_ext.h:34:16: Anmerkung: Vorherige Deklaration von »gettid« war hier
34 | extern __pid_t gettid (void) __THROW;
|                ^~~~~~
video.c: In Funktion »CuvidDisplayFrame«:
video.c:3828:5: Warnung: Implizite Deklaration der Funktion »glXWaitVideoSyncSGI«; meinten Sie »GlxGetVideoSyncSGI«? [-Wimplicit-function-declaration]
3828 |     glXWaitVideoSyncSGI (2, (Count + 1) % 2, &Count);   // wait for previous frame to swap
|     ^~~~~~~~~~~~~~~~~~~
|     GlxGetVideoSyncSGI
video.c:4001:2: Warnung: Implizite Deklaration der Funktion »glXGetVideoSyncSGI«; meinten Sie »GlxGetVideoSyncSGI«? [-Wimplicit-function-declaration]
4001 |  glXGetVideoSyncSGI (&Count);    // get current frame
|  ^~~~~~~~~~~~~~~~~~
|  GlxGetVideoSyncSGI
make: *** [<eingebaut>: video.o] Fehler 1
make: *** Es wird auf noch nicht beendete Prozesse gewartet....
softhdcuvid.cpp: In Elementfunktion »virtual eOSState cSoftHdMenu::ProcessKey(eKeys)«:
softhdcuvid.cpp:2351:18: Warnung: diese Anweisung könnte durchfallen [-Wimplicit-fallthrough=]
2351 |      HotkeyState = HksInitial;
|      ~~~~~~~~~~~~^~~~~~~~~~~~
softhdcuvid.cpp:2352:2: Anmerkung: hier
2352 |  case HksRed:   // red and first number
|  ^~~~
==> FEHLER: Ein Fehler geschah in build().
Breche ab...
[vdr@vdr vdr-softhdcuvid]$

Neuen Pull-Request erstellt, reindent aller Sourcen gemäß common style (wie in anderen Plugins). .indent.pro ist mit eingecheckt, sollte für zukünftige Arbeiten alles etwas übersichtlicher machen.

zork

Zitat von jojo61

Lösche gettid aus video.c

It works, vielen Dank!! Btw. die video.h wars

Lars

Zitat von jojo61

So etwas wie mpv --gpu-api=vulkan  <videofile> sollte da helfen. Evtl mach noch -v -v dazu um zu sehen was passiert.

Witzigerweise geht mpv problemlos, log im Anhang.

Aber bingo, ich habe das Problem gefunden, libplacebo läuft jetzt (wenn auch nicht zufriedenstellend). Das ganze Problem lag an fehlenden environmentvariablen im systemd environment. Ohne libplacebo wie gesagt kein Problem, da softhdcuvid.conf displaydefinition (-d :0.0) enthält. libplacebo reicht das offensichtlich nicht: erst nachdem ich vdr.service file von Systemd mit

---

[Service]

Environment="DISPLAY=:0.0"

Environment="XSESSION=/home/vdr/.Xsession"

---

ergänzt habe, lief libplacebo-basierte Version von softhdcuvid! Gemein.

jojo61, danke für deine Geduld! Ich weiß, war bereits sehr grenzwertig.

Jetzt noch ergänzend zum Verhalten: Meine aktuelle Version (von 12. Okt) verliert Frames in SD, HD, UHD. Bei SD ca. dropped Frames 3 Frames/sec, Frame Process time 0.37 ms. Bie HD und UHD mehr. Nvidia-smi zeigt utilization 30% (SD) .. 70% (UHD). Ist nicht plausibel: Frames gehen verloren obwohl anscheinend jede menge "processing-Kapazitäten" da sind. Kann es sein, dass ich mir eine neuere Version holen soll oder gab es nichtts in dieser Richtung?

BTW: habe versucht für SD auf "bicubic" umzustellen, er ist eine Verbesserung da, aber Frames werden immer noch gedropped auch in SD.