softhdcuvid jetzt mit VAAPI und HDR support

Unter Nvidia cuvid kann kein 4K testen, unter 1920 passt es da.

mit softhdvaapi und drm verhält es sich gleich falsch.

Zitat von jojo61

FireFly Ich nutze auch Suse 15.1 und da funktioniert alles. Welches Farbtiefe hast du denn bei X eingestellt (24 oder 30 ) ?

Ich hatte 24, jetzt habe ich 30 - kein Unterschied, OSD erscheint nicht. Ich habe mittlerweile auch ein GLX Demoprogramm compiliert, das ein Rechteck auf dem Bildschirm erzeugt - funktioniert als root und auch als User vdr.

Wenn ich es als VDR-User starte legt es die Grafik über den gesamten Bildschirm und nach dem stoppen sehe ich wieder das laufende Fernsehbild.

Das erste OSD-Menü nach dem VDR-Start scheint wohl erzeugt zu werden (bleibt aber unsichtbar), aber wenn das zweite dargestellt/erzeugt werden soll bleibt das Fernsehbild stehen.

Kann das an Rechten liegen, z.B. von Device-Files? Aber dann dürfte das Demoprogramm auch nicht funktionieren

# glxinfo |grep Mesa
client glx vendor string: Mesa Project and SGI
    Device: Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)  (0x3e91)
OpenGL renderer string: Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2
OpenGL version string: 3.0 Mesa 18.3.2
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.2

# vulkaninfo |more
===========
VULKAN INFO
===========

Vulkan API Version: 1.0.65

ERROR: [loader] Code 0 : libVkICD_mock_icd.so: cannot open shared object file: No such file or directory
Instance Extensions:
........

Hat das etwas zu bedeuten? Ich konnte die Datei nicht finden

# /usr/lib64/mesa-demos/xdemos/overlay
Couldn't get an overlay visual.
Your hardware probably doesn't support framebuffer overlay planes.

Werden diese Overlays gebraucht? Ist das evtl das Problem?

2019-12-23T16:05:03.166976+01:00 vdr vdr: [1934] [softhddev]CreateOsd: left 154, top 937, level 0, using OpenGL OSD support
2019-12-23T16:05:03.167195+01:00 vdr vdr: [1934] [softhddev]Trying to start OpenGL Worker Thread
2019-12-23T16:05:03.167389+01:00 vdr vdr: [1978] oglThread thread started (pid=1934, tid=1978, prio=high)
2019-12-23T16:05:03.167580+01:00 vdr vdr: [1978] [softhddev]OpenGL using display :0
2019-12-23T16:05:03.200134+01:00 vdr vdr: [1978] [softhddev]OpenGL Context initialized
2019-12-23T16:05:03.200407+01:00 vdr vdr: [1978] [softhddev]Shaders initialized
2019-12-23T16:05:03.200565+01:00 vdr vdr: [1978] [softhddev]vdpau interop initialized
2019-12-23T16:05:03.200710+01:00 vdr vdr: [1978] [softhddev]Vertex buffers initialized
2019-12-23T16:05:03.200846+01:00 vdr vdr: [1978] [softhddev]Maximum Pixmap size: 16384x16384px
2019-12-23T16:05:03.200981+01:00 vdr vdr: [1934] [softhddev]OpenGL Worker Thread successfully started
2019-12-23T16:05:03.201115+01:00 vdr vdr: [1934] [softhddev]cOglOsd osdLeft 154 osdTop 937 screenWidth 1920 screenHeight 1080
2019-12-23T16:05:03.240562+01:00 vdr vdr: vor create osd
2019-12-23T16:05:03.240993+01:00 vdr vdr: vor compile vertex osd
2019-12-23T16:05:03.241231+01:00 vdr vdr: compile Status 1 loglen 0 ><
2019-12-23T16:05:03.241422+01:00 vdr vdr: vor compile fragment osd
2019-12-23T16:05:03.241600+01:00 vdr vdr: compile Status 1 loglen 0 ><
2019-12-23T16:05:03.241781+01:00 vdr vdr: Link Status 1 loglen 0
2019-12-23T16:06:02.694353+01:00 vdr vdr: [1940] changing pids of channel 4 (SWR RP HD) from 5131+5131=27:5132=deu@3,5133=mis@3;5136=deu@106:5135=deu:5134 to 5121+5121=27:5122=deu@3,5123=mis@3;5126=deu@106:5135=deu:5134

Das Log (mit DEBUG kompiliert) sieht IMHO ok aus

Zitat von jojo61

Ist denn das Video wieder zu sehen wenn das OSD wieder weg ist.

Nein, das OSD ist nie zu sehen. Wenn ich während der ersten paar Sekunden (in denen das erste OSD zusehen wäre) umschalte, Mute drücke etc. läuft das Bild weiter, aber es ist kein OSD zu sehen. Wenn ich etwas später umschalte (d.h. ein neues OSD erzeuge), dann bleibt das Video-Bild stehen und nur der Ton läuft weiter. Das sieht so aus, als würde das erste OSD-Objekt nicht dargestellt (bzw. wartet auf die Darstellung), kann auch nicht destroyed werden und wenn dann das zweite OSD dargestellt werden soll bleibt auch das Videobild hängen.

Ich denke, es wird der Intel-Treiber benutzt, X log:

15.446] (II) LoadModule: "intel"
[    15.446] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
[    15.448] (II) Module intel: vendor="X.Org Foundation"
[    15.448]    compiled for 1.20.3, module version = 2.99.917
[    15.448]    Module class: X.Org Video Driver
[    15.448]    ABI class: X.Org Video Driver, version 24.0
[    15.448] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
        i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
        915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
        Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
        GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[    15.448] (II) intel: Driver for Intel(R) HD Graphics
[    15.448] (II) intel: Driver for Intel(R) Iris(TM) Graphics
[    15.448] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics
[    15.487] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20180719
[    15.488] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics
[    15.488] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx, avx2; using a maximum of 4 threads
[    15.488] (**) intel(0): Depth 24, (--) framebuffer bpp 32
[    15.488] (==) intel(0): RGB weight 888
[    15.488] (==) intel(0): Default visual is TrueColor

Heißt das der Intel-Treiber nutzt den modeset-Treiber ?!?!?

Zitat von jojo61

Du könnest mal ein Screencapture machen und schauen ob dort das OSD zu sehen ist. Das geht mit svdrpsend.

Interessant! Im gegrabbten Biild ist das OSD zu sehen!

Mit "modesetting" ruckelt das Bild nach wenigen Sekunden, ist asynchron zum Ton und im VDR Log gibts Ringbuffer Overflow Meldungen, wird also offenbar nicht in HW dekodiert.

Was ich sonst noch versucht habe: Debug-Meldungen in Klasse cOglOsd und cOglThread::DoCmd, das sieht aber alles OK aus. Das Flush hängt nie, meistens wird bei !dirty rausgesprungen aber manchmal auch bis zum Ende durchgelaufen und bei DoCmd baut sich ne Queue auf von ca 20 commands, die aber auch direkt wieder alle abgearbeitet werden.

In X sind u.a. die Extensions GLX und Composite geladen (werden die gebraucht? welche evtl noch?), in keinem Log gibt's Fehlermeldungen oder Warnungen. Der VDR läuft nur mit den absolut notwendigen Plugins.

In der xorg.conf und *.d habe ich etliche Sachen ausprobiert und auskommentiert, aber ohne Erfolg. Einmal kurz habe ich einen OSD-Balken gesehen nachdem ich DGA abgeschaltet hatte, konnte es aber nicht mehr reproduzieren.

Die neue GIT Version mit Änderungen im Shader brachte auch keinen Erfolg.

Auch das Erhöhen des Grafikspeichers von 64MB auf 512 im Bios hat nichts gebracht.

Was mir nicht klar ist: Wie kommt das auf den Bildschirm? Im Plugin läuft ja alles fehlerfrei und es bleibt nichts hängen, auch wenn das Bild stehen bleibt. Welche Log's gibt es noch oder was kann man noch testen?

Zitat von jojo61

Den Grafikspeicher musst du in jedem Fall auf 512MB im Bios einstellen.

Evtl. probiere mal die DRM Version. Die musst du dann aber auf der Konsole starten.

Ähm, kann ich das an meinem nuc8i3beh2 auch im Bios einstellen?

Zitat von CKone

Ähm, kann ich das an meinem nuc8i3beh2 auch im Bios einstellen?

Nein, kann man bei Bean Canyon nicht, nur "Minimum Memory Size" des IGD. Gibt hier nur 2 Werte, 32GB oder 64GB. Was tatsächlich benötigt wird, reserviert die Grafiktreiber mit dem OS im laufenden Betrieb.

"Aperture Size" ist nicht der Speicher für den IGD, sondern stellt nur einen dynamischen genutzten Adressraum für den IGD Speicher dar.

Zitat von jojo61

in der Datei video.c ist in der Zeile 4043 folgendes auskommentiert: // eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglThreadContext);

Aktiviere das mal. Mach die // weg. Bin gespannt ob dann das Video zu sehen ist. Und häng mal ein Debuglog von start bis zum ersten Bild an. Da müsste man sehen wir der BT709 shader und der OSD shader gebaut wird.

mfg

jojo61

PS: Hast du ambilight oder sowas am laufen ?

Alles anzeigen

Mit dem eglMakeCurrent wird endlich mal ein Fehler vom glewInit() angezeigt, aber Error: unknown Error

ambilight o.ä. läuft nicht, ich habe jetzt nur mit den minimalen Plugins getestet.

Hi,

die "drirc" ist schon am richtigen Platz?

CU

9000h

Ja, weil wie die gefehlt hatte, hatte ich andere Fehlermeldungen..... Habe grade die Rechte mal auf 644 gesetzt, hilft aber auch nichts

Zitat von fnu

Nein, kann man bei Bean Canyon nicht, nur "Minimum Memory Size" des IGD. Gibt hier nur 2 Werte, 32GB oder 64GB. Was tatsächlich benötigt wird, reserviert die Grafiktreiber mit dem OS im laufenden Betrieb.

"Aperture Size" ist nicht der Speicher für den IGD, sondern stellt nur einen dynamischen genutzten Adressraum für den IGD Speicher dar.

Hab jetzt die "Aperture Size" auf 512GB und die Lüftersteuerung auf "cool", damit funktioniert er jetzt tadellos auf einem UHD Sender seit über 30min, früher ist er nach weniger als 10 Minuten da mit einem grünverpixelten Bild ausgestiegen (VDR restart reichte allerdings, Reboot nicht notwendig).

Leider Falschmeldung, passiert weiterhin auch bei nur ~55 Grad, ausschließlich bei UHD und nach ner gewissen Laufzeit und egal ob vaapi oder drm.

Temperatur war vorher nicht signifikant höher bei ~65 Grad, denke das war eher nicht der Ausschlag, vllt mach ich ihn später wieder auf "quiet":

root@bionic:~# sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +62.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +59.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:        +59.0°C  (high = +100.0°C, crit = +100.0°C)

Das Problem mit den schwarzen Flächen im skindesiger ist damit leider nicht behoben, aber das hier ist schon super wenn die UHD Box auch länger als 10 Minuten UHD kann

Zitat von jojo61

Das Suse glew hat kein egl eincompiliert. Du musst dir glew selber compilieren.

Arghh, das erklärt's! Ich melde mich wieder wenn ich das drin habe

Zitat von jojo61

Hast du mal versucht den skin zu ändern und dann wieder zurück zu stellen ohne die Auflösung zu ändern ? Danach geht das bei mir dann.

Ich vermute es liegt am cachen im Skindesigner. Der bekommt da irgend etwas nicht mit.

ich glaube ich hab mittlerweile alles versucht ohne den geringsten Erfolg. Die Flächen des OSD sind in allen Konstellationen schwarz.

Es ist sogar so, dass wenn ich das OSD fest auf 1920x1080 anbinde das skalierte TV Bild wie hier zu sehen softhddevice <> 4k Auflösung <> skindesginer - OSD Problem fehlt. Das erhalte ich nur mit Auto (darunter die 128MB fürs OSD in den softhddrm Einstellungen passt aber?)

Wir können das aber auch gern mal zusammen in einer Skype oder Whatsapp Video Session durchspielen wenn du magst. Auch wie die Skins korrekt ausschauen mit softhdcuvid auf nem anderen VDR mit ner alten nvidia GT630.

Zitat von jojo61

Bzgl deinem UHD Problem: Wie hast du denn das DVB-S angeschlossen ? Ist das eine lokaler USB Empfänger oder per vnsi oder satip ?

Bei mir funktioniert eigentlich nur Satip. Bei VNSI zu meinen Server hatte ich auch Probleme mit dem Decoder und es wurde grün.

Ich habe nun auf dem Server ein minisatip server laufen.

mit streamdev, aber da sagst du was - ich hatte da auch schon drüber nachgedacht, genauso wie über ein UHD zertifiziertes HDMI Kabel.

hab einen minisatip mit zwei Tunern am laufen, teste ich später. Wolln noch schnell eine Runde in Dortmund über den Weihnachtsmarkt. - bei der ganzen Fresserei tut etwas Frischluft ganz gut,

Zitat von jojo61

Whatsapp habe ich nicht Und gibt es noch Skype für Linux ? Ich habe keine Windows Rechner hier

wenn ich das wüsste, nehm für sowas einfach iphone oder ipad Aber zumindest für Ubuntu würde es Pakete geben, sicher auch für SuSE: https://www.heise.de/tipps-tri…nktioniert-s-4399457.html