softhdcuvid jetzt mit VAAPI und HDR support

Ich habe das Plugin mal versuchsweise paketiert - dabei ist mir aufgefallen, dass es einen Segfault gibt, wenn man sich nur für seinen Hilfetext interessiert:

$ vdr -P softhddrm -h
[...]
Plugins: vdr -P"name [OPTIONS]"

softhddrm (3.0.0) - A software and GPU emulated UHD device

  -a device     audio device (fe. alsa: hw:0,0 oss: /dev/dsp)
  -p device     audio device for pass-through (hw:0,1 or /dev/dsp1)
  -c channel    audio mixer channel name (fe. PCM)
  -d display    display of x11 server (fe. :0.0)
  -f            start with fullscreen window (only with window manager)
  -g geometry   x11 window geometry wxh+x+y
  -r Refresh    Refreshrate for DRM (default is 50 Hz)
  -C Connector  Connector for DRM (default is current Connector)
  -v device     video driver device (cuvid)
  -s            start in suspended mode
  -x            start x11 server, with -xx try to connect, if this fails
  -X args       X11 server arguments (f.e. -nocursor)
  -w workaround enable/disable workarounds
        no-hw-decoder           disable hw decoder, use software decoder only
        no-mpeg-hw-decoder      disable hw decoder for mpeg only
        still-hw-decoder        enable hardware decoder for still-pictures
        still-h264-hw-decoder   enable h264 hw decoder for still-pictures
        alsa-driver-broken      disable broken alsa driver message
        alsa-no-close-open      disable close open to fix alsa no sound bug
        alsa-close-open-delay   enable close open delay to fix no sound bug
        ignore-repeat-pict      disable repeat pict message
        use-possible-defect-frames prefer faster channel switch
  -D            start in detached mode

Speicherzugriffsfehler (Speicherabzug geschrieben)

Sieht so aus, als würde er im Destructor versuchen Dinge aufzuräumen, von denen ich nicht sicher bin, ob er die für die Ausgabe überhaupt braucht:

(gdb) bt
#0  0x00007ffff6ff1bed in drm_clean_up () at drm.c:464
#1  VideoExit () at video.c:6687
#2  0x00007ffff6fe9c26 in StopVideo () at softhddev.c:2013
#3  SoftHdDeviceExit () at softhddev.c:3131
#4  0x00007ffff6fe0c1b in cPluginSoftHdDevice::~cPluginSoftHdDevice (this=0x5555558080c0, __in_chrg=<optimized out>)
    at softhdcuvid.cpp:3050
#5  0x00007ffff6fe0c3d in cPluginSoftHdDevice::~cPluginSoftHdDevice (this=0x5555558080c0, __in_chrg=<optimized out>)
    at softhdcuvid.cpp:3046
#6  0x00005555556795a5 in cDll::~cDll (this=0x5555557c11b0, __in_chrg=<optimized out>) at plugin.c:189
#7  0x00005555556795dd in cDll::~cDll (this=0x5555557c11b0, __in_chrg=<optimized out>) at plugin.c:187
#8  0x00005555556c82f2 in cListBase::Del (this=this@entry=0x7fffffffe4c0, Object=Object@entry=0x5555557c11b0,
    DeleteObject=DeleteObject@entry=true) at tools.c:2195
#9  0x000055555567aced in cPluginManager::Shutdown (this=this@entry=0x7fffffffe4a0, Log=Log@entry=false) at plugin.c:518
#10 0x000055555567ad1d in cPluginManager::~cPluginManager (this=0x7fffffffe4a0, __in_chrg=<optimized out>) at plugin.c:306
#11 0x00005555555f58d8 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:699

kannst du für unsere Tests noch einmal bitte die Eckpunkte bestätigen jojo, nicht das wir im Dunkeln rumstochern

Also die drm Version des Plugins spielt ohne X Server, und wenn man erstmal das HDR außer Acht lässt dann tut es auch ein mainstream 5.3 Kernel wie zB aus ubuntu fokal 20.04?

Müssen wir dem Plugin dann noch irgendwas mitgeben damit es das Display und das Pulseaudio Gerät findet?

Mit dem softhdvaapi läuft das sehr prima auf dem NUC8, hab die libplacebo allerdings wieder rausgenommen, ich finde die Bildqualität ist damit unter aller Kanone - weiß gar nicht wo ich da überall drehen soll damit das wieder passt. Mit der Verision ohne libplacebo spielt es dagegen in der nvidia Klasse, hier auch ohne jegliche Ruckler oder andere Zicken...

Gruß Christian

Kann es sein, dass im Makefile fälschlicherweise nicht gegen die libEGL gelinkt wird, wenn softhddrm gebaut wird? CKone und ich hatten da einen missing Symbol Error:

Dec 20 11:12:41 bionic vdr: [1115] loading plugin: /usr/lib/vdr/plugins/libvdr-softhddrm.so.2.4.1

Dec 20 11:12:41 bionic vdr: [1115] ERROR: /usr/lib/vdr/plugins/libvdr-softhddrm.so.2.4.1: undefined symbol: eglGetCurrentDisplay

Dec 20 11:12:41 bionic vdr[1115]: vdr: /usr/lib/vdr/plugins/libvdr-softhddrm.so.2.4.1: undefined symbol: eglGetCurrentDisplay

Index: vdr-plugin-softhddrm-2.1.0+git20191212-8-d2dedb4/Makefile
===================================================================
--- vdr-plugin-softhddrm-2.1.0+git20191212-8-d2dedb4.orig/Makefile      2019-12-12 11:31:40.000000000 +0100
+++ vdr-plugin-softhddrm-2.1.0+git20191212-8-d2dedb4/Makefile   2019-12-16 15:10:05.377770126 +0100
@@ -164,6 +164,7 @@
 CONFIG += -DUSE_DRM -DVAAPI
 _CFLAGS += $(shell pkg-config --cflags libdrm)
 LIBS += -lgbm -ldrm
+LIBS += -lEGL
 endif

Zitat von jojo61

Könnte aber auch daran liegen das ihr im Makefile nur DRM ausgewählt habt. Bei mir war zusätzlich noch VAAPI ausgewählt.

Ja, ich lasse die einzelnen Plugins getrennt bauen.

Ich wollte softhdvaapi auch mal ausprobieren, bekomme aber beim Start direkt ein Shader-Compile Error und kein Bild:

vdr: [1683] OSD size changed to 1920x1080 @ 1
vdr: [1683] [softhddev]CreateOsd: left 154, top 461, level 0, using OpenGL OSD support
vdr: [1683] [softhddev]Trying to start OpenGL Worker Thread
vdr: [1760] oglThread thread started (pid=1683, tid=1760, prio=high)
vdr: [1760] [softhddev]OpenGL using display :0 vdr: [1760] [softhddev]OpenGL Context initialized
vdr: [1760] #012[softhddev]:SHADER: Compile-time error: Type: 0 - #012>0:2(2): error: syntax error, unexpected NEW_IDENTIFIER#012<
vdr: [1760] [softhddev]ERROR compiling shader
vdr: [1760] [softhddev]Could not initiate Shaders
vdr: [1760] [softhddev]OglThread cleanup
vdr: [1760] oglThread thread ended (pid=1683, tid=1760)
vdr: [1683] [softhddev]openGL Thread NOT successfully started
vdr: [1683] [softhddev]OpenGl Thread not started successfully, using Dummy OSD
vdr: [1759] [softhddev]stopping OpenGL Worker Thread
vdr: [1759] [softhddev]OpenGL Worker Thread stopped
vdr: video: normal aspect output 1077x1079+421+0 Video 1920x1079
vdr: [1759] [softhddev]stopping OpenGL Worker Thread
vdr: [1759] [softhddev]OpenGL Worker Thread stopped
vdr: video: normal aspect output 1915x1080+2+0 Video 1920x1080
vdr: GetFormat Init ok 1280x720

Skin ist mittlerweile das VDR Default Skin, CPU/GPU ist ein i3-8300, VAAPI=1, LIBPLACEBO=0

Ich dachte das liegt am ausgeschalteten libplacebo, aber mit libplacebo 0.5.0 compiliert es nicht mehr

so, mal ein aktueller Stand zu vdr-plugin-softhddrm, derzeit jetzt mit UHD HDR TV, dafür aber noch ohne den intel-drm-kernel:

- unter yavdr haben wir kein Bild bekommen ohne den X Server am Start zu hindern, das mag aber auch durch die Architektur begründet sein

- Ton war etwas tricky, geholfen hat am Ende das alte Vorgehen zu pcm.51to20: http://www.vdr-wiki.de/wiki/in…Softhddevice-plugin#Audio

- insgesamt fühlt sich das schon noch runder an als vdr-plugin-softhdvaapi, was aber auch schon gut ist.

- wenn ich länger auf einem UHD Testsender stehe dann kommt nach einiger Zeit so ein grünes bzw grün verschneites Bild. War unter softhdvaapi auch schon so: weiß nicht ob der nuc bei 60 Grad da zu warm wird oder wo der Schuh drückt. Mit 1920x1080 Inhalten passiert das nicht.

- sehr geil ist das unter beiden Plugins die atmo Schnittstelle weiter funktioniert, Jörg hat schon eine Erweiterung ins seduatmo eingechecked, für vdrboblight ist das noch anhängig.

Enttäuscht bin ich momentan von den vorhanden skindesigner skin (insbesondere die mit zapcockpit Unterstützung), weiß aber nicht ob es am intel Treiber oder am UHD liegt: shady und estuary4vdr gehen gar nicht, die meisten Flächen sind entweder tiefschwarz oder vollkommen transparent. Einzig matrixHD wirklich funktioniert tadellos. Alexander hatte den Hinweis das es womöglich an den dort verwendeten Vector Grafiken liegt - hier werde ich mal Tomas ansprechen ob er da eine Idee hat was sonst noch an shady anders ist.

Alles in allem bin ich schon sehr zufrieden, vielen Dank an jojo, aber auch nicht weniger an Alexander der sich die Zeit genommen hat das mühselig mit mir zu debuggen, und letztendlich auch an horchi für die schnelle Anpassung seines Plugins.

Als nächstes hoffe ich das es zeitnah einen passende intel-drm-kernel für ubuntu gibt der der uns große Patchorgien erspart

Gruß Christian

ich glaube das mit dem skindesigner ist eher ein Problem der skalierten skin als vom frontend, werde die drm version nachher noch mal in 1920x1080 starten und schauen wie das da ausschaut. Dein patch ist in jedem Fall drin in meinem skindesigner, hab ich kontrolliert.

Beim Audio gab es immer ein Problem mit dem 5.1 Downmix, das schlägt vor allem dann durch wenn es nur eine Tonspur gibt (zB RTL HD wenn die in 5.1 senden) - die letzten Jahre haben wir das von pulseaudio machen lassen aber für alsa bedarf es da dieser Krücke. Wir schauen aber nochmal ob wir nicht doch besser pulse weiternutzen können.

Wenn du was hörst wegen der Integration deiner Patche in den drm-intel sag bitte Bescheid, dann schauen wir da auch.

Gruß Christian

Zitat von jojo61

FireFly Du musst die drirc als .drirc in dein Homeverzeichnunss legen. Dann sollte es mit den Shadern klappen.

Danke, damit bekomme ich ein Bild. Ich hatte die Infos zu der Datei zwar gelesen, aber nicht mit meinem Problem in Verbindung gebracht.

Jetzt bleibt das Bild stehen, wenn das OSD aufgemacht wird (und OSD erscheint keins, aber auch keine Fehlermeldung im Log), das muss ich mir später noch mal genauer ansehen.

Zitat von jojo61

Der Skindesigner kann ja von sich aus kein UHD. Da musst du in jedem Fall dann das OSD fest auf 1920x1080 einstellen. Das sollte im Setup machbar sein.

mfg

jojo61

merkwürdig, matrixhd läuft hier super mit voller Auflösung

werde später shady nochmal in „Klein“ versuchen.

ups, kannst du mir sagen wo ich das finde? - mir ist so als ob ich das früher schon mal gemacht habe.

habs gefunden.

Macht aber keinen Unterschied.

also, ich habe genau diesen Effekt, also nix neues!

softhddevice <> 4k Auflösung <> skindesginer - OSD Problem

Zitat von jojo61

Da sieht mir immer noch nach einen Problem mit dem OSD aus. Da wird dann das OSD angezeigt und das im Hintergrund laufende Video nicht mehr durchgereicht.

Das ist wohl ein alphablending Problem. Welche Version nutzt du denn ?

Und kommentiere LIBPLACEBO mal mit # aus dem Makefile anstatt es auf 0 zu setzen.

Also intel_gpu_top zeigt noch Render-Last an wenn das Bild stehen bleibt, das spricht für ein alphablending Problem. Dein Plugin habe ich gestern ausgechecked, OS ist 0pensuse 15.1 mit ffmpeg 4 von Packman.

LIBPLACEBO war bereits mit # auskommentiert.

glxgears zeigt auch was an (50 fps), da ist das Bild dann weg und kommt auch nicht mehr wenn man glxgears abbricht. Beim Stoppen des VDR wird ganz kurz das aktuelle Fernsehbild angezeigt, vermutlich weil das OSD dann zugemacht wird.

Fehlt vielleicht noch irgendein Paket?