Nachdem ich media-libs/glm installieren musste, bekomme ich die Meldung:
openglosd.o:/usr/local/vdr/vdr-2.4.0/PLUGINS/src/softhdcuvid-180905/codec.h:50: multiple definition of `hw_device_ctx'
softhdcuvid.o:/usr/local/vdr/vdr-2.4.0/PLUGINS/src/softhdcuvid-180905/codec.h:50: first defined heredie Grab Funktion muss ich noch ausbauen. Da direkt auf der Karte gerendert wird kann man nichts mehr graben.
Wenn ich den vdr mit vdr-plugin-vdrboblight oder vdr-plugin-seduatmo starte dann kracht er sofort, könnte mir vorstellen das die Schnittstelle auf die hier aufgesetzt wird in Richtung des grab geht.
Was mit auch aufgefallen ist das wenn ich die osd Größe fest auf 1920 stelle ich nur noch ein weißes osd bekomme (trotz vorhandener 1920er Auflösung)
Ansonsten sehr schick auf der gt630 hier, weiter so!
Christian
Edit:
Bzw kann das auch an seduatmo oder vdrboblight liegen das die unbedingt das softhddev suchen und nicht finden?
Scheint ja so langsam eine Alternative zu vdpau oder vaapi zu werden. Plane mir evtl auch eine GTX 1050 TI zu kaufen.
Nur wie macht ihr das denn wenn die grab-Funktion aus dem neuen Plugin rausfliegt?
Wie bekommt ihr dann Euer Ambilight zum laufen? Mit hyperion und externen Grabber?
ich hoffe ja man findet noch eine Lösung für das grab, ansonsten wird die UHD Zukunft wohl eine ohne Ambilight 
Ich muss mein Statement von oben erweitern bzw. korrigieren:
vdr-plugin-vdrboblight => vdr startet nicht ohne softhddevice
vdr-plugin-seduatmo => vdr funktioniert normal, macht halt kein Ambilight
Christian
Ich will noch einen scalierungsshader einbauen. Dann muss ich eh davor in ein FBO rendern. Dann könnte ich auch mal schauen ob ich daraus dann grabe.
Das wird aber noch etwas dauern. Ich mach erstmal Urlaub 
PS: die fehlende Datei ist nun auch eingecheckt.
mfg
jojo61
PS: da ich das plugin umbenannt habe werden die atmo sachen es wohl nicht finden. Was ja auch nicht schlimm ist weil graben eh (noch) nicht geht.
hyperion-x11 grabber müsste hier doch auch gehen. Bei VDPAU hat das nicht funktioniert wegen der Art der Ausgabe, aber mit cuvid sollte es eigentlich kein problem sein.
Naja die vdr Plugins sind da ziemlich in die softhddev Schnittstelle reinentwickelt damit das runterrechnen der Farben auf der NVIDIA Hardware geschieht und das ganze extrem Performant wird. Johns und horchi haben da lang dran gebastelt.
Beim softhddev wird vom sedzatmo zb quasi ein Bild in der Geometrie der verbauten led angefragt, also wenn du oben 16 und an der Seite 9 led hast kommt da ein fertiges 16x9 Foto raus wo du direkt jedes Pixel einer led zuweisen kannst. Dadurch ist einmal die Datenmenge extrem klein und die Grafikkarte kann Farben sicher besser mischen als das Plugin.
Bei hyperion schätze ich aber das smoothing sehr. Damit gibt es sehr weiche Übergänge ohne Flackern. Das grabben geschieht bei hyperion-x11 über die xRender extension was auch sehr performant ist und mit einem entsprechenden Dezimierungsfaktor ist 4K@50fps beim grabben kein Problem.
Ich hatte mal das vdr-boblight plugin laufen mit softhddevice und war nicht wirklich begesitert von dem Ergebnis. Aktuell nutze ich deswegen meist Kodi als Frontend und hyperion-x11. Einfach mal probieren. Es muss aber hyperion.ng sein.
EDIT: Falls es jemand testen möchte, diese beiden patches müssen noch rein
ZitatWenn UHD ruckelt liegt das sicher nicht an der HDMI anbindung, Schau mal mit top welche Last am Rechner ist. Wenn die GrKa mit einem Mining Modul angebunden ist dann ist da auch nur ein PCIe Kanal aktiv. Das ist zu wenig für UHD. Da brauchst du schon 4 Kanäle und volle PCIe Bandbreite.
Hallo Jojo,
das Mininig-Modul ist rausgeflogen und die Karte steckt in enem x16-Slot. Die Prozessorlast liegt bei ~5-20% pro Kern. Kann es sein, dass ein Athlon64 6000+ mit zwei Kernen trotz Hardware-Beschleunigung nicht reicht?
Cu
biggsmann
Compiliert jetzt
Der aktuelle Git-Stand funktioniert bei mir leider nicht - wenn ich das Plugin unverändert baue, bekomme ich eine Meldung beim Start des VDR, dass das Symbol hw_device_ctx nicht definiert ist.
Sep 07 11:00:59 yavdr07 vdr[27818]: vdr: /usr/lib/vdr/plugins/libvdr-softhdcuvid.so.2.4.0: undefined symbol: hw_device_ctxIch sehe dafür nur eine Deklaration in https://github.com/jojo61/vdr-…d/blob/master/codec.h#L50 und in libavcodec/avcodec.h von ffmpeg 3.4 scheint die eigentliche Definition zu stecken (AVBufferRef *hw_device_ctx;), die er aber ignoriert.
Wenn ich in https://github.com/jojo61/vdr-…blob/master/video.c#L2243 AVBufferRef als Typ des Pointers angebe (also AVBufferRef *hw_device_ctx = NULL; schreibe), ist das Problem mit dem fehlenden Symbol weg, dafür habe ich im Log dann Warnungen von xcb und einen Segfault:
Sep 07 11:45:34 yavdr07 vdr[1005]: [1005] [softhddev]SetPlayMode: 1
Sep 07 11:45:34 yavdr07 vdr[1005]: [1005] OSD size changed to 1920x1080 @ 1
Sep 07 11:45:34 yavdr07 vdr[1005]: [1005] [softhddev]CreateOsd: left 0, top 708, level 0, using OpenGL OSD support
Sep 07 11:45:34 yavdr07 vdr[1005]: [1005] [softhddev]Trying to start OpenGL Worker Thread
Sep 07 11:45:34 yavdr07 vdr[1005]: [1240] oglThread thread started (pid=1005, tid=1240, prio=high)
Sep 07 11:45:34 yavdr07 vdr[1005]: [xcb] Unknown request in queue while dequeuing
Sep 07 11:45:34 yavdr07 vdr[1005]: [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
Sep 07 11:45:34 yavdr07 vdr[1005]: [xcb] Aborting, sorry about that.
Sep 07 11:45:34 yavdr07 vdr[1005]: vdr: ../../src/xcb_io.c:165: dequeue_pending_request: Zusicherung »!xcb_xlib_unknown_req_in_deq« nicht erfüllt.
Sep 07 11:45:34 yavdr07 systemd[1]: vdr.service: Main process exited, code=killed, status=6/ABRT
Sep 07 11:45:34 yavdr07 systemd[1]: vdr.service: Failed with result 'signal'.Wenn ich den VDR mit der Umgebungsvariablen __GL_THREADED_OPTIMIZATIONS=0 starte, ist der SIGABRT von xcb beim Start weg. Dafür ist das Video dann aber gestaucht, während das OSD normal gezeichnet wird und mit dem Skindesigner geht überhaupt nichts mehr.
Bei mir die gleiche Meldung.
Hallo jojo 61,
den 396.24 habe ich jetzt auch (vorher .37 wenn ich nicht irre). Leider keine Änderung. In meiner Verzweiflung habe ich ffmeg mal ohne den Patch übersetzt, ändert leider nichts am Problem. Gibt es irgendwo noch eine Einstellung zum Deinterlacing? Hintergrund meiner Frage ist, dass der Astra-Demo-Kanal sich aller paar Sekunden "fängt", dann ein paar Sekunden vernünftig läuft und dann wieder diese komischen Ruckler produziert. In Log erscheint dann
Sep 7 17:12:18 uvid vdr: get uniform colormatrix 1
Sep 7 17:12:18 uvid vdr: get uniform colormatrix_c 2 -0,915688
Hilft das?
cu
biggsmann
Ich frage mich nur warum es bei mir einwandfrei läuft.
Mit welcher Optimierungsstufe baust du den VDR und die Plugins? Welcher Compiler (in welcher Version) kommt bei dir zum Einsatz? Da scheint sich ja schon der Linker anders zu verhalten.
seahawk1986 compiliere mal ohne das openglosd. Dazu den Define im Makefile (-DOPENGLOSD) auskommentieren. Das Openglosd macht noch einen GL thread und da scheint es Probleme zu geben. Ich frage mich nur warum es bei mir einwandfrei läuft.
Damit allein baut das Plugin nicht, weil das openglosd.o weiterhin in den OBJS steht - wenn ich diese Änderungen mache baut es:
diff --git a/Makefile b/Makefile
index 447b838..4777b45 100644
--- a/Makefile
+++ b/Makefile
@@ -107,7 +107,7 @@ ifeq ($(OPENGL),1)
CONFIG += -DUSE_GLX
_CFLAGS += $(shell pkg-config --cflags gl glu glew)
LIBS += $(shell pkg-config --libs gl glu glew)
-CONFIG += -DUSE_OPENGLOSD
+#CONFIG += -DUSE_OPENGLOSD
_CFLAGS += $(shell pkg-config --cflags glew)
LIBS += $(shell pkg-config --libs glew)
_CFLAGS += $(shell pkg-config --cflags freetype2)
@@ -202,7 +202,7 @@ override CFLAGS += $(_CFLAGS) $(DEFINES) $(INCLUDES) \
### The object files (add further files here):
-OBJS = $(PLUGIN).o softhddev.o video.o audio.o codec.o ringbuffer.o openglosd.o
+OBJS = $(PLUGIN).o softhddev.o video.o audio.o codec.o ringbuffer.o #openglosd.o
SRCS = $(wildcard $(OBJS:.o=.c)) $(PLUGIN).cpp
diff --git a/video.c b/video.c
index db251c2..cea16a7 100644
--- a/video.c
+++ b/video.c
@@ -2240,7 +2240,7 @@ static int init_cuvid(AVCodecContext *avctx,CuvidDecoder * decoder)
AVCUDADeviceContext *device_hwctx;
CUcontext dummy;
- hw_device_ctx = NULL;
+ AVBufferRef *hw_device_ctx = NULL;
hw_device_ctx = av_hwdevice_ctx_alloc(AV_HWDEVICE_TYPE_CUDA);
if (!hw_device_ctx)Das Videobild ist in der Höhe ca. auf die Hälfte gestaucht und zentriert (wie in diesem Post beschrieben), während das OSD Bildschirmfüllend gerendert wird.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!