Ich hatte das gestern Abend paketiert und hochgeladen: https://launchpad.net/~seahawk…shed&field.series_filter=
Wow, das war schnell! seahawk1986 Nochmal vielen Dank für Deine tolle Arbeit.
Beiträge von stegro
-
-
ok eingecheckt.
seahawk1986 Bist Du so lieb und paketierst das in Deinem jammy-vdr repo?
Das wäre super!
-
Ja teste das mal. Wenn das klappt dann baue ich das auch ein.
Hi,
ja ich kann bestätigen, dass es damit funktioniert:
i) Environment in systemd services file wieder gelöscht, so dass der Ursprungszustand wieder hergestellt ist.
ii)Code snipped in video.c in Funktion VideoInit eingefügt in Zeile 7027 nach.
if (!display_name && !(display_name = getenv("DISPLAY"))) {
// if no environment variable, use :0.0 as default display name
display_name = ":0.0";
}
......... code snipped
if (!getenv("DISPLAY")) {
//force set DISPLAY environment variable, otherwise nvidia driver
//has problems at libplace-swapchain-init
Debug(3, "video: setting ENV DISPLAY=%s\n",display_name);
setenv("DISPLAY",display_name,0);
//Debug(3, "video: ENV:(%s)\n",getenv("DISPLAY"));
}
............
Wäre cool, wenn du es eincheckst!
-
Ok dann bist du der erste dem das Problem mit der DISPLAY Variablen auffällt
Aber ich kann es nicht an placebo übergeben. Muss also vorher gesetzt werden.Du könntest mal versuchen mit -d :0.0 zu starten. Evtl. geht das.
Hi, habe ich auch gemacht, hilft nichts.
Was geholfen hat war bis jetzt nur der Eintrag im systemd services file.
Hat den Nachteil, wenn das Display sich von z.B. :0 nach :1 ändert.
Ich habe hier zufälligerweise in einem fork von Deinem repro gefunden:
https://github.com/sistlind/vd…9c876e4d10f488ccacaa791f3Soll ich das auch mal bei Dir in Zeile 7025 einfügen? Macht Sinn?
-
Soweit ich das API bisher kenne, geht das nicht. Welche libplacebo Version nutzt du denn ? Die neueren sind alle ungetestet.
Hi, ich nutze die libplacebo aus seahawk's jammy-main repository, also version 175.
-
Ich habe ein Problem/Frage zum Plugin softhdcuvid:
Ich habe festgestellt, dass libplacebo in jammy die DISPLAY Environment Variable braucht.
Dabei starte ich softhdcuvid via user vdr, der keine login shell hat, entsprechend wird keine DISPLAY variable gesetzt.
(Dann als normaler user im Desktop: xhost+ und mit softhdcuvid plug softhdcuvid atta die Bildausgabe).
Ich musste im systemd services file des vdr die Display Variable setzen mit Environment="DISPLAY=:0.0"
Ansonsten crashed libplacebo!
Check:
Wenn ich das plugin ohne libplacebo übersetze brauche ich die Variable nicht.
Wenn ich vdr mit --user <mein desktop user> laufen lasse auch nicht.
Nur wenn ich vdr mit --user=vdr laufen lassen brauche ich die DISPLAY Variable.
jojo61 Gibt es eine Möglichkeit im plugin die DISPLAY variable an libplacebo zu übergeben?
Immerhin öffnet das Plugin ja schon mal kurz ein Fenster bevor es chrashed, sollte also wissen wo das Display ist.
Das wäre gut, dann müsste man nicht die DISPLAY variable im systemd services File hard reinkodieren.
-
Versuch mal in der /etc/vdr/conf.d/50-softhdcuvid das -D rauszunehmen - das Problem ist, dass Skins, die Pixmaps nutzen, crashen, weil softhdcuvid im Gegensatz zu softhddevice-cuvid keine Dummy-Implementierung hat, wenn das Frontend detached ist.
Danke seahawk1986 !
Habe ich gemacht. Kein Unterschied.
Ich nutze ja Deine Pakete auf ein ubuntu desktop drüber installiert.
Ich habe jetzt folgende Situation:
Lasse ich vdr als user vdr laufen via systemd und mache (nach einem xhost +) dann als normaler desktop user "svdrpsend plug softhdcuvid atta"
flackert der Rahmen des video Fensters kurz auf, dann crasht es.
Starte ich den vdr aus dem Terminal als normaler desktop user und dann attache ich wieder softhdcuvid funktioniert alles.
Es ist also offensichtlich ein permission problem. Es beißt sich wohl mit meiner X session von ubuntu desktop?
Vermutlich tritt das nicht auf, wenn ich das via ansible playbook mache und als Basis ubuntu server nehme?
Update (sorry):
Kompiliere ich softhdcuvid ohne libplacebo funktioniert es auch.
Es schein also ein libplacebo permission problem zu sein.
Nutze ich das Plugin softhddevie-cuvid habe ich das Problem nicht. (Macht Sinn, wenn es ein placebo Thema ist).
Die Frage ist für mich:
Wie unterscheiden sich die beiden Plugins ?
jojo Hast Du vielleicht eine Idee?
Ich würde gerne Deine Variante weiter nutzen.
-
Hi, jetzt habe ich doch noch ein kleines Problem gefunden:
Installiere ich von seahaw vdr-plugin-softhddevice-cuvid funktioniert es.
Purge ich das und installiere anstelle dessen vdr-plugin-softhdcuvid bekomme ich kein Bild. (pop kurz hoch und verschwindet sofort)
Ich habe das plugin und auch libplacebo auch aus dem jammy repo installiert.
Ich bekomme keinerlei Fehlermeldung im syslog
Als Basis hatte ich nvidia-driver-510 von jammy installiert.
-
Bin erstmal auch ganz happy. Nutze aber Kodi nicht.
Habe ein Vanilla Jammy mit Seahawks Paketen aufgesetzt.
HW: ist noch eine Haswel Kiste. Musste die Auflösung auf HD runterschalten, sonst gibt es Aussetzer.
Nutze seit dem upgrade das softhhdvaapi device. Das läuft auch gut.
"Eigentlich" wollte ich eine alte GT1030 gleich einbauen, warte aber, bis Arte et. al. mal UHD senden.
Eine gute Gelegenheit seahawk1986 "Danke zu sagen" für seine tollen Pakete!
Ach ja: in /etc/group vdr in render eintragen
-
Hi, das sieht sehr gut aus!
Ich denke, dass kannst Du einfach in Deiner Source einchecken.
Ich habe im Syslog auch nichtsmehr verdächtiges finden können. Die Audio Delays (ohne placebo, analog Intel HW) sind jetzt auch verschwunden.Herzlichen Dank für Deinen Einsatz und Deine Geduld mit mir!
Vielleicht macht das ja die AMD Ryzen Platform (5650G z.B.) attraktiver für den VDR.
-
ok, habe ich gemacht. Ich habe dazu nochmal aus Deinem Repository das original ausgecheckt.
Das habe ich zu bieten (ich habe dann einmal weitergemacht, um einen zweiten Wert zubekommen.)
-
Habe ich probiert.
leider bekomme ich die zweite Ebene nicht gebacken:
Dec 3 19:09:32 amd vdr[12101]: vor create Object 0 with fd 39 import size 921600 offset 0 1280x720
Dec 3 19:09:32 amd vdr[12101]: vor create Object 1 with fd 41 import size 230400 offset 921600 640x360
Der erste Aufruf geht noch gut, der zweite bringt den bekannten Fehler:
Dec 3 19:09:34 amd vdr[12101]: error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2170)
ist da was mit memory tiling los?
ich checke es leider nicht.
Ich habe mal das selfcompiling example laufen lassen, das ging ohne probleme
Dort wird auch in der zweiten Ebene einfach durch 4 geteilt.
Bin etwas ratlos? Was kann ich noch tun, um das einzukreisen?
-
jojo61 Ich habe mir die mesa source für "nicht intel" angeschaut:
https://github.com/mesa3d/mesa…um/frontends/va/surface.c
Wenn ich das richtig verstanden habe wird dort size=0 gesetzt.
gibt es eine andere Möglichkeit die size zu ermitteln (height * width * 4 funktioniert wohl eher nicht)?
VG Stefan
-
Ok, ich schaue mir desc mal genauer an, melde mich.
-
Da ist mir wohl eine Änderung der libplacebo durch die Lappen gegangen. Die Zeile 2170 stimt wohl im aktuellen commit der Lib nicht mehr. Hast du placebo selber übersetzt ? Dann poste doch bitte mal die stelle um die Zeile 2170 um zu sehen was ihm da fehlt. Ist wohl nur ein Feld was noch zu füllen ist. Mangels AMD Karte kann ich hier wenig testen.
Noe, ich habe die Version von Seahawk genommen.
dpkg -l | grep placebo"*"
ii libplacebo-dev:amd64 7:4.175.0+git20211113-146-72cd260-1yavdr0~focal amd64 GPU-accelerated video/image rendering primitives (development files)
ii libplacebo175:amd64 7:4.175.0+git20211113-146-72cd260-1yavdr0~focal amd64 GPU-accelerated video/image rendering primitives (shared library)
Ich habe jetzt apt-get source gemacht. In der Datei steht:
// Rendering to/from a frame with no planes is technically allowed, but so
// pointless that it's more likely to be a user error worth catching.
require(image->num_planes > 0 && image->num_planes <= PL_MAX_PLANES);
require(target->num_planes > 0 && target->num_planes <= PL_MAX_PLANES);
for (int i = 0; i < image->num_planes; i++)
validate_plane(image->planes[i], sampleable);
Das ist die Definition:
#define validate_plane(plane, param) \
do { \
require((plane).texture); \
require((plane).texture->params.param); \
require((plane).components > 0 && (plane).components <= 4); \
for (int c = 0; c < (plane).components; c++) { \
require((plane).component_mapping[c] >= PL_CHANNEL_NONE && \
(plane).component_mapping[c] <= PL_CHANNEL_A); \
} \
} while (0)
Update:
Vermutlich ist bei der Übergabe was schiefgelaufen?
jojo61: Ich habe das Plugin mal auf einem computer mit Intel Graphik übersetzt und das printf Statement wieder aktiviert.
Auffällig ist, dass size hier einen vernünftigen Wert hat:
Nov 30 12:40:35 multi-lin vdr[4401]: vor create Object 0 with fd 16 import size 1433600 offset 0 1280x720
Nov 30 12:40:35 multi-lin vdr[4401]: vor create Object 0 with fd 16 import size 1433600 offset 942080 640x360
-
Hi, das habe ich gemacht (sorry für die edits).
Nach:
decoder->pl_frames[index].planes[n].texture = pl_tex_create(p->gpu, &tex_params);
das eingesetzt:
for (int n = 0; n < Planes; n++)
close(desc.objects[n].fd);
"Fehler beim export VAAPI Handle" ist jetz weg.
Das ist ja schon mal super!
Nov 29 15:16:02 amd vdr[10156]: vor create Object 0 with fd 14 import size 0 offset 0 1280x720
Nov 29 15:16:02 amd vdr[10156]: vor create Object 1 with fd 42 import size 0 offset 921600 640x360
d.h. fd wird nicht mehr hochgezählt.
Warum ist eigentlich size immer 0?
Es bleibt der Placebo Fehler bei:decoder->pl_frames[index].planes[n].texture = pl_tex_create(p->gpu, &tex_params);
-
Hi jojo61 gab leider keine Besserung.
Ich habe mal das printf statement wieder aktiv gesetzt. Evtl hilft das beim Fehler finden.
Dabei habe im syslog gesehen, dass fd immer hochgezählt wird.
Import size und offset ist immer 0
-
Hallo allerseits,
ich habe jetzt versucht, softhdrm auch unter X zum laufen zu bringen. (als softhdvaapi natürlich).
Mein System ist ein AMD Ryzen 5650GE (mit AMD Renoir GPU).
5.15 Kernel und die mesa treiber von oibaf
Ich habe dazu libplacebo175 von Seahawk installiert.
im Makefile von softhddrm habe ich:
VAAPI=1
LIBPLACEBO=1
Leider bekomme ich jetzt folgende Fehlermeldungen wenn ich das Plugin innerhalb einer X Session starte:
vdr[9365]: Fehler beim export VAAPI Handle
vdr[9365]: error: Validation failed: (image->planes[i]).texture (../src/renderer.c:2170)
vdr[9365]: error: #0 /lib/x86_64-linux-gnu/libplacebo.so.175(+0x3dda1) [0x7fcb493c1da1
vdr[9365]: error: #1 /lib/x86_64-linux-gnu/libplacebo.so.175(+0x407f9) [0x7fcb493c47f9]
vdr[9365]: error: #2 /lib/x86_64-linux-gnu/libplacebo.so.175(pl_render_image+0xa0) [0x7fcb493caf80]
vdr[9365]: error: #3 /usr/lib/vdr/plugins/libvdr-softhdvaapi.so.2.5.6(+0x2f25b) [0x7fcb497af25b]
vdr[9365]: error: #4 /usr/lib/vdr/plugins/libvdr-softhdvaapi.so.2.5.6(+0x3611f) [0x7fcb497b611f]
vdr[9365]: error: #5 /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7fcb4aff5609]
vdr[9365]: error: #6 /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7fcb4aa0a293]
jojo61 Der Fehler schein mir ähnlich zu sein, wie in der DRM Variante. Hast Du eine Idee, ob man das auch fixen könnte?
Das wäre super, da ich meine Kiste schon gerne mit X betreiben möchte.
-
jojo61 habe ich gemacht. Es sieht super aus.
Das bekomme ich als Output, nachdem ich den vdr von der command line gestartet habe:
-
jojo61 Habe ich gemacht. Leider keine Änderung.
Schicke mir die Testversion, ich debugge gerne!
Update:
Sorry, dass ich nochmal dilettiere:
Ich habe mir Deinen Code angeschaut Deinen Hinweis gesehen, dass Du eventuell den Handle nicht richtig zurückgeben hast.
Ich habe dann Dein Close statement vor dem return eingefügt, sorry reine Experimental Informatik.
decoder->fds[index * Planes] = desc.objects[0].fd;
glBindTexture(GL_TEXTURE_2D, 0);
eglMakeCurrent(eglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
EglCheck();
for (int n = 0; n < Planes; n++)
close(desc.objects[n].fd);
return;
Aber das Problem ist erst einmal weg! Ich bekomme den Fehler nicht mehr und das Bild ruckelt auch nicht.
Macht das Sinn?
