softhdcuvid/softhdvaapi/softhddrm with hevc and UHD

  • 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 ;)

  • 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


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • 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 Regel

    Code
    <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):

    Code
    Sep 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.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • 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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • SD Anzeige ist jetzt horizontal gestaucht (4:3), ich meine, das wär schon besser gewesen.


    @seahawk1986


    Bei Dir scheint streamdev im Spiel zu sein, wenn ich das bei mir aktiviere, habe ich auch stockende Bilder beim Umschalten.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Ich bin nochmal zurück auf die Version vom 1.9. (softhdcuvid v0.6.1rc1-GITcbdc46e), da ist SD noch OK.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • 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:

    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:

  • Das ist keine Lösung, da dann 4:3 Sendungen falsch wiedergegeben werden.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • 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

  • Gleiche Meldung wie vorher beim detach


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • 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?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!