softhdcuvid/softhdvaapi/softhddrm with hevc and UHD

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

    D.h. beim starten mit -D kommt das OSD sofort als overlay mit Bild und umschalten auf anderen Screen mit DETA und ATTA geht auch.

    Habe es bestimmt 30mal zwischen 2 Monitoren hin und her geschaltet ohne crash :)


    jojo61

  • ffmpeg 3.4.4 bringt keine Verbesserung


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

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

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

    Upps mit offenem OSD hatte ich es noch gar nicht probiert. Kann es reproduzieren und schaue es mir an.


    jsffm an den ffmpeg sachen habe ich nichts mehr gemacht, Insofern wundert es mich nicht das sich da nix bessert. Hast du immer noch einen crash beim detachen ?


    jojo61

  • Hast du immer noch einen crash beim detachen ?

    Nein, beim Attachen


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

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich hab mich mal an nem Backtrace vom detach versucht:



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

  • 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
    ~/src/experimental/ffmpeg-3.4.4/libavcodec$ grep -n 'ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces' cuvid.c 
    844:    ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
    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?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • seahawk1986 Habe gerade gesehen das ich einen Tippfehler im Readme hatte. Die Zeile bei meiner FFMPEG 4.0 ist 863 und nicht 360.

    Die zweite Stelle im Sourcefile wo das vorkommt ist nicht nötig zu patchen, aber es schadet auch nichts.

    Hintergund ist folgender:

    Beim deinterlacen erzeugt der decoder ein zweites Vollbild (frame) . Wenn nun die Framequeue schon voll ist dann ist kein Platz mehr für dieses weitere Frame und die Queue löuft über. Deswegen habe ich die Frameque einfach um ein weiteres (genauer 2 sicherheitshalber) beim alloc erweitert. Dann ist immer noch Platz weil der "voll" test nicht bis zum Ende der Queue auffüllt.

    Im Prinzip sollte die Queue nie voll laufen weil die Frames ja abgeholt und angezeigt werden. Am Anfang habe ich die Frames erst abholt nachdem die Decoderqueue (av_codec_send_packet) voll war. So habe ich den Fehler entdeckt. Dann habe ich das abholen der Frames aber umgestellt und hole immer sofort alle fertigen Frames ab.Damit sollte es eigentlich auch ohne den FFMPEG patch gehen. Aber wie es aussieht tritt das Problem doch noch manchmal auf und dann wird der patch gebraucht. Ein Fehler ist es auf jeden Fall.

    Ich weiss leider nicht wie ich das den Jungs von FFMPEG melden soll damit es dort eingepflegt wird.


    mfg

    jojo61


    PS: das Detachen mit dem skindesigner schaue ich mir noch an


    jsffm dein BT ist interessant. Ich schaue das noch genauer an.

  • PS: das Detachen mit dem skindesigner schaue ich mir noch an

    Danke, er scheint sporadisch auch ohne skindesigner mit LCARS als Skin zu crashen das sieht dann z.B. so aus: crash_0.6.1rc1+git20180929-29-a998e6a-1yavdr0~bionic.txt

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich weiss leider nicht wie ich das den Jungs von FFMPEG melden soll damit es dort eingepflegt wird.

    Man könnte es über die ML (libav-user) oder den IRC probieren: https://ffmpeg.org/contact.html

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke, er scheint sporadisch auch ohne skindesigner mit LCARS als Skin zu crashen das sieht dann z.B. so aus: crash_0.6.1rc1+git20180929-29-a998e6a-1yavdr0~bionic.txt

    Der crash mit LCARS lag daran das er noch versucht hat ein Bild anzuzeigen als die Buffer schon gelöscht waren. Das habe ich nun hoffentlich verriegelt.


    jsffm dein Fehler beim ATTA ist sonderbar. Er crasht beim versuch den GKXcontext zu löschen. Da ist die libX11 und die libGLX von nividia beteiligt. Welche libX11 hast du denn ? Bei mir ist es die 1.6.3


    seahawk1986 beim DETA mit skindesigner scheint der skindesigner das detachen nicht mitzubekommen. 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 :)


    jojo61

  • x11-libs/libX11-1.6.6


    es könnte sein, das beim BT noch ne ältere Version aktiv war, der BT hatte sich aber nicht verändert.


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

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Mit dem Commit aus dem Git 3f15f79 sieht es schon mal besser aus, ich konnte mit dem Skindesigner gerade bei mehrfachem deta->atta mit einem Bildschirmwechsel oder Start von KODI dazwischen keinen Crash auslösen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • grab grab grab ?


    Aber schon mal vielen Dank bis hierher, werde nachher mal testen.


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Ist denn nun noch etwas offen ?

    Die Implementierung von GRAB fehlt noch.


    Leider unterstützt der nvidia-396 die GT630 und GT730 Karten laut https://www.nvidia.com/Downloa…Results.aspx/137211/en-us nicht - ich werde noch ein PPA mit dem nvidia-Treiber und dem gepatchten ffmpeg anlegen, damit die yavdr-ansible Nutzer mit neueren NVIDIA-Karten den aktuellen Stand leichter ausprobieren können.

    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!