softhdcuvid mit libplacebo - manchmal kurze Bildschirm Freeze beim öffnen des OpenGL OSD

  • Hallo.

    Grundsätzlich finde ich in meiner Umgebung die Video-Ausgabe mit softhdcuvid und libplacebo alternativlos.
    Ich habe ohne libplacebo und mit softhddrm getestet, aber die Bildqualität überzeugt mich am meisten in der o.g. Konstellation.

    Leider gibt es einen kleinen Schönheitsfehler mit dem ich zwar leben würde, aber den ich doch versuchen möchte abzustellen.

    Wenn ich das OSD öffne, dann friert manchmal das Bild kurz (1-2s) ein. Das passiert nicht immer, aber häufig wenn das OSD lange nicht geöffnet wurde.
    Nachdem es weiter geht sind Bild und Ton kurz nicht synchron. Den Fehler habe ich schon sehr lange bemerkt, auch schon mit meinem alten System mit einer Nvidia T400.
    Nur mit der T400 schaffte es die Grafikkarte manchmal nicht den a/v sync wieder herzustellen.
    Wenn man das OSD kur vorher offen war, kann ich dieses Problem nicht feststellen.
    Es fühlt sich irgendwie so an, als würde das Opengl OSD schlafen und müsste geweckt werden. Wenn es dann wach ist funktioniert es einwandfrei und ohne Verzögerung.
    Das spricht doch eigentlich dafür, dass es keine Frage der Power ist.

    Das Problem tritt mit unterschiedlichen Skins auf, also getestet mit skindesigner, LCARS, klassischen Skin und skinflatplus.
    Es tritt auch mit unterschiedlichen Scalern auf.
    Mit der neuen Grafikkarte Nvidia T1000 mit 8G RAM wird der a/v sync in der Regel wieder hergestellt.
    Da merkt man also schon, dass die Grafikkarte viel leistungsfähiger ist.
    Das Sysem sollte eigentlich genug Power haben, dass es keine Frage der Resourcen ist, denke ich?
    Die Auslastung, angezeigt per nvtop, zeigt auch keine extremen Spitzen.
    Der Intel N100 läuft im performance-Mode.

    Was könnte die Ursache für diese Freeze sein?

    jojo61 Hast Du eine Idee, an welcher Stelle ich mal nachforschen kann?

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Das OSD ist ja ein eigener Thread. Ich hoffe der wird nicht rausgeswapped wenn er nicht aktiv ist. Wieviel swap Space ist denn benutzt im normalen Betrieb.

    Ich glaube nicht, dass das System Swapped:

    Code
    vdr ~ # free
                  gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
    Speicher:   16216336     1662480    13913464      208100     1032348    14553856
    Swap:        8388604           0     8388604

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Ich glaube nicht, dass das System Swapped

    Ja sieht nicht danach aus. War ja auch nur so eine Idee. Aber mir fällt wirklich nichts ein was die Ursache sein könnte. Das OSD wird nur beim Aufbau gerendert, danach wird es einfach in jedes Frame einkopiert. Aber das das Rendern wirklich Zeit kosten soll glaube ich nicht. Deswegen wird das ja per Opengl auf der GPU gemacht. Mit wievielen Lanes ist den deine Graka angebunden ? Wir hatten hier mal die Diskussion das es Engpässe auf dem PCIe Anschluss zur Graka gibt bei einigen Boards.

  • Ja sieht nicht danach aus. War ja auch nur so eine Idee.

    Ich bin für jede Idee dankbar!

    Deswegen wird das ja per Opengl auf der GPU gemacht. Mit wievielen Lanes ist den deine Graka angebunden ?

    Das steht im Manual vom Motherboard.

    PCIe-Steckplätze:
    PCIE1 (PCIe 3.0 x16-Steckplatz) wird für Grafikkarten mit PCIe x2-Lane-Breite verwendet.
    PCIE2 (PCIe 3.0 x1-Steckplatz) wird für Grafikkarten mit PCIe x1 Lane-Breite verwende

    dmesg sagt zu PCIe:

    lspci -vvv meint:

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Mit PCIe 3.0 und 16 Lanes kannst du ca. 15,5 GB pro Sekunde auf die Graka schaffen. Bei 8 Bit pro Farbe und einer UHD Auflösung wird das dann schon eng.

    Ob es aber nun daran liegt ist schwer zu sagen.

    Gut, ich betreibe ja das Ganze nur mit 1920x1080p50.

    Aber wenn ich es richtig verstehe, werden nur 2 Lanes verwendet:

    Code
    vdr ~ # lspci -vvvs 01:00.0 | grep -i width
                    LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <4us
                    LnkSta: Speed 8GT/s, Width x2 (downgraded)

    Das wären dann ja maximal nur 2GB/s...

    Das wäre ja ärgerlich, wenn das Board zu schwach ist.
    Kann man irgendwie sicher feststellen, ob das die Ursache ist, Bevor ich mich nach einem anderen Board umschaue?

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Leider läuft pcm-pcie auf dem System nicht:

    Code
     pcm-pcie
     Intel(r) Performance Counter Monitor: PCIe Bandwidth Monitoring Utility 
     This utility measures PCIe bandwidth in real-time
     ...
     Detected Intel(R) N100 "Intel(r) microarchitecture codename Raptor Lake" stepping 0 microcode level 0x1c
     Jaketown, Ivytown, Haswell, Broadwell-DE, Skylake, Icelake, Snowridge and Sapphirerapids Server CPU is required for this tool! Program aborted

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    http://www.easy-vdr.de

  • Ob die x2 tatsächlich hier die Anzahl der Lanes angibt ? Aber wenn es wirklich nur 2 Lanes sind, dann frage ich mich warum das Board der Graka keine 16 Lanes gibt. Hast du weitere PCIe Karten im Board ? Oder PCIe SSDs ?

    Es ist eine PCIe NVME mit drin.

    Was ich im Netz gefunden habe, zeigt wohl lspci -vvv mit LnkSta: Speed 8GT/s, Width x2 (downgraded) die Anzahl der tatsächlichen genutzten Lanes an.
    In der Dokumentation zum Board steht wohl auch die Einschränkung:

    Das Board ist schon sehr schwachbrüstig mit seinem 6W TDP Prozessor.
    Da könnte es schon sein, dass der Rest auch kastriert wurde.

    Deine Vermutung würde zumindest erklären, warum die Freeze mit dem neuen System nicht verschwunden sind.
    Das alte System war ein ThinkServer TS200v von 2011 mit einer Nvidia T400. Da war nur PCIe Gen1 x16 dran.

    Wenn wirklich die PCIe-Anbindung die Ursache für die Freeze ist, würde ich mich nach einem anderen System umschauen.

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

    Edited 2 times, last by heifisch (March 7, 2025 at 7:32 AM).

  • Ich würde an deiner Stelle eher mit dem Problem leben. Es gibt keine Garantie das die Ursache tatsächlich der PCIe Bus ist.

    Die CPU mitsamt der GPU ist sicher auch mit libplacebo am Rand ihrer Möglichkeiten.

  • Ich würde an deiner Stelle eher mit dem Problem leben. Es gibt keine Garantie das die Ursache tatsächlich der PCIe Bus ist.

    Ich habe jetzt schon so viel Energie rein gesteckt um dieses Problem zu beseitigen, dass ich nicht gerne aufgeben möchte. :wand
    Na ich gucke mal, ob ich was Gebrauchtes günstig bei Kleinanzeigen kaufen kann.
    Mit kräftiger Intel CPU und Intel-Grafik, könnte ich ja dann auch noch mal softhddrm und libplacebo testen.
    Evtl. würde dann auch das Tool pcm-pcie laufen und ich könnte mir mal die Auslastung auf dem PCIe Bus ansehen.

    Die CPU mitsamt der GPU ist sicher auch mit libplacebo am Rand ihrer Möglichkeiten.

    Was hattest Du denn für Systeme mit libplacebo im Einsatz, mit denen das bei Dir gut funktioniert hat?

    Danke aber fürs mitdenken...

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Mit kräftiger Intel CPU und Intel-Grafik, könnte ich ja dann auch noch mal softhddrm und libplacebo testen.

    softhhddrm ist sicher weniger resourcen belastend weil da ja schonmal kein X läuft. Ich habe hier immer nur auf meinem NUC3 getestet und der war immer schnell genug. Aber auch da ist libplacebo schon eine Herausforderung.

    Ich bin dann aber auf Odroid-N2 umgestiegen weil es da für wenig Geld viel Leistung gibt. Ausserdem ist da HDR und UHD kein Problem. Das Bild ist sicher nicht so gut wie mit libplacebo, aber auch der Odroid-N2 macht eine super skalierung von SD.

    Ausserdem braucht das ganze System nur ca. 7 Watt.

  • softhhddrm ist sicher weniger resourcen belastend weil da ja schonmal kein X läuft. Ich habe hier immer nur auf meinem NUC3 getestet und der war immer schnell genug. Aber auch da ist libplacebo schon eine Herausforderung.

    Da hattest Du softhdcuvid mit libplacebo gar nicht groß im Einsatz?

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Da hattest Du softhdcuvid mit libplacebo gar nicht groß im Einsatz?

    Doch das war lange mein Haupteinsatz auf einem Intel Quad Core. Aber der hat ca. 100 Watt verbraucht und das wurde mir dann langsam zu viel. Ausserdem kann softhdcuvid kein HDR und das wollte ich unbedingt haben.

    Deswegen habe ich dann softhddrm geschrieben und dann softhdodroid. Da läuft das ganze am besten und ist derzeit mein Haupt VDR.

  • Doch das war lange mein Haupteinsatz auf einem Intel Quad Core. Aber der hat ca. 100 Watt verbraucht und das wurde mir dann langsam zu viel. Ausserdem kann softhdcuvid kein HDR und das wollte ich unbedingt haben.

    Deswegen habe ich dann softhddrm geschrieben und dann softhdodroid. Da läuft das ganze am besten und ist derzeit mein Haupt VDR.

    jojo61 Vielen Dank. Damit verstehe ich die Zusammenhänge besser und kann das Problem besser einordnen.

    Für das odroid-N2 müsste ich einen kompletten Strategiewechsel machen.
    Mein aktueller VDR hat die große HDD-Platte drin und soll mittels der Nvidia-Karte auch die Aufnahmen in HEVC transcodieren.

    Gentoo Linux ~ VDR 2.7.4 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ Asrock N100M ~ 16GB RAM ~ NVIDIA T1000 8G

  • Mein aktueller VDR hat die große HDD-Platte drin und soll mittels der Nvidia-Karte auch die Aufnahmen in HEVC transcodieren.

    Das ist ja auch kein schlechter Ansatz. Und ich supporte ja auch weiterhin softhdcuvid/vaapi/drm. Nur libplacebo braucht halt doch einen potenten Rechner.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!