Posts by jojo61

Wenn ich dich richtig verstanden habe dann geht es incl. OSD wenn du den vdr normal startest mit aktiven plugin.

Wenn du aber mit -D startest oder ein DETA - ATTA bei funktionierendem plugin machst dann bleibt es stehen.

Es ist mir ein völliges Rätsel was hier passiert. Der Start des Plugins bei -D ist der gleiche wie ohne -D nur etwas später halt wenn das ATTA kommt.

Im Moment kann ich nur vermuten das es der NVIDIA Treiber 450 noch sein könnte. Allerdings wüsste ich nicht warum.

Da würde es nur helfen wenn du mal den 440.100er probierst der bei mir läuft.

Sorry wenn es dir zu viel arbeit macht.

Hier gibt es einen NVIDIA Fehlerreport Das könnte das Problem beschreiben.

Ok das bestätigt meine Vermutung das er im Swap hängen bleibt. Siehst du das OSD noch oder kommt das erst gar nicht hoch.

Laut Log sollte das noch angezeigt werden bevor es hängen bleibt. Zumindest swapped er noch 12 Frames mit OSD.

Welche Version von vulkan hast du denn ?

Und dann sehe ich immer einen VNSI: Requesting clients to reload timers kurz vor den Hänger. Kannst du das Plugin mal rausnehmen ?

Eigentlich sollte das Banding bei NVIDIA mit ihrem Dithering unterbunden werden. Aus meiner Sicht funktioniert das auch ganz gut.

Man kann das im nvidia-settings aber auch abschalten. Ich habe das bei mir abgeschaltet weil die libplacebo auch schon dithering macht in der Renderpipleline.

seahawk1986 wrote:

Gerne

Ich habe dir mal eine neue video.c angehängt mit mehr Debug prints. Das müllt dir nun syslog zu. Am besten du startest mit -D und dann machst du ein ATTA und dann ein ok

PS: du musst die Datei noch zu video.c umbenennen

10 Bit alleine reicht allerdings nicht für HDR. Da muss auch noch einer Schnittstelle zum übergeben der HDR Parameter an den Fernseher sein.

Und die gibt es mE. noch nicht lauffähig in Kernel. Allerdings habe ich auch schon eine Zeitlang nicht nachgeschaut.

Da frage ich mich ob Kodi das kann und wie sie es machen.

Ich könnte dir eine Version mit mehr Debugs verfügbar machen wenn du Lust zum Testen hast.

Da ich es hier nicht reproduzieren kann, kann ich sonst kaum helfen

Aus meiner Sicht hat sich hier nichts geändert. Bei mir geht 10 Bit über DP, aber nur in HD und in RGB 4:4:4.

Mehr geht nicht weil die NVIDIA Karte bei DP nicht in YUV 420 umschalten kann oder will. Und RGB 4:4:4 in 10 Bit die maximale Datenrate bei HDMI 2.0 sprengt.

Ich habe noch ein paar shader bereitgestellt die man zum Bildverbessern mal ausprobieren kann.

LumaSharpen und AdaptivSharpen sollte selbsterklärend sein.

MIt KrigBilateral wird bei YUV420 der UV Teil skaliert bevor die RGB umwandlung gemacht wird. Damit sollten Farbsäume an Schriften weniger sein.

Ohne skalierung von UV werden ja immer 4 Pixel mit der selben Farbe behaftet.

In den Shadern zum nachschärfen kann man die Parameter anpassen

Viel Spaß

OK mehr debug geht nicht als du schon hast ....

Und wenn ich das Log mit dem von mir vergleiche dann ist es identisch incl. dem Teil wo das OSD aufgebaut wird.

Nur warum es dann nicht angezeigt wird und das plugin stehen bleibt ist mir unklar.

Wenn ich mir das gdb anschaue dann sieht es so aus als ob er im swap stehen bleibt. Du hat die 450er NVIDIA Version.

Bei mir läuft alles grösser 440.100 nicht mehr. Dann bekomme ich nicht mal mehr ein laufendes X beim booten.

Ging es denn vor dem upgrade auf das neue libplacebo mit dem 450er NVIDIA Treiber?

seahawk1986 wrote:

Ich habe das Plugin mal komplett deaktiviert (davor wurde es geladen, aber LCARS als Skin genutzt).

Das ist dann immer noch das letzte, was ich vom Plugin sehe, wenn ich nach dem Attachen mit OK das OSD öffne:Ich habe mich dann mal mit gdb an den VDR gehängt, um zu sehen, was die einzelnen Threads gerade machen: gdb.txt - eventuell hilft das weiter.

Ich sehe immer noch nix. Kannst du mal das Plugin mit DEBUG im Makefile übersetzen und nochmal ein Log posten ?

Schwer zu finden wenn man es nicht reproduzieren kann. Hast du denn ein laufendes Bild bevor du ok drückst ?

lnj wrote:

jojo61

Please check the compilation with LIBPLACEBO ?= 0, I have error.

Ok fixed

Da sehe ich nichts auffälliges. Kannst du mal ohne skindesigner testen ?

zillerbaer wrote:

Der Direct Rendering Manager ist der zentrale Teil des Plugins. Neben der Enscheidung auf Abhängigkeiten zu X zu verzichten, ist das der prägente Teil meiner Philosophie. Ich sehe keinen Grund eine Namensänderung vorzunehmen.

Das ist völlig in Ordnung. Du warst eh der erste mit dem Namen.

Hmm das kann ich so nicht reproduzieren. bei mir klappt das in allen Fällen. Kannst du mal ein Log mit Debug anhängen ?

zillerbaer wrote:

Mit dem Softhddrm habe ich nix zu tun. jojo61 nennt sein plugin Softhddrm. Ist bissel unglücklich gewählt.

Ja die Namesgebung ist nicht so einfach. Die Version softhdcuvid und softhdvaapi orientiert sich am decoder und softhddrm orientiert sich am Ausgabe API. Ursprünglich wollte ich auch noch eine Version für den Raspi machen, habe das aber zwischenzeitlich aufgegeben weil er für meine Ideen einfach zu langsam ist.

Beim Raspi kann man nur sinnvoll Videos ausgeben wenn man auf dem ganzen Weg vom Stream zum Display nur Hardwareresourcen nutzt. D.h. Hardwardekoder für den Stream und HardwareAPI (drm) für die Ausgabe. Es gibt praktisch keine Möglichkeit das Bild zwischendurch zu bearbeiten. Dafür ist der Raspi bzw. die GPU zu langsam. Ich hatte eine Version mit einem opengl shader fertig zur konfertierung von YUV nach RGB auf X. Doch schon hier gab es Probleme mit der performance. Das ganze geht halt nur wenn man drm nutzt und das in Hardware machen lässt. Und dafür gibt es hier eine exzellente Entwicklung von zillerbaer

Ich finde die Idee das ganze softhddevice4arm zu nennen sehr gut zumal mit v4l2m2m ja auch ein "universal" decoder genutzt wird.

mfg

jojo61

lnj wrote:

LIBS += -L/usr/local/cuda/lib64

Have you decided to use CUDA libraries again instead of ffnvcodec?

Mist da ist mir ein Fehler mit dem Makefile unterlaufen. Ich werde es korrigeren. Natürlich nutze ich weiterhin ffnvcodec.

Habs nun korrigiert. Man kann die Zeile auch einfach löschen.

PS: Für cuvid gibt es eigentlich nichts neues, Alle änderungen bzgl. libplacebo mit opengl betreffen vaapi.

Hallo

so nach langer Zeit habe ich mal wieder etwas gebastelt und auf die neuste libplacebo upgedatet. Dabei habe ich nun auch support für libplacebo mit opengl eingebaut. Dann muss man kein vulkan mehr haben. Das geht aber nur für vaapi, dafür dann aber auch mit softhddrm.

Ich habe gesehen das lnj einiges von meiner cuvid Version übernommen hat. Das freut mich. Schau dir aber mal mein shader.h an da habe ich einiges verbessert und ich denke das kannst du 1:1 übernehmen. Da es nun libplacebo mit vulkan und opengl gibt und ich beide unterstütze werde ich den Support für alle Versionen ohne libplacebo rauswerfen. Das gibt es ja in sehr guter Qualität von lnj Damit wird es dann etwas übersichtlicher im Makefile und den Quellen. Die aktuelle Version geht aber auch noch ohne libplacebo.

Feedback erwünscht und viel Spaß

jojo61

vilrann wrote:

joulu 15 10:11:13 digiboksi2 vdr[513]: [513] loading plugin: /usr/lib/vdr/plugins/libvdr-softhdcuvid.so.2.4.3

joulu 15 10:11:13 digiboksi2 vdr[513]: [513] ERROR: /usr/lib/vdr/plugins/libvdr-softhdcuvid.so.2.4.3: undefined symbol: gbm_create_device

joulu 15 10:11:13 digiboksi2 vdr[513]: vdr: /usr/lib/vdr/plugins/libvdr-softhdcuvid.so.2.4.3: undefined symbol: gbm_create_device

The missing symbols are from the drm Version. If you really want to build a cuvid version then you should disable drm in the Makefile.

lnj wrote:

With softhddevice and vaapi pip does not work yet, now I do not have hardware to do something with vaapi.

PIP mit vaapi geht nicht. Der vaapi Dekoder kann nur einen Stream bearbeiten. FFMPEG verhindert zwar nicht einen zweiten zu öffnen, aber dann kommt der Dekoder durcheinander und mischt die Streams. das konnte ich gut beobachten beim Versich PIP in softhdvaapi zu korrigieren. Dann habe ich PIP aus softhdvaapi rausgenommen.

minixjr wrote:

Falls sich aber einer der softhddeviceXYZ Entwickler mal mit AMD und VA-API beschäftigt, könnte ich mir vorstellen, dass AMD in Zukunft die bessere Wahl sein wird.

Das war mal mein Plan aber dann hat sich die AMD RX 460 leider ins Nirwana verabschiedet. Und nochmal ca. 100€ auszugeben um den AMD Treiber fertig zu stellen war mir dann zu teuer. Ich nutze produktiv ja eine GTX 1050 und hatte die RX 460 nur zum entwickeln des Treibers gekauft. Den Intel Treiber habe ich ja noch gemacht auf meinem NUC. Wenn es also irgendwo eine ausgediente AMD Karte gibt. dann her damit

mfg

jojo61