Ich habe nur die permissive flags bei CUVID aktiviert. Teste mal.
Damit compiliert es bei mir auch wieder.
Vielen Dank.
Posts by heifisch
-
-
Schuld an dem Kompilier-Fehler ist folgender commit:
Diff
Display Morecommit 40c2152557b27ba0c98839371787a8cea348a14f Author: jojo61 <git@jojo61.de> Date: Sun Oct 19 16:31:38 2025 +0200 Adapt Makefile CFLAGS diff --git a/Makefile b/Makefile index 6147df1..316c7eb 100644 --- a/Makefile +++ b/Makefile @@ -113,8 +113,8 @@ TMPDIR ?= /tmp ### The compiler options: -export CFLAGS = $(call PKGCFG,cflags) -fpermissive -export CXXFLAGS = $(call PKGCFG,cxxflags) -fpermissive +export CFLAGS = $(call PKGCFG,cflags) +export CXXFLAGS = $(call PKGCFG,cxxflags) ifeq ($(CFLAGS),) $(warning CFLAGS not set) -
Zwischen der 3.33 und der 3.34 gab es "nur" Änderungen bzgl. des vaapi deinterlacers. Wenn da nun compiler Fehler bzgl. CUDA includes auftauchen, dann liegt das sicher an der Compilierumgebung.
die sich aber zwischen 3.33 und 3.34 nicht geändert hat...
Getestet mit git checkout V3.33
-
Hm, dann danke für die Übernahme -- da wäre doch ein eigenes Thema besser angebracht wie z.B. "[softhdcuvid] Problem mit CUDA"
Ich habe hier nichts übernommen.
Ich habe nur darauf hingewiesen, dass die hier angezeigten Änderungen zu einem Fehler beim Compilieren führen.Es handelt sich schließlich um die gleichen Sourcen...
-
Das hat nichts mit dem ffmpeg zu tun. Du compilierst für die CUDA variante und dir fehlen die cude includes oder sie sind zu neu. Zabrimus hat das schon bei LE13 gefunden.
Ausserdem scheint etwas mit deinen xcb includes zu neu oder fehlerhaft zu sein.
Hallo jojo61.
Ich habe den Fehler nur hier gepostet, weil Du hier auf die neue Version hingewiesen hast.
Was die includes angeht, die V3.33 lässt sich in der gleichen Umgebung kompilieren.
Deshalb bin ich davon ausgegangen, dass der Fehler mit den letzten Änderungen gekommen ist. -
Ich bekomme mit ffmpeg-8.0 und softhdcuvid-3.34 folgenden Compilier-Fehler:
Code
Display Morevdr /usr/local/src/vdr-plugin-softhdcuvid # make x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -ggdb3 -g -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURC E -I/usr/include -I/usr/include/freetype2 -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG -DHAVE_GL -DAV_INFO -DAV_INFO_TIME=3000 -DUSE_MPE G_COMPLETE -DH264_EOS_TRICKSPEED -DUSE_VDR_SPU -DUSE_OPENGLOSD -DUSE_GLX -DPLACEBO -DCUVID -DYADIF -DUSE_SCREENSAVER -DGIT_ REV='"618b689"' -g -W -Wextra -Werror=overloaded-virtual -Wno-unused-parameter -c -o softhdcuvid.o softhdcuvid.cpp cc -O2 -pipe -march=native -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -ggdb3 -g -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include -I/ usr/include/freetype2 -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG -DHAVE_GL -DAV_INFO -DAV_INFO_TIME=3000 -DUSE_MPEG_COMPLETE - DH264_EOS_TRICKSPEED -DUSE_VDR_SPU -DUSE_OPENGLOSD -DUSE_GLX -DPLACEBO -DCUVID -DYADIF -DUSE_SCREENSAVER -DGIT_REV='"618b689"' -g -W - Wextra -c -o softhddev.o softhddev.c cc -O2 -pipe -march=native -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -ggdb3 -g -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include -I/ usr/include/freetype2 -I./opengl -I./ -DPLUGIN_NAME_I18N='"softhdcuvid"' -D_GNU_SOURCE -DDEBUG -DHAVE_GL -DAV_INFO -DAV_INFO_TIME=3000 -DUSE_MPEG_COMPLETE - DH264_EOS_TRICKSPEED -DUSE_VDR_SPU -DUSE_OPENGLOSD -DUSE_GLX -DPLACEBO -DCUVID -DYADIF -DUSE_SCREENSAVER -DGIT_REV='"618b689"' -g -W - Wextra -c -o video.o video.c In Datei, eingebunden von video.c:209: video.c: In Funktion »EglInit«: video.c:1092:14: Warnung: Format »%x« erwartet Argumenttyp »unsigned int«, aber Argument 3 hat Typ »VisualID« {alias »long unsigned int«} [-Wformat=] 1092 | Debug(3, "Chosen visual ID = 0x%x\n", vi->visualid); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~ | | | VisualID {alias long unsigned int} misc.h:107:44: Anmerkung: in Definition des Makros »Debug« 107 | #define Debug(level, fmt...) Syslog(level, fmt) | ^~~ video.c:1092:37: Anmerkung: Formatzeichenkette ist hier definiert 1092 | Debug(3, "Chosen visual ID = 0x%x\n", vi->visualid); | ~^ | | | unsigned int | %lx video.c: In Funktion »CuvidDelHwDecoder«: video.c:2154:17: Fehler: Implizite Deklaration der Funktion »cuCtxDestroy« [-Wimplicit-function-declaration] 2154 | cuCtxDestroy(decoder->cuda_ctx); | ^~~~~~~~~~~~ video.c: In Funktion »CuvidMixVideo«: video.c:4195:25: Fehler: Zuweisung an »const struct pl_hook * const*« von inkompatiblem Zeigertyp »const struct pl_hook * (*)[5]« [-Wincompatible-pointer-types] 4195 | render_params.hooks = &p->hook; | ^ video.c: In Funktion »make_osd_overlay«: video.c:4277:9: Fehler: Zuweisung an »const struct pl_fmt *« von inkompatiblem Zeigertyp »pl_fmt« {alias »const struct pl_fmt_t *«} [-Wincompatible-pointer-types] 4277 | fmt = pl_find_named_fmt(p->gpu, "rgba8"); // 8 Bit RGB | ^ video.c:4316:60: Fehler: Initialisierung von »const struct pl_fmt_t *« von inkompatiblem Zeigertyp »const struct pl_fmt *« [-Wincompatible-pointer-types] 4316 | .w = width, .h = height, .d = 0, .format = fmt, .sampleable = true, .host_writable = true, | ^~~ video.c:4316:60: Anmerkung: (nahe der Initialisierung für »(anonym).format«) video.c: In Funktion »InitPlacebo«: video.c:5705:21: Fehler: Initialisierung von »char *« von inkompatiblem Zeigertyp »char (*)[19]« [-Wincompatible-pointer-types] 5705 | char *ext[2] = {&xcbext, &surfext}; | ^ video.c:5705:21: Anmerkung: (nahe der Initialisierung für »ext[0]«) video.c:5705:30: Fehler: Initialisierung von »char *« von inkompatiblem Zeigertyp »char (*)[15]« [-Wincompatible-pointer-types] 5705 | char *ext[2] = {&xcbext, &surfext}; | ^ video.c:5705:30: Anmerkung: (nahe der Initialisierung für »ext[1]«) video.c:5712:24: Fehler: Zuweisung an »const char * const*« von inkompatiblem Zeigertyp »char * (*)[2]« [-Wincompatible-pointer-types] 5712 | iparams.extensions = &ext; | ^ make: *** [<eingebaut>: video.o] Fehler 1 -
Das Verhalten ist anders, aber aus meiner Sicht nicht unbedingt schlechter. Ich kann jetzt auf den Header des Detailfensters clicken und das Detailfensters etwas bewegen. Dann springt das Detailfenster 100% in den sichtbaren Bereich, und bleibt so stehen. Finde ich OK. Ich habe aber auch nichts gegen das alte Verhalten. Was meinen denn die Anderen?
Gut zu wissen wie das jetzt geht. An das neue Verhalten kann ich mich gewöhnen.
-
Außerdem gibt es bei Aufnahmen neben den Filter einen neuen Button, mit dem der Text im Filter gelöscht werden kann.
Cool...
Danke MarkusE , dass Du meinen Wunsch erfüllt hast!!!
-
Ich komme jetzt kurzfristig nicht zum Programmieren, d.h. es wird so einige Wochen dauern.
Kommt Zeit, kommt Rad. Ich gehe erst mal Radfahren...
Aber trotzdem Danke.
-
Warum das nicht bei jeder Aufnahme klappt, ist unklar.
Vergessen nach dem Reboot kann passieren, wenn die Datenbank nicht von /dev/shm auf die Platte gesichert wurde. Da bin ich dran ...
Ich beobachte es noch mal genauer.
Wenn das mit dem Vergessen bekannt ist, und Du dran bist, dann ist ja gut.
Vielen Dank!
-
Dieser Recording-Hook funktioniert bei mir soweit.
Bash#!/bin/bash #set -x if [ $1 == "edited" ]; then svdrpsend PLUG tvscraper SCRE $2; fiKorrektur, funktioniert doch nicht so zuverlässig.
Klappt nicht bei jeder Aufnahme und vergisst manchmal die Zuordnung nach einem Reboot... -
Dieser Recording-Hook funktioniert bei mir soweit.
Bash#!/bin/bash #set -x if [ $1 == "edited" ]; then svdrpsend PLUG tvscraper SCRE $2; fi -
Ich glaube die Daten muss man im 'Recodring_Hook' kopieren.
Danke für den Tipp. Das hatte aber schon mal ohne Hook funktioniert.
Landet dann die Aufnahme auch in der Datenbank?Aber man könnte auch das scrapen der geschnittenen Aufnahme durch den Hook starten.
-
Kann ich hier nicht reproduzieren,
Ein paar Minuten nach dem Start der Aufnahme sind die scraper Daten auch bei der Aufnahme.
Es geht nicht um neue Aufnahmen, sondern um geschnittene Aufnahmen.
-
Im git ist ein update.
Damit sind die scraper Daten für geschnittene Aufnahmen über das VDR interne Service Interface wieder sofort verfügbar.
Sollte mit live und den Skins funktionieren.
Bitte testen.
~ Markus
Hallo MarkusE .
Seit einiger Zeit habe ich das Verhalten, dass wieder keine Scraper-Daten den frisch geschnittenen Aufnahmen zur Verfügung stehen.
Man muss die geschnittene Aufnahme manuel scrapen, damit sie wieder verfügbar sind.Hast Du das Verhalten wieder geändert?
Gruß und Danke.
Heiko
-
Bitte testet das, und gebt uns hier Feedback.
Bei einem kurzen Test, konnte ich keine Fehlfunktion feststellen.
Ich lasse es mal produktiv laufen und melde, wenn mir etwas auffällt.Vielen Dank!
-
Mit PCIe 3.0 und 16 Lanes kannst du ca. 15,5 GB pro Sekunde auf die Graka schaffen. Bei 8 Bit pro Farbe und einer UHD Auflösung wird das dann schon eng.
Ob es aber nun daran liegt ist schwer zu sagen.
Ich habe hier noch mal ein wenig geforscht und hoffe, dass meine Schlussfolgerungen nicht ganz daneben liegen.
nvtop zeigt auch RX und TX auf dem PCIe Bus an (Screenshot erste Zeile).
Leider keine Kurve, da gibt es zwar ein Ticket, ist aber noch nicht implementiert.Im normalen Betrieb mit libplacebo liegt die GPU-Last bei ca. 21% und PCIe RX/TX nicht höher als 30 MiB/s.
Wird das OpenGL OSD aufgerufen wird im Verhältnis eine sehr hohe Last erzeugt:
Mit dem Befehl stress-ng --pci 8192 --pci-dev 0000:01:00.0 kann ich auf dem PCIe Bus noch etwas mehr Stress erzeugen.
Das hat aber keinen Einfluss auf das Verhalten. D.h. ich erzeuge damit nicht noch mehr Freeze.
Also ist der PCIe wahrscheinlich eher nicht der Engpass.Ich konnte allerdings einen Zusammenhang der Häufigkeit der Freeze mit der Größe des OSD feststellen.D.h. Stelle ich bei Bildausgabe von 1920x1080p die OSD-Größe auf im Plugin auf 1280x720 oder reduziere ich die OSD Größe in den VDR-Einstellungen z.B. auf 80%x80%, treten die Freeze nicht mehr bzw. nicht so häufig auf. Bin mir nicht mehr sicher, bei 80%x80% habe ich jetzt auch wieder ein Freeze gehabt...
Wegen der schlechten Augen hatte ich das OSD auf 98%x98% eingestellt.Ich denke, die Ursache für die Freeze ist das OpenGL OSD.
Das Seltsame ist, dass es nicht immer auftritt und meistens nur dann, wenn das OSD lange nicht offen war.
Der Lautstärkebalken alleine verursacht keine Freeze.Ich reduziere jetzt mal die OSD-Größe, bis es nicht mehr auftritt.
-
Und ich supporte ja auch weiterhin softhdcuvid/vaapi/drm.
Dafür bin ich sehr dankbar!
-
Doch das war lange mein Haupteinsatz auf einem Intel Quad Core. Aber der hat ca. 100 Watt verbraucht und das wurde mir dann langsam zu viel. Ausserdem kann softhdcuvid kein HDR und das wollte ich unbedingt haben.
Deswegen habe ich dann softhddrm geschrieben und dann softhdodroid. Da läuft das ganze am besten und ist derzeit mein Haupt VDR.
jojo61 Vielen Dank. Damit verstehe ich die Zusammenhänge besser und kann das Problem besser einordnen.
Für das odroid-N2 müsste ich einen kompletten Strategiewechsel machen.
Mein aktueller VDR hat die große HDD-Platte drin und soll mittels der Nvidia-Karte auch die Aufnahmen in HEVC transcodieren. -
softhhddrm ist sicher weniger resourcen belastend weil da ja schonmal kein X läuft. Ich habe hier immer nur auf meinem NUC3 getestet und der war immer schnell genug. Aber auch da ist libplacebo schon eine Herausforderung.
Da hattest Du softhdcuvid mit libplacebo gar nicht groß im Einsatz?
