jojo: ich könnte mir vorstellen, dass es Probleme macht, dass du aus zwei Threads parallel auf den OpenGL Kontext zugreifst. Du hattest das "ActivateOsd" ja wohl schon mal in cOglCmdCopyBufferToOutputFb drinn. Dadurch würde die Ausgabe des OSD vom Osd Thread erledigt. Vielleicht wäre das besser...du hattest aber wohl sicherlich deine Gründe, warum du es anders herum machst
softhdcuvid/softhdvaapi/softhddrm with hevc and UHD
-
-
louis Der OSD Thread kann die Ausgabe nicht selber machen, das wäre sonst nicht mit dem Bild sysnconisiert. Ich schalte den Kontext immer schön brav um. Es ist auch zulässig aus 2 Threads auf das selbe Texture zuzugreifen. Aber vtl. muss ich noch eine semaphore dazwischen legen. Nur scheint es ja etwas grundsätzliches schief zu gehen bei den anderen.
Ich werde mir das ganze nun mal mit ffmpeg 3.4 ansehen. Evtl. ist da doch was andres.
mfg
jojo61
-
Ich benutze ffmpeg 3.3.8
-
Das das Bild nur die halbe höhe hat das liegt sicher nicht an FFMPEG. In der Funktion VideoUpdateOutput scheint mir noch ein BUG zu sein. Nur habe ich den bisher nicht richtig gefunden. Ich habe noch was verändert und mal einen Debug print eingebaut der ins Syslog schreibt welches Fenster er für das Video aufziehen will. Das sollte der Fernstergrösse entsprechen. Wenn das nicht so ist dann hat er sich verrechnet.
Ausserdem habe ich das Makefile angepasst so das man nun OPENGLOSD auskommentieren kann (ganz am Anfang). Ich konnte mit ffmpeg 3.4 alles kompilieren. Laufen lassen kann ich das nicht so ohne weiteres ohne mir die ganzen avlibs hier auf dem Rechner zu zerschiessen. Das mit den verschiedenen Versionen der FFMPEG libraries ist echt ne Kacke. Da ist nix abwärtskompatibel
Zu deb xcb Problemen hier noch meine derzeitigen Versionen: lib-xcb-iccm.so.4.0.0 und lib-xcb.so.1.1.0.
An den Standard Compileoptionen vom vdr habe ich nichts geändert. Warum das mit dem abschalten von OPENGLOSD funktionierte lag daran das bei mir das objektfile nicht gelöscht wurde und somit einfach dazugelinkt wurde. Das Makefile sollte das nun korrigiert haben.
mfg
jojo61
-
Mit der aktuellen Git-Version bekomme ich mit jetzt wieder ein Videobild mit voller Höhe.
Was mir gerade aufgefallen ist, weil sich der Fenstertitel mit der neuen Version von softhddevice auf softhdcuvid geändert hat:
Ich hatte eine Regel für Openbox, die für softhddevice die Fensterdekoration entfernt und das Fenster maximiert - wenn die Regel nicht mehr greift, startet das Plugin ohne Probleme, aber sobald ich die Fensterdekoration durch Openbox in der rc.xml mit so einer RegelCode<application title="softhdcuvid"> <decor>no</decor> <maximized>yes</maximized> <skip_taskbar>no</skip_taskbar> </application>
entfernen und das Fenster maximieren lasse, tritt der Fehler mit xcb wieder auf (die Bibliotheken für xcb haben unter Ubuntu nebenbei bemerkt die selben Versionsnummern wie auf deinem System):
CodeSep 08 20:17:13 yavdr07 vdr[1019]: video: fatal i/o error Sep 08 20:17:13 yavdr07 vdr[1019]: [xcb] Unknown request in queue while dequeuing Sep 08 20:17:13 yavdr07 vdr[1019]: [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called Sep 08 20:17:13 yavdr07 vdr[1019]: [xcb] Aborting, sorry about that. Sep 08 20:17:13 yavdr07 vdr[1019]: vdr: ../../src/xcb_io.c:165: dequeue_pending_request: Zusicherung »!xcb_xlib_unknown_req_in_deq« nic Sep 08 20:17:14 yavdr07 systemd[1]: vdr.service: Main process exited, code=killed, status=6/ABRT
Wenn ich das Plugin stattdessen mit -f im Vollbild starten lasse, scheint der Fehler beim Start nicht aufzutreten.
Mit dem Skindesigner ist die OSD-Darstellung unvollständig - es sieht so aus, als würde er den Hintergrund nicht rendern und ab und an gibt es ein schwarz blinkendes OSD (scheint bevorzugt zu passieren, wenn er Dinge neu zeichnet).
Beim Detachen crasht er weiterhin.
-
Das hilft mir weiter. So wie es aussieht schickt X11 wenn es den Rand entfernt eine Nachricht über xcb die ich nicht verstehe oder die nicht supported ist.
Da schau ich mir mal an. Brauchst du das denn unbedingt und warum startest du nicht mit -f ?
Der Skindesigner bzw. das openglosd schreibt unsyncronisiert in das texture das ich als OSD anzeige. Das muss ich noch verriegeln. Mir ist aber auch aufgefallen das die Skins teilweise grau in grau sind und ich den Eindruck habe das die Farben nicht stimme. Bei der runden Uhr sind die Zeiger kaum zu sehen.
mfg
jojo61
PS das detachen verstehe ich immer noch nicht. Kannst du das mal mit gdb debuggen und nen Backtrace posten
-
-
Ich hab gerade mal die aktuelle Version installiert, schaut auf den ersten Blick gut aus.
Bleiben disconnect und grab.
-
Brauchst du das denn unbedingt und warum startest du nicht mit -f ?
Grundsätzlich brauche ich einen Weg, um das Plugin mit detachtem Frontend starten zu können, damit der startende VDR keine Abhängigkeit zu einem laufenden X-Server hat und das Frontend nicht ungewollt dargestellt wird, wenn es bereits andere laufende Programme wie z.B. KODI gibt. Und wenn ich es attache, sollte es keine Fensterdekoration haben.
Zur Frage, warum das Fenster maximiert lauft: Bei yaVDR gab es bislang ein Dock (wmDrawer), das man per Mouse-Over am linken Bildschirmrand erreichen konnte. Das klappt nur, wenn das Fenster nicht im Vollbild läuft. Außerdem gibt es Spezialfälle wie bei CKone, der eine PIP-Funktionalität mit zwei parallel laufenden VDR-Instanzen nutzt und dann die beiden Fenster auf dem Bildschirm nebeneinander oder leicht überlappend anordnen können will.
Mit dem Commit 9a14e74 bekomme ich ohne Fensterregel und wenn ich das Plugin mit -f starte ab und an beim Start oder beim dem ersten Kanalwechsel ein schwarzes Bild, teilweise läuft es auch normal. Ich schaue mal, ob ich da ein Muster finde.
PS das detachen verstehe ich immer noch nicht. Kannst du das mal mit gdb debuggen und nen Backtrace posten
Der Backtrace davon sieht so aus: detach_crash.txt
-
Wenn der VDR beim ersten Kanalwechsel hängt und entweder kein Bild oder ein eingefrorenes Bild des aktuellen Kanals anzeigt, sieht das in Log und mit gdb so aus:
- Syslog: start_freeze_after_channel_change.txt
- gdb Backtrace: start_freeze_after_channel_change.bt.txt
-
SD Anzeige ist jetzt horizontal gestaucht (4:3), ich meine, das wär schon besser gewesen.
Bei Dir scheint streamdev im Spiel zu sein, wenn ich das bei mir aktiviere, habe ich auch stockende Bilder beim Umschalten.
-
Ich bin nochmal zurück auf die Version vom 1.9. (softhdcuvid v0.6.1rc1-GITcbdc46e), da ist SD noch OK.
-
Wenn der VDR beim ersten Kanalwechsel hängt und entweder kein Bild oder ein eingefrorenes Bild des aktuellen Kanals anzeigt, sieht das in Log und mit gdb so aus:
- Syslog: start_freeze_after_channel_change.txt
- gdb Backtrace: start_freeze_after_channel_change.bt.txt
Laut deinem Log wird der Osd Thread bei dir direkt nach dem Starten aus irgendwelchen Gründen wieder gestoppt. Wird dann das OSD angefordert, gibts einen Deadlock. Der würde aber nicht passieren, wenn der Osd Thread laufen würde...
-
jsffm stelle mal auf pan&scan in dem Setup für 16:9
Beim detach hat einer der oglThreads einen SEGFAULT . Mit gdb ist aber nicht herauszubekommen welcher das ist. Da laufen einfach zuviele.
Das sieht bei mir dann so aus:
Code
Alles anzeigen[New Thread 0x7fffb632b700 (LWP 18273)] [New Thread 0x7fffb5b2a700 (LWP 18274)] [New Thread 0x7fffb5329700 (LWP 18275)] [New Thread 0x7fffa3fff700 (LWP 18278)] [New Thread 0x7fffa37fe700 (LWP 18279)] [New Thread 0x7fffa2ffd700 (LWP 18280)] [New Thread 0x7fffa27fc700 (LWP 18281)] [New Thread 0x7fffa1ffb700 (LWP 18282)] ratio: 16:9 6536:3609 hier kommt der detach [Thread 0x7fffc7fff700 (LWP 18250) exited] [Thread 0x7fffb632b700 (LWP 18273) exited] [Thread 0x7fffb5b2a700 (LWP 18274) exited] [Thread 0x7fffc4d11700 (LWP 18272) exited] [Thread 0x7fffa2ffd700 (LWP 18280) exited] [Thread 0x7fffa37fe700 (LWP 18279) exited] Thread 31 "oglThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb5329700 (LWP 18275)] 0x00007ffff12eba7d in xcb_writev () from /usr/lib64/libxcb.so.1 Missing separate debuginfos, use: zypper install fontconfig-debuginfo-2.11.1-4.3.x86_64 glibc-locale-debuginfo-2.22-19.1.x86_64 krb5-debuginfo-1.12.5-16.1.x86_64 libGLEW1_13-debuginfo-1.13.0-4.4.x86_64 libGLU1-debuginfo-9.0.0-18.4.x86_64 libX11-6-debuginfo-1.6.3-10.3.1.x86_64 libX11-xcb1-debuginfo-1.6.3-10.3.1.x86_64 libXau6-debuginfo-1.0.8-9.3.x86_64 libXext6-debuginfo-1.3.3-6.3.x86_64 libXfixes3-debuginfo-5.0.1-10.3.x86_64 libXrender1-debuginfo-0.9.9-6.3.x86_64 libasound2-debuginfo-1.1.4.1-1.1.x86_64 libbz2-1-debuginfo-1.0.6-34.15.x86_64 libcairo2-debuginfo-1.15.2-8.3.1.x86_64 libcap2-debuginfo-2.22-18.16.x86_64 libcom_err2-debuginfo-1.42.11-15.1.x86_64 libcroco-0_6-3-debuginfo-0.6.11-4.3.x86_64 libcurl4-debuginfo-7.37.0-36.1.x86_64 libdatrie1-debuginfo-0.2.4-22.3.x86_64 libdrm2-debuginfo-2.4.76-1.2.x86_64 libexpat1-debuginfo-2.1.0-24.1.x86_64 libffi4-debuginfo-5.3.1+r233831-10.1.x86_64 libfreetype6-debuginfo-2.6.3-5.3.1.x86_64 libgcc_s1-debuginfo-7.3.1+r258812-10.1.x86_64 libgdk_pixbuf-2_0-0-debuginfo-2.34.0-19.1.x86_64 libgio-2_0-0-debuginfo-2.48.2-3.4.x86_64 libglib-2_0-0-debuginfo-2.48.2-3.4.x86_64 libgmodule-2_0-0-debuginfo-2.48.2-3.4.x86_64 libgobject-2_0-0-debuginfo-2.48.2-3.4.x86_64 libgraphite2-3-debuginfo-1.3.1-7.3.1.x86_64 libharfbuzz0-debuginfo-1.4.5-6.1.x86_64 libidn11-debuginfo-1.28-9.3.1.x86_64 libjpeg8-debuginfo-8.1.2-42.1.x86_64 libkeyutils1-debuginfo-1.5.9-7.13.x86_64 libldap-2_4-2-debuginfo-2.4.44-18.1.x86_64 liblzma5-debuginfo-5.2.2-3.15.x86_64 libopenssl1_0_0-debuginfo-1.0.2j-25.1.x86_64 libpango-1_0-0-debuginfo-1.40.1-3.4.x86_64 libpcre1-debuginfo-8.39-11.1.x86_64 libpixman-1-0-debuginfo-0.34.0-4.3.x86_64 libpng16-16-debuginfo-1.6.8-11.3.x86_64 librsvg-2-2-debuginfo-2.40.20-15.1.x86_64 libsasl2-3-debuginfo-2.1.26-14.1.x86_64 libselinux1-debuginfo-2.5-4.17.x86_64 libssh2-1-debuginfo-1.4.3-18.3.x86_64 libstdc++6-debuginfo-7.3.1+r258812-10.1.x86_64 libthai0-debuginfo-0.1.25-3.3.x86_64 libva-drm1-debuginfo-1.7.3-1.3.x86_64 libva-x11-1-debuginfo-1.7.3-1.3.x86_64 libva1-debuginfo-1.7.3-1.3.x86_64 libvdpau1-debuginfo-1.1.1-11.3.x86_64 libxcb-icccm4-debuginfo-0.4.1-6.3.x86_64 libxcb-render0-debuginfo-1.11.1-9.1.x86_64 libxcb-shm0-debuginfo-1.11.1-9.1.x86_64 libxcb1-debuginfo-1.11.1-9.1.x86_64 libxml2-2-debuginfo-2.9.4-15.1.x86_64 libz1-debuginfo-1.2.8-14.3.1.x86_64 (gdb) bt #0 0x00007ffff12eba7d in xcb_writev () at /usr/lib64/libxcb.so.1 #1 0x00007ffff1749b76 in _XSend () at /usr/lib64/libX11.so.6 #2 0x00007ffff1740516 in XQueryExtension () at /usr/lib64/libX11.so.6 #3 0x00007ffff17347d2 in XInitExtension () at /usr/lib64/libX11.so.6 #4 0x00007fffee72afbf in XextAddDisplay () at /usr/lib64/libXext.so.6 #5 0x00007fffc547dfca in () at /usr/lib64/libGLX_nvidia.so.0 #6 0x00007fffc547ee9b in () at /usr/lib64/libGLX_nvidia.so.0 #7 0x00007fffc5484b09 in () at /usr/lib64/libGLX_nvidia.so.0 #8 0x00007ffff795c4e2 in __nptl_deallocate_tsd () at /lib64/libpthread.so.0 #9 0x00007ffff795c737 in start_thread () at /lib64/libpthread.so.0 #10 0x00007ffff6313e8d in clone () at /lib64/libc.so.6
-
Das ist keine Lösung, da dann 4:3 Sendungen falsch wiedergegeben werden.
-
Die SD Sender werden in 4:3 gesendet (720:576 ). Ich wüsste nicht wie ich da erkennen kann ob es eine 4:3 Sendung oder 16:9 sendung ist,
Kann mir da jemand weiterhelfen ? Ich denke pan&scan ist da die richtige einstellung.
mfg
jojo61
-
So habe noch etwas eingecheckt um den crash beim detach zu unterbinden. Hoffentlich hilf es.
mfg
jojo61
-
Gleiche Meldung wie vorher beim detach
-
So habe noch etwas eingecheckt um den crash beim detach zu unterbinden. Hoffentlich hilf es.
Wenn ich ohne OPENGLOSD baue, klappt jetzt das detachen. Beim erneuten Attachen habe ich dann erst mal kein Videobild, sondern einen Farbverlauf von Schwarz nach Rot und Ton, bis ich den Kanal umschalte.
Mit OPENGLOSD bleibt der VDR jetzt beim Starten regelmäßig hängen (egal ob das Plugin mit oder ohne -f gestartet wird), der Crash beim detachen ist eventuell ein Folgefehler weil der VDR generell nicht mehr richtig auf Befehle reagiert. Streamdev-Client und alle anderen Plugins habe ich mal versuchsweise deaktiviert und die darüber empfangenen Kanäle aus der channels.conf entfernt, das macht keinen Unterschied.
Hier noch mal der Backtrace: openglosd_hangs.txt, wenn man sich mit gdb attach $(pidof vdr) an den Prozess hängt - den LDPRELOAD für den Sundtek Mediaclient habe ich auch gerade mal versuchsweise entfernt, das ändert auch nichts.
Als nächstes versuche ich es noch mal mit einem anderen Window-Manager als Openbox, vielleicht ändert das noch etwas - was setzt du da ein?
-
Mit twm und icewm ist der Hänger mit OPENGLOSD beim Start weg, wenn ich das Plugin ohne -f starte, aber beim Detachen crasht der VDR immer noch. Könnte die Größenänderung Wechsel vom Fenster- in den Vollbildmodus das OPENGLOSD durcheinander bringen bzw. versuchen den Thread abbrechen zu lassen?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!