softhdcuvid with hevc and UHD

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Code
    1. Sep 28 13:19:48 gentoo vdr[10373]: [softhddev]Resume:
    2. Sep 28 13:19:48 gentoo vdr[10373]: video: visual 0x21 depth 24
    3. Sep 28 13:19:48 gentoo vdr[10373]: video: window prepared
    4. Sep 28 13:19:48 gentoo vdr[10373]: video/glx: glx version 1.4
    5. Sep 28 13:19:48 gentoo vdr[10373]: video/glx: GlxSwapIntervalMESA=(nil)
    6. Sep 28 13:19:48 gentoo vdr[10373]: video/glx: GlxSwapIntervalSGI=0x7f0f60018000
    7. Sep 28 13:19:48 gentoo vdr[10373]: video/glx: GlxGetVideoSyncSGI=0x7f0f4ded1390
    8. Sep 28 13:19:48 gentoo vdr[10373]: RGB size 8:8:8
    9. Sep 28 13:19:48 gentoo vdr[10373]: [10423] fatal error, server exiting: Ungültiger Dateideskriptor
    10. Sep 28 13:19:49 gentoo vdr[10373]: [10373] switching to channel 19 T-8468-38914-772 (tagesschau24 HD (T))


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

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


    jsffm welchen Treiber hast du denn im Einsatz ? Ich teste auf 10 Bit ausgabe und bei dir scheint er da in der Gegend abzuschmieren.


    mfg

    jojo61

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ok ich werde auch mal mit dem 396.54 testen. Ich will sicher keinen bestimmten Treiber vorschreiben, aber mir scheint an der Stelle doch noch Bewegung in den Treibern von NVIDIA zu sein. Das mit der Bildschirmauflösung schaue ich mir mal an, ist das aber nicht etwas exotisch ?


    jojo61


    So mit dem 396.54 läuft es bei mir auch völlig ok. Detachen und Attachen geht und mit -D hochfahen und dann attachen geht ach. Da frage ich mich was bei dir anders ist. Meine vermutung ist das es an den verschiedenen opengl contexten liegt. Nur die kann ich nicht auflösen wg. den verschiedenen Threads.

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • Ich benutze 384.130, bei neueren habe ich ein Problem mit OSD beim softhddevice. Ich kann mal mit eineren neueren Version Testen.


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

  • Ich benutze jetzt seit gut 2 Wochen vdr-plugin-softhdcuvid (0.6.1rc1+git20180909-22-cca1022-1yavdr0~bionic) auf meinem Wohnzimmer VDR und es läuft soweit stabil.

    Festgestelltes Problem (neben dem bereits erwähnten 4:3 Issue, scheint ja in einer neueren Version schon erledigt zu sein) nur das die HD Sender der RTL Familie merkwürdig "ruckeln" bzw. "zucken". Tritt sowohl bei Live-TV als auch (neuen/alten) Aufnahmen auf. RTL UHD klappt (hab neulich Formel 1 gesehen) hingegen.


    Ist da was bekannt?

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

    Ich teste nun mit 396.54.


    mfg

    jojo61

  • Jetzt habe ich mal andere Treiber getestet:


    396.54

    Code
    1. Sep 28 17:02:36 gentoo vdr[21998]: codec: can't open video codec!

    390.67

    Code
    1. Sep 28 17:07:37 gentoo vdr[26926]: [26976] fatal error, server exiting: Ungültiger Dateideskriptor
    2. Sep 28 17:07:38 gentoo vdr[26926]: [26926] switching to channel 19 T-8468-38914-772 (tagesschau24 HD (T))

    also wie gehabt.


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

    The post was edited 1 time, last by jsffm ().

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich vergass noch was zu sagen, der Fehler bei 396.54 kommt beim Start!


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

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

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

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

    Mit welchem Treiber testest du denn nun ?

  • Mit 396.54.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da scheint die Version nicht mit dem ffmpeg zusammen zu spielen. Wenn er keinen Codec aufmachen kann, dann ist das aber ffmpeg.

    3.3.8 sollte wohl 3.4 sein.


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