VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand? Teil 2

  • Im Anschluss an VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand? möchte ich das Thema der Hänger bei Wiedergabe von H264 codierten Sendern mit vdpau aufgreifen. Gerade beim Einsatz von neueren Distris mit xorg-servern ab 1.9 ist dies relevant, da diese nvidia Treiber ab 256 erfordern, während der letzte gute nvidia Treiber der 195.30 ist.
    Beschreibung der Hänger: VDPAU und die "Hänger" bei HD. Wie ist der aktuelle Stand? „Die "Hänger" beginnen mit einem kurzen Standbild (1-2 Sekunden) das dann direkt in einen schnellen Bildvorlauf übergeht, der ebenfalls noch mal 1-2 Sekunden läuft. Der Ton läuft währenddessen ganz normal weiter. Es gibt weder vor noch nach einem Hänger Asynchronitäten. Auf der Konsole erfolgt währendessen die berühmt-berüchtigte Ausgabe "verwerfe Bild mit PTS...". Während dieser Phase kommt es auch zu einer erhöhten CPU-Auslastung (bei einem meiner Rechner dreht der CPU-Lüfter dann hörbar schneller).“
    Bei schnelleren Cpus gibt es aber keinen schnellen Bildvorlauf, sondern nur das 1-2 Sekunden lange Standbild, danach läuft der Film normal weiter. Denn schnelle Cpus holen die Verspätung praktisch sofort wieder auf, während langsamere Cpus dazu etwas Zeit brauchen, und während des Aufholens eine Art schnellen Bildvorlauf produzieren.
    Um diese Hänger messbar zu machen, gibt es von Durchflieger bzw. von rnissl den Profiling bzw. Watchdog Patch. Ich habe die Patche so verändert, dass sie zwecks dauerhaftem mitloggen ins syslog schreiben. Dabei habe ich mich über die unterschiedlichen Ergebnisse gewundert.
    Bei 720p Sendern gibt es alle 20ms ein Bild. Der watchdog patch lässt öfters mal eins oder mehrere aus. Hier fehlt 10.915:

    Code
    Sep  3 22:32:10 vdr xine: ==== 22:32:10.835 WATCHDOG 0 ms: vdp_decoder_render took 0.000 ms to execute ==== 
    Sep  3 22:32:10 vdr xine: ==== 22:32:10.855 WATCHDOG 0 ms: vdp_decoder_render took 0.000 ms to execute ==== 
    Sep  3 22:32:10 vdr xine: ==== 22:32:10.875 WATCHDOG 0 ms: vdp_decoder_render took 0.035 ms to execute ==== 
    Sep  3 22:32:10 vdr xine: ==== 22:32:10.895 WATCHDOG 0 ms: vdp_decoder_render took 0.000 ms to execute ==== 
    Sep  3 22:32:10 vdr xine: ==== 22:32:10.935 WATCHDOG 0 ms: vdp_decoder_render took 0.000 ms to execute ==== 
    Sep  3 22:32:10 vdr xine: ==== 22:32:10.955 WATCHDOG 0 ms: vdp_decoder_render took 0.045 ms to execute ====


    Hier fehlen mehrere watchdog ausgaben, und die zweite Zeit ist Null im Gegensatz zur Profiling Ausgabe. Aktiviert war das innere und äußere profiling, sowie der watchdog.


    Hier die syslog Einträge eines Hängers. Obwohl sowohl der Profiling als auch der Watchdog im Einsatz waren, hat nur der Profiling Patch Alarm gegeben. Der Watchdog patch hat beim Hänger keinen output verursacht:

    Code
    Nov  5 01:58:36 vdr xine: ==== 01:58:36.669 WATCHDOG 0,250 ms: vdp_decoder_render took 1,098 ms to execute ====
    Nov  5 01:59:32 vdr xine: ==== 01:59:32.051 WATCHDOG 0,250 ms: vdp_decoder_render took 1,084 ms to execute ====
    Nov  5 01:59:53 vdr xine: ==== 01:59:53.292 WATCHDOG 0,250 ms: vdp_decoder_render took 0,531 ms to execute ====
    Nov  5 03:19:09 vdr xine: ==== 03:19:09.332 VDPAU PROFILE O_PEAK 262,500 ms ==== render
    Nov  5 16:59:16 vdr xine: ==== 16:59:16.658 VDPAU PROFILE O_PEAK 39,595 ms ==== render
    Nov  5 16:59:18 vdr xine: ==== 16:59:18.536 VDPAU PROFILE O_PEAK 1877,478 ms ==== render
    Nov  5 16:59:20 vdr xine: ==== 16:59:20.401 VDPAU PROFILE O_PEAK 1864,526 ms ==== render
    Nov  5 17:12:20 vdr xine: ==== 17:12:20.641 WATCHDOG 0,250 ms: vdp_decoder_render took 1,169 ms to execute ====
    Nov  5 17:15:39 vdr xine: ==== 17:15:39.620 WATCHDOG 0,250 ms: vdp_decoder_render took 1,089 ms to execute ====
    Nov  5 17:15:52 vdr xine: ==== 17:15:52.471 WATCHDOG 0,250 ms: vdp_decoder_render took 1,346 ms to execute ====


    Syslog oder printf´s macht dabei keinen Unterschied.


    1. Frage: Wieso sind die Ergebnisse vom Profiling patch und watchdog patch so unterschiedlich?


    Jetzt das Merkwürdigste. Wenn ich nur den watchdog patch verwende, gibt es auf meinem System keine Hänger mehr! Ich habe lange gezögert, das hier zu schreiben, aber nach einigen Monaten glaube ich nicht mehr an Zufall. Auf meinem System bekomme ich nach mehrmaligem Wechsel der patche eindeutig mit dem Profiling patch (egal ob watchdog patch dabei oder nicht) Hänger, wenn aber nur der watchdog patch drauf ist keine Hänger. Und damit meine ich nicht nur die syslog Einträge, ich sehe auch keine Hänger.


    2. Frage: Bei wem ist das auch so, bzw. bei wem ist das nicht so? Und welches System ist im Einsatz (Gpu, nvidia Treiber, Cpu, Software)?


    Gpu: G210, nvidia Treiber: 290.x, Cpu: Sempron 140@Athlon II X2, opensuse 11.3 mit aktuellem Kernel und xine cvs.
    Die Aufnahmen waren von den ÖRs in 720p H264.


    Falls das nicht nur bei mir so ist, müsste man eventuell die Theorie, dass der nvidia Treiber Schuld ist, ändern, und den Fehler auch in xine suchen.


    Nachtrag zur Abgrenzung von anderen Rucklern und Hängern
    Der Grund für die Hänger sind laut durchflieger und rnissl ein Problem im nvidia treiber, welches sich dadurch zeigt, dass vdpau decoder Aufrufe zu viel Laufzeit für ein frame benötigen. Dies tritt auch bei Aufnahmen auf.
    Es wäre aufschlussreich, wenn ihr die syslog Ausgaben um den Zeitpunkt des Hängers herum postet. Zur Kontrolle, ob der watchdog funktioniert, kann man mit "grep -e render messages" schauen, ob überhaupt Ausgaben kommen (bei 3ms sollte ab und zu was erscheinen).


    Anbei der Patch, auf dem gerade nur der watchdog aktiv ist. Man kann aber auch das innere oder äußere Profiling aktivieren. Der Patch hat sich im Lauf der Zeit bei mir verändert, obige Ausgaben sind teils mit Vorgänger Versionen entstanden und beim watchdog hatte ich mal ms von int auf double geändert.




    Edit:
    Teil3: Rezept gegen Mikroruckler bei vdpau h264 mit xine *

  • Hallo,


    Klingt sehr interessant. Werde ich testen und hier posten.
    Was mir zu dem Thema aufgefallen ist.
    Es tritt bei mir auch auf normalen Sendern auf. Nicht nur auf HD.
    Es tritt allerdings niemals bei einer Wiedergabe auf.


    Jedenfalls ist es bei mir so. Wie sieht es bei Euch aus?




    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

    2 Mal editiert, zuletzt von Dirk () aus folgendem Grund: versehentlich ein beitrag u weit unten editiert

  • Hallo pixelpeter, was du schreibst klingt nach etwas anderem. Hier geht es um Hänger, die nur bei HD (H264) auftreten (und bei Aufnahmen genauso wie beim live sehen). Für andere Hänger gibt es viele Ursachen. Vielleicht wäre es sinnvoll, wenn du für dein etwas anderes Problem einen eigenen Thread aufmachst ;) .

  • Hmm... ich hatte beide (profiling+watchdog) Patche schon am laufen, einzeln und zusammen. Hatte dabei aber eher den Eindruck, dass die Hänger mit Patch häufiger vorkamen. Ich probiers nochmal aus, eventuell stimmt ja deine Beobachtung....


    Gruß
    iNOB

  • Gestern mit Patch wieder einen Hänger auf SAT1HD gehabt. Scheint wohl die Ursache nicht zu beseitigen....shit.


    Gruß
    iNOB

  • Interessant. Hat der watchdog was ins syslog geschrieben? Falls ja, wäre ich interessiert zu sehen, was darum herum im syslog steht. Hast du überhaupt irgendwelche watchdog Meldungen im syslog (grep -e render messages)?
    Ich habe seit nun 3 Monaten keine Hänger mehr gehabt, wobei nur der watchdog patch drin ist. Sonst dauert es nicht lange, bis ein Hänger kommt. Ich gucke aber nur die ÖRs.

  • Gestern mit Patch wieder einen Hänger auf SAT1HD gehabt. Scheint wohl die Ursache nicht zu beseitigen....shit.


    Gruß
    iNOB


    ich kenne die Hänger wie du ausschließlich von hdplus, dort auch vor allem bei Liveevents, also volle Datenrate. Ich hab das weder bei Sky HD noch bei ÖR HD und auch nicht bei Aufnahmen beobachten können. Es handelt sich wie gesagt um Mikroruckler, treten vieleicht 2-5x die Stunde und meist bei Live Events auf. X Faktor ist zB. so eine Sendung wo dieses zu beobachten ist. Dieses Nachlaufen wie weiter vorn beschrieben ist hier nie aufgetreten.


    Ich hab im selben Zusammenhang auch mal bei sehr dynamisch Bildwechseln extrem leichte Klötzchenbildung für den Bruchteil einer Sekunde wahrgenommen, daher komme ich so langsam zu der Theorie das die verwendete nvidia HW einfach zu so einer Spitze nicht genug Reserven bereithält. Es ist auch GPU temperaturtechnisch leicht nachzuvollziehen, das NICHTS die GPU so extrem belastet wie hdplus 1080i, besonders dann wenn sie den Datenhahn voll aufdrehen, keine ÖR HD, kein ORF HD und auch kein Sky HD ruft diese GPU Temperatur hervor....


    Hat jemand ähnliche Erfahrungen gemacht?


    PS: ich teste das mit einem anderen User demnächst noch einmal mit einer GT430, bin sehr gespannt auf das Ergebnis.


    Gruß
    CKone

    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



  • CKone
    Stimmt, jetzt wo du es sagst... auf ARD/ZDFHD, SkyHD oder ORFHD konnte ich die kurzen Hänger (<1s) auch noch nie beobachten. Aufnahmen sind generell ruckelfrei. Könnte schon an HD+ liegen, zumal ich zum Testen unbewußt immer VOXHD oder kabeleins HD hergenommen habe, da sich hier der Fehler am ehesten zeigt. Das Decrypten schließe ich als Fehlerursache aus, da sich keine Auffälligkeiten diesbezüglich in den Logs zeigen.


    Den letzten Ruckler habe ich übrigens bei VoiceOfGermany auf Sat1HD festgestellt, womit sich auch das mit deinen Beobachtungen deckt.


    Gruß
    iNOB

  • Meinst du mit Mikroruckler denn die hier beschriebenen Hänger von 1 bis 2 Sekunden?


    nein, ich denke ich bin eher bei iNOB und <1s und nur extrem selten, also Jammern auf ganz hohem Niveau.

    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



  • Hm, die Ursache für die Hänger, um die es hier geht, liegt daran, dass vdp_decoder_render zu lange braucht.
    Habt ihr den bei euren Rucklern und mit watchdog oder profiling entsprechende syslog Einträge?

  • Hallo,


    Bitte mal folgendes testen:


    Bei mir laufen aktuell 5 vdr's auf verschiedensten Plattformen bei ansonsten identischer Konfiguration.
    Zwei sind nicht von dem Problem betroffen, auf der atom Plattform habe ich die Hänger auch auf SD Kanälen.
    Im allgemenen treten diese Hänger sehr selten aber doch immer wieder mal auf.


    Heute habe ich auf dem Atom hohe IO Last erzeugt und hatte sofort diesen Hänger.
    Ich habe ich mir mal genauer angesehen was bei den zwei ohne dieses Problem anders ist.
    Nach langer Suche bin ich darauf gestgoßen, dass auf den fehlerfreien der Ordner /tmp im tmpfs liegtv, bei den anderen nicht.
    Unter /tmp liegen ja die xine Sockets.
    Ich habe jetzt mal auf allen Systemen tmp als tmpfs eingehangen und werde das mal beobachten.


    Könnte das Problem damit zusammenhängen?



    Peter

    VDR1: ASUS N100I-D D4 + IP TV Plugin + Flirc + softhddevice-git VAAPI + vdr-2.6.5 + 3 weitere Plugins + Debian Bookworm via M2 + Kernel 6.1.0


    VDR2: ASUS AT3IONT-I + PCTV USB Stick 461e + Nvidia 340.108 + Flirc + softhddevice-git + vdr-2.6.4 + 8 weitere Plugins + Samsung U70 + Debian Bullseye via SSD + Kernel 6.3.6 + LG 55 Zoll

  • Nein. Hab bei mir das tmp-Verzeichnis in tmpfs liegen und trotzdem den Fehler, wenn auch nur sporadisch.


    Gruß
    iNOB

  • Kann ich sehen/konfigurieren wo vdr-sxfe seine local pipe anlegt?
    In /tmp sehe ich bei mir nichts. Habe aber gerade dazu festgestellt das es bei mir nicht als tmpfs gemounted ist.


    Edit: Sehe gerade


    Code
    [19046] [input_vdr] Connecting (data) to pipe:///etc/vdr/plugins/xineliboutput/pipes.3317/pipe.0


    bzw.


    Code
    lsof -c vdr-sxfe | grep pipe
    vdr-sxfe 17971 root 18r FIFO 8,1 0t0 2393707 /etc/vdr/plugins/xineliboutput/pipes.3317/pipe.0 (deleted)


    In dem Verzeichnis sehe ich aber zumindest über ein "ls -al" die pipe auch nicht. Das deleted beim lsof wundert mich auch ein bischen.


    Bleibt noch die Frage, lässt sich das per config ändern wo er die pipe hinlegt?

  • Per config lässt es sich anscheinend nicht ändern.


    frontend_srv.c

    Code
    cString Base(cPlugin::ConfigDirectory());
    if(*Base) {
    m_PipesDir = cString::sprintf("%s/xineliboutput/pipes.%d", *Base, getpid());
    m_AllowedHostsFile = cString::sprintf("%s/" ALLOWED_HOSTS_FILE, *Base);
    } else {
    LOGMSG("cXinelibServer: cPlugin::ConfigDirectory() failed !");
    m_PipesDir = cString::sprintf("/tmp/xineliboutput/pipes.%d", getpid());
    m_AllowedHostsFile = cString::sprintf("/video/" ALLOWED_HOSTS_FILE);
    }


    Ich werd es mal im Code umbiegen auf /tmp und das ganze per tmpfs einhängen.

  • Subjektiv ist es besser geworden. Längere Log-Auswertungen um es objektiv zu beurteilen habe ich aber leider nicht.


    Vorher hatte ich nur sehr selten mal die kurzen Hänger, die dann zu einer Art schnellem Vorlauf geführt haben. Das konnte ich in den letzten Tagen nicht mehr beobachten.


    Wer es selbst mal ausprobieren möchte, müsste xineliboutput patchen.


    frontend_svr.c
    Zeile

    Code
    m_PipesDir = cString::sprintf("%s/xineliboutput/pipes.%d", *Base, getpid());


    ändern in

    Code
    m_PipesDir = cString::sprintf("/tmp/xineliboutput/pipes.%d", getpid());


    Dazu natürlich per mount prüfen ob /tmp wirklich als tmpfs eingehangen ist.

  • Interessant wäre ja auch ob es nur bei schwächeren graka zu dem Problem kommt. Ich bin mir mittlerweile ziemlich sicher. Wie könnte es sonst sein dass einige keine Probleme haben...


    Gibt es jemanden mit zb einer gt430 der auch die probleme hat?

  • Das Problem ist existent auf ATOM-Boards mit ION-Chipsatz und auf Systemen mit GT210 Grakas. Würde mich wundern, wen das auf einem System mit GT430 anders wäre.


    Gruß
    iNOB

  • Auf meinem zotac Atom mit gt218 tritt es eben auch auf. Ich vermute jedoch dass es bei besserer Hardware nicht Auftritt weil ich mit anders nicht erklären kann warum es bei einigen öfter (bei mir), bei anderen kaum und bei wieder anderen (angeblich) gar nicht Auftritt...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!