Beiträge von seahawk1986

    Beim nächsten ATTA ist das OSD dann kaputt. Das scheint mir am skindesigner zu liegen. Oder jemand sagt mir wie ich dem skindesigner das DETA mitteilen kann

    Ich habe gerade noch mal in meine Notizen geschaut: Der skindesigner hätte gerne, dass man ihm ein svdrpsend plug skindesigner DLIC schickt, wenn man das Frontend detached (softhddevice mit High Level OSD) - an anderer Stelle hat louis geschrieben, dass man den Befehl vor dem Detachen bei geschlossenem OSD absetzen soll (Skindesigner 0.8.8).


    Bei yaVDR 0.6 hatte ich das so gelöst, dass das Frontend-Skript mit aller Gewalt versucht das OSD zu schließen (also die Taste MENU gefolgt von BACK BACK BACK, kleine Pause und noch mal BACK BACK sendet), dann wird DLIC an den Skindesigner gesendet und zum Schluss geht das DETA an softhddevice(-openglosd). Bei yavdr-ansible hatte ich das vereinfacht (erst DETA an softhddevice/-cuvid, dann DLIC an den skindesigner) - das hat mit den älten softhddevice-Forks bei meinem Versuchen gut geklappt, aber falls nötig baue ich den Workaround wieder ein.

    Kannst du mal die EDID anhängen, die dein TV bereitstellt?


    Ein Knackpunkt unter Windows scheint zu sein, dass nvidia-Karten einen EDID mit Version 1.3 ignorieren (https://www.reddit.com/r/nvidi…a_displayport_dell_u2410/) - laut http://www.analogway.com/files…te-paper-edid--082714.pdf Seite 2 ist der Aufbau von Version 1.3 und 1.4 grundsätzlich identisch, aber 1.4 funktioniert nicht über HDMI.


    Man könnte mal versuchen die Bytes für die EDID-Version zu manipulieren und ggf. die Informationen für die Farbtiefe zu ergänzen.

    Da ich aber auf dem System nicht wild eigene ffmpeg Versionen kompilieren mag, warte ich mal bis es eine funktionierende Version in die yavdr Repos oder zugehörige PPAs geschafft haben.

    Bei ffmpeg 3.4.4 gibt es zwei Stellen in der libavcodec/cuviddec.c, in denen die im README angesprochene Stelle vorkommt:

    Code
    1. ~/src/experimental/ffmpeg-3.4.4/libavcodec$ grep -n 'ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces' cuvid.c
    2. 844: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
    3. 1041: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));

    Bei der cuviddec.c aus ffmpeg 4.0.2 sind die Treffer in Zeile 856 und 1059, was ziemlich weit weg von den in der README angegebenen Zeile 360 ist:

    Unfortunatly FFMEG has a bug with deinterlacing cuda frames. So you have to patch the file in libavcodec/cuviddec.c

    Somewhere near line 360 depending on your release: old: ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));

    new: ctx->frame_queue = av_fifo_alloc((ctx->nb_surfaces + 2 ) * sizeof(CuvidParsedFrame));

    jojo61 hast du eventuell einen Patch für die von dir genutzte ffmpeg-Version, mit dem man den Zusammenhang besser sehen kann?

    so gefixt

    Die Hänger sind weg, aber ich habe mit dem skindesigner noch sporadische Crashes wie crash_0.6.1rc1+git20180929-29-a998e6a-0yavdr0~bionic.txt beobachten können, wenn man das Plugin für den Bildschirmwechsel detached und wieder attached. Mit LCARS als Skin scheint das nicht zu passieren.


    Die Menü-Darstellung mit dem skindesigner sieht jetzt sauberer aus (der Hintergrund wird korrekt gezeichnet) und das Scrollen funktioniert ohne Flackern.

    seahawk1986 so nochmal am OSD und DETA gebastelt und versucht die GLX Contexte besser zu verstehen. Bei mir klappt nun alles.

    Es wird besser :) - nach dem erneuten Attachen habe ich jetzt Bild und OSD. Aber das Plugin hängt immer noch reproduzierbar beim detachen, falls da gerade das OSD offen ist.

    Und das detachen und auf einem anderen Display reattachen klappt mit der neuesten Version nicht mehr zuverlässig, da gibt es häufig das Problem, dass das Plugin nicht sicher ist, ob es attached oder detached ist:

    So habe die OSD sachen nochmal nachgearbeitet. Bis auf das starten mit -D sollte nun alles gehn.

    Wenn man nach dem start mit -D ein attach, detach und dann wieder attach macht geht es auch. Das muss ich aber noch fixen.

    Wenn ich das Frontend detache und danach wieder attache sehe ich mit der aktuellen Version aus dem Git das OSD auf einem schwarzen Hintergrund, aber kein Video solange das OSD offen ist. Dabei ist es egal, ob ich das Plugin mit -D starten lasse oder nicht.

    Das mit der Bildschirmauflösung schaue ich mir mal an, ist das aber nicht etwas exotisch ?

    yaVDR hat seit vielen Jahren die Fähigkeit das Frontend vorübergehend auf einem zweiten angeschlossenen Bildschirm/Beamer darzustellen - und da das immer noch genutzt wird, wäre es natürlich schön, wenn das auf mit softhdcuvid funktionieren würde.


    Das realisitischere Szenario für den Desktop-Betrieb wäre natürlich, dass man das Plugin nicht imit -f, sondern mit einer Geometrie-Angabe wie -g 1280x720+0+0 startet und später in den Vollbildmodus geht, dabei tritt das Problem mit der OSD-Größe auch auf.

    seahawk1986 du hast den 390.48 Treiber von NVIDIA. Ich teste die ganze Zeit mit 396.24. Der Absturz ist im NVIDIA Treiber. Kannst du das mal auf 396.24 updaten ? Alle neueren Treiber als 396.24 hatten/haben ein Problem mit CUDA und ich habe noch nicht evaluiert ob das nun behoben ist. Deswegen bitte teste mal mit dem 396.24.

    Veraltete Zwischenversionen sind immer etwas schwierig, wenn man Pakete dafür in einem PPA anbieten könnnen will (man muss das Plugin ja gegen eine bestimmte Treiberversion bauen, die in einer Paketquelle liegt und noch nicht von anderen Paketen ersetzt wurde) ...


    Ich habe das Plugin gerade mal versuchsweise gegen den 396.54 aus https://launchpad.net/~graphic…ield.series_filter=bionic gebaut. Damit ist der Hänger beim Detachen schon mal weg, aber ich habe nach dem erneuten Attachen kein OSD (man sieht nur einen komplett schwarzen bzw. hellblauen Bildschirm wenn die Kanalanzeige bzw. das Menü aktiv sind).


    Außerdem scheint das Plugin die Bildschirmauflösung nur einmalig zu ermitteln, wenn man z.B. auf einem Display mit kleinerer Auflösung startet, dann das Plugin detached und es auf einem höher auflösendem Display wieder re-attached, wird das OSD nur auf der Fläche des kleineren Bildschirms gezeichnet.

    Mit der neuen Version hatte ich direkt einen Hänger beim detachen des Frontends (man sieht nur noch ein Standbild) - das Plugin scheint sich dann nicht sicher zu sein, welchen Zustand es hat:

    Hier noch der Coredump von einem Hänger mit der neuesten Version: Coredump_softhdcuvid_0.6.1rc1+git20180928-26-97f53c8.txt


    Wenn der VDR mit detachtem Plugin gestartet wird, während KODI läuft und man dann nach dem Beenden von KODI softhdcuvid attached, gibt es nur ein schwarzes bzw. einfarbiges OSD.

    Wie sieht denn das Log auf dem Server dabei aus? Gibt es Meldungen, dass der angeforderte Kanal nicht getuned werden kann oder der Lock wegbricht? Aus meiner Erfahrung der letzten Monate (aufgrund tendenziell zu hoher Signalpegel an der Antennendose hatten meine Tuner sporadisch Aussetzer, was ich zum Glück mit Dämpfungsreglern in den Griff bekommen habe) kann ein VDR 2.4.0 sehr zickig reagieren, wenn es Empfangsprobleme gibt.

    Habe noch einen Fix für den Aspectratio für SD Sender eingecheckt und zusätzlich noch einen Mutex für das openglosd.

    Die Deadlocks beim OSD-Aufruf scheinen jetzt weg zu sein und das Skalieren des Bildes im Skindesigner beim Öffnen des Hauptmenü funktioniert auch :tup


    Es gibt noch ein paar Darstellungsprobleme mit dem skindesigner: Das Zeichnen des Menü-Hintergrundes klappt noch nicht zuverlässig - beim estuary4vdr oder shady_KISS Theme kann man das gut beobachten (Hintergrund entweder schwarz oder komplett Transparent). Und wenn man im Menü scrollt, flackert das OSD z.T. deutlich sichtbar - fast so als würde da immer alles neu gezeichnet.


    Edit: Der VDR crasht zwar beim Detachen nicht mehr, aber ich bekomme nach dem erneuten Attachen teilweise kein Bild und/oder auch kein OSD mehr, bis ich den VDR neu starte. Umschalten hilft nicht.


    Das Log beim Attachen scheint auf den ersten Blick nicht viel herzugeben: