softhdcuvid with hevc and UHD

  • Witzigerweise geht mpv problemlos, log im Anhang.

    Dumme frage: kann es sein, dass shader oder ähnliches irgendwo gecached wird und ich mal diesen Cache "cleanen" sollte?

    Nein die shader werden nicht gecached. Der Absturz ist beim erstellen der Swapchain. Und da wird nur die XCB Surface benutzt. Sieht eigentlich alles gut aus und dennoch geht es nicht. Da der Absturz in den NVIDIA Libs ist könnte es mit dem NVIDIA Treiber zu tun haben. Oder schau mal ob es einen update der XCB Libs gibt.

  • Nein die shader werden nicht gecached. Der Absturz ist beim erstellen der Swapchain. Und da wird nur die XCB Surface benutzt. Sieht eigentlich alles gut aus und dennoch geht es nicht. Da der Absturz in den NVIDIA Libs ist könnte es mit dem NVIDIA Treiber zu tun haben. Oder schau mal ob es einen update der XCB Libs gibt.

    Entschuldigung, unsere Postings haben sich überschnitten, s. oben, es tut!

  • BTW: habe versucht für SD auf "bicubic" umzustellen, er ist eine Verbesserung da, aber Frames werden immer noch gedropped auch in SD.

    Framedrops sind gefühlt "heftiger" wenn diagnostic-OSD von softhdcuvid eingeblendet ist.

  • Ja ich habe auch das Problem das es gefühlt langsamer geworden ist. Bei meiner 1050 musste ich auch einige scaler ändern damit keine Framedrops mehr auftreten. Das war vor einiger Zeit noch völlig anders. ich habe den NVIDIA Treiber im verdacht und werde mal Versuche mit älteren Treibern anstellen.

    Ich hab denke so um die 415 ist das Problem entstanden. Wenn du Lust und Zeit hast kannst du ja mal einen älteren Treiber testen.


    mfg

    Jojo61

  • Habe versucht heute ein Bisschen zu experimentieren. Mit den zurückgehen auf ältere Treiber bin ich gescheitert: bereits 418 kompiliert nicht bei mir, vermutlich wegen dem 5.3.x kernel. mit 430 und 435 ist das Verhalten gleich.

    OSD erzeugt ordentlich Last, für SD-Kanäle steigt GPU-Utilization von ca. 20% auf ca. 30% und das scheint schon "zu viel" zu sein -> framedrops in diagnostic-OSD

    Ich habe ebenfalls softhdcuvid aktualisiert.

    Frame Duration, die ohne libplacebo bei 2,5ms liegt, steigt mit libplacebo auf 20ms für SD und 25ms für UHD

    War es auch früher so, dass OSD so viel Last erzeugt?

  • Hallo Das OSD mit libplacebo erzeugt immer etwas höhere Last weil ich es übers RAM umkopieren muss. Ich schau mir das mal an ob ich das noch optimieren kann. Du hast als Ausgabedevice einen UHD Fernseher angeschlossen, Da hat schon meine 1050 so ihre schwierigkeiten mit dem OSD.


    Mal sehen ob ich da was machen kann.

  • Habe versucht heute ein Bisschen zu experimentieren. Mit den zurückgehen auf ältere Treiber bin ich gescheitert: bereits 418 kompiliert nicht bei mir, vermutlich wegen dem 5.3.x kernel. mit 430 und 435 ist das Verhalten gleich.

    OSD erzeugt ordentlich Last, für SD-Kanäle steigt GPU-Utilization von ca. 20% auf ca. 30% und das scheint schon "zu viel" zu sein -> framedrops in diagnostic-OSD

    Ich habe ebenfalls softhdcuvid aktualisiert.

    Frame Duration, die ohne libplacebo bei 2,5ms liegt, steigt mit libplacebo auf 20ms für SD und 25ms für UHD

    War es auch früher so, dass OSD so viel Last erzeugt?

    Ich habe nochmal ein paar kleine Optimierungen zum OSD eingecheckt. Die Angzeigte Frame Duration bei Placebo ist leider nicht ganz richtig. Es werden 20ms angezeigt wenn die Duration kleiner/gleich 20ms sind und es werden mehr als 20ms angezeigt wenn es länger dauert. D.h. bei einer Anzeige von 25ms schafft es die karte nicht das Frame schnell genug anzuzeigen. Das liegt dann an placebo und der eingestellten Skalierung und der nötigen Farbkonvertierung. Mir ist immer noch nicht klar warum das nun so langsam ist.


    jojo61

  • Ich habe nochmal ein paar kleine Optimierungen zum OSD eingecheckt. Die Angzeigte Frame Duration bei Placebo ist leider nicht ganz richtig. Es werden 20ms angezeigt wenn die Duration kleiner/gleich 20ms sind und es werden mehr als 20ms angezeigt wenn es länger dauert. D.h. bei einer Anzeige von 25ms schafft es die karte nicht das Frame schnell genug anzuzeigen. Das liegt dann an placebo und der eingestellten Skalierung und der nötigen Farbkonvertierung. Mir ist immer noch nicht klar warum das nun so langsam ist.

    Danke schön. Ich habe es ausprobiert, es hat eventuell minimal etwas verbessert, aber nicht grundlegend. Ich orientiere mich eher daran, ob (und wie viele) dropped Frames es in diagnostic-OSD gibt. Bei SD sind es jetzt ca. 2 pro Sekunde, ich glaube davor waren es eher 3. Bei HD sind jetzt ca. 4, bei UHD ca. 6. BTW: als Scalierung ist bicubic eingestellt, scheint minimalen Ressourcenverbrauch zu haben.

    Ohne OSD sieht es so aus, als ob SD und evtl HD flüssig laufen, UHD definitiv nicht mehr.

    Frame Duration ist immer bei über 20ms: SD 20,4, UHD ca. 25ms

    Ohne libplacebo läuft es ganz OK, so werde ich das auch erstmals lassen.

  • So ich glaube ich habe das Problem mit PLACEBO gefunden. Wenn du Lust hast probiere es doch nochmal aus.

    Ja, in der Tat! Es ist viel, viel besser geworden mit libplacebo. Ohne OSD scheint es flüssig zu laufen. Mit diagnose-OSD gibt es sporadische dropped Frames, ca. 1 Frame pro Sekunde, in allen Auflösungen (SD, HD, UHD). Ich würde sagen, in SD und HD wird es richtig brauchbar. Ich UHD bei "normalen" Kanälen wie Fashion 4k ist es auf den ersten Blick auch akzeptabel, SES UHD ist problematisch. Gratuliere, super!

    Jetzt kommen ein Paar sonstige Beobachtungen: Ich vermute, dass im Decoding (H265, MPEg4 etc.) noch ein Wurm steckt. Starten wir mit SD-Kanälen: wenn ich diagnostic-OSD einblende, treten dropped Frames hauptsächlich bei schnellen großflächigen Bewegungen auf. Solange im Bild nur kleinere Veränderungen passieren, werden keine Frames verloren. Wenn ich parallel dazu GPU-Utilization in nvidia-smi beobachte, sehe ich keine nennenswerte Schwankungen, Utilization ist mit libplacebo bei SD ohne OSD bei ca. 23%, mit diagnostic-OSD bei 30%, d.h. es sollte noch jede menge Lüft nach oben sein. Konnte ich bei mehreren Kanälen beobachten. Bei HD und UHD ist das weniger offensichtlich, der Effekt ist der gleiche: Dropped Frames beim eingeblendeten diagnistic-OSD korellieren mit Bewegungen im Bild.

    Bei SES-UHD treten in manchen Szenen reproduzierbar Rückler (dropped Frames) auf. In allen Konstellationen: mit oder ohne OSD, mit oder ohne libplacebo. Insbesondede shuttle-start ist so eine Szene.

    Fazit: ich glaube, da ist noch etwas unsauber beim dekodieren bzw. es gibt komische Wechselwirkungen mit dem Rest der Anzeigelogik.

    BTW: GPU-Utilization (ohne diagnostic-OSD, mit libplacebo) steigt bei "normalen" UHD-Kanälen auf 40%, bei SES-UHD auf 80%

    Aber trotzdem, geile Arbeit! Danke!

  • Also das sich die Framesdrops mit dem Bildinhalt verändern wundert mich schon sehr. Da gibt es eigentlich keinen Zusammenhang.

    SES-UHD ist in HDR mit BT2020 Farben und da wird in Placebo zusätzlich noch eine Farbumwandlung in BT709 oder sRGB gemacht (je nachdem welche Monitorfarbe du eingestellt hast). Das erklärt die höhere Last mit HDR.


    Wenn du dir den checkin anschaust sieht du das ich nur den usleep zwischen den Frames verkürzt habe. Zum Testen kannst du das auch mal von 5000 auf 1000 reduzieren. Im Prinzip bracht man das gar nicht. Aber wenn ich es rausnehme dann habe ich hier ein langsames Reagieren auf Eingaben. Wenn du mit lircd arbeitest dann kannst du es evtl. auch ganz rausnehmen.


    mfg

    jojo61

  • Wenn du dir den checkin anschaust sieht du das ich nur den usleep zwischen den Frames verkürzt habe. Zum Testen kannst du das auch mal von 5000 auf 1000 reduzieren. Im Prinzip bracht man das gar nicht. Aber wenn ich es rausnehme dann habe ich hier ein langsames Reagieren auf Eingaben. Wenn du mit lircd arbeitest dann kannst du es evtl. auch ganz rausnehmen.

    Ich habe es probeweise auf 1000 reduziert, das hat aber nichts mehr geändert. Ich habe mir den Code angeschaut, stelle aber fest, dass ich mit den ganzen #ifdefs nur schwer durchblicken kann, was da abgeht. Eventuell schaue ich mir das bei Gelegenheit "genauer" an.


  • Moin jojo61,

    dieser Fehler ist im aktuellen git wieder enthalten 146b826 funktionierte.

    Gruß

    moz

  • Hallo moz,

    bei mir läuft es normal.


    Gruß

    Murry

    Hmm,

    X läuft bei mir in UHD, OSD ist auf HD eingestellt.

    EIgentlich richtig wenn das OSD dann auf 1/4 des Screen dargestellt wird.

    Bis dato wurde das OSD aber immer richtig skaliert. Mit der neuen Version nicht mehr.


    Stelle ich das OSD auf Custom und 3840x2160 wird skindesigner nicht mehr richtig dargestellt und es kommt zum Absturz.

  • Ahh am OSD habe ich ja geschraubt. Ich schaue mir das nochmal an. Das sollte zu beheben sein. Ich schaue auch in UHD mit OSD size auto. Aber ich nutze nur LCARS. Skindesigner kann aber nur 1920x1080. Das muss dann hochskaliert werden. Das ging auch mal. Ich werde es beheben.


    jojo61

  • Hi,

    if I fast open and close the menu "m", I can trigger a visible issue. (1920x1080 lcars no placebo)


    and another strange log on exit

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

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

  • Hi,

    Quote

    Und ausserdem habe ich versucht das OSD bei schnellem an und aus zu beheben

    it is still there, but only without placebo.

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.