[gelöst] [softhddevice] Probleme mit speed up video, droping frame

    Hallo *,


    ich habe seit einiger Zeit das Problem, dass bei Benutzung von softhddevice teilweise Mikroruckler auftreten.
    Im Log zeigt sich das durch die mehrmals pro Minute auftretende Meldung "video: speed up video, droping frame_".


    Ich kann das Problem eindeutig auf den commit 0f62a521f41a44212507539a2417c28f74169491 ("improved audio skip, after channel switch") zurückführen.
    Davor gibt es keine Probleme, danach treten sie auf.


    Wenn man sich die Logs anschaut (s.u., eimal mit Problemen, einmal ohne) dann sieht man, dass das von mir eingestellte Audiodelay von 200 ms "nach unten wegläuft". Bei den neueren Version kommt dann irgendwann so ca. bei 185 ms ein "speed up video, droping frame" und dann fängt das ganze wieder von vorne an.


    Bei der alten, bei mir fehlerfreien Version scheint es eine Art Regelschleife zu geben, die ohne das droppen von Frames auskommt.


    Mein Display wird definitiv mit 50Hz angesteuert. Im Systemumfeld habe ich so ziemlich alles versucht, um das Problem zu beheben. U.a.
    - verschiedene VDR-Versionen, so gut wie ungepatcht, aktuell 1.7.32
    - verschiedene Kernel-Versionen (3.2, 3.5, 3,6), aktuell 3.5.7
    - verschiedene Windowmanager, aktuell Openbox
    - verschiende nvidia-Treiber, aktuell 304.64
    - keine doppelt belegten Interrupts für nvidia, snd-hd-intel und die DVB-C Karten
    - die Audio drift correction von softhddevice hilft nicht


    Jemand ne Idee, wo ich noch drehen kann?


    aktueller Checkout mit Debug


    commit 57af9863673b29e4322dd8336bb38696661bebc4, ohne Probleme

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    Einmal editiert, zuletzt von lostinspc ()

    Also ich vermute mal daß es mit der vorherigen Version genauso ist.
    Eine Änderung war, daß diese Meldungen eine höhere Priorität bekommen haben.
    Mit der alten Version sind die nur mit -DDEBUG ausgeben worden, mit der neuen Version
    haben die VDR Debug Loglevel.


    Ich würde den Audiodrift Code nicht verwenden, da er meiner Meinung nach mehr kaputt macht
    als repariert. Dieser arbeitet mit der Systemzeit und die wird vom VDR verändert, was die ganze
    Berechnung verfälscht.


    Die normale Berechnung basiert nur auf den PTS bzw. DTS Zeiten die mit dem Stream kommen.


    Die Frage ist passiert es auf allen Sendern?
    Wie gibst du den Sound aus HDMI / SPDIF / Analog?


    Du kannst mal eine andere Tonausgabe wählen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Hm, weiss nicht ob du das letztens mitgelesen hast, der Audiopuffer ist per default auf 336 ms, im Webif steht dann 0. Wenn man nun einen zusätzlichen Puffer von 200 ms will muss man im Webif also 536 ms eintragen. Mit 200 ms wird der Puffer verkleinert und die droping frames kommen häufiger. Ich hatte ähnliche Probleme mit den neueren Versionen, ein richtiges einstellen des Audiobuffer hat geholfen.
    Grüsse Peje

    Zitat von johns


    ...
    Ich würde den Audiodrift Code nicht verwenden, da er meiner Meinung nach mehr kaputt macht
    als repariert. Dieser arbeitet mit der Systemzeit und die wird vom VDR verändert, was die ganze
    Berechnung verfälscht.


    Audiodrift hatte ich nur probehalber mal verwendet, ist wieder ausgeschaltet.

    Zitat


    Die normale Berechnung basiert nur auf den PTS bzw. DTS Zeiten die mit dem Stream kommen.


    Die Frage ist passiert es auf allen Sendern?


    Meiner Meinung nach auf "allen Sendern" (Kabel BW, d.h. bei mir ÖR HD und FTA)


    Zitat


    Wie gibst du den Sound aus HDMI / SPDIF / Analog?


    Du kannst mal eine andere Tonausgabe wählen.


    SPDIF optisch an einen 5.1 Receiver, tritt sowohl mit PCM als auch AC3 auf. Zur Soundausgabe verwende ich den onboard chip über alsa (snd-hda-intel mit rtl ALC 887)
    Analog oder HDMI über die nvidia probiere ich am Wochenende mal aus

    Zitat


    Hm, weiss nicht ob du das letztens mitgelesen hast, der Audiopuffer ist per default auf 336 ms, im Webif steht dann 0. Wenn man nun einen zusätzlichen Puffer von 200 ms will muss man im Webif also 536 ms eintragen. Mit 200 ms wird der Puffer verkleinert und die droping frames kommen häufiger. Ich hatte ähnliche Probleme mit den neueren Versionen, ein richtiges einstellen des Audiobuffer hat geholfen.
    Grüsse Peje


    Ja, hatte ich vergessen zu erwähnen: Am Puffer habe ich natürlich auch gedreht, das mit dem "0" = default = 336 ms war mir bekannt. Ich habe verschiedene Werte bis 999 versucht, keine Änderung ...


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    Bei mir sieht es so aus (GT520/ARD HD)



    Der drop ist zwar unnötig, aber ich denke mal perfekt wirds nie werden.
    Auch die -23 sehen falsch aus, deshalb gebe ich die +2 bzw. -1 aus.
    Weil die mit in die A/V Sync Berechnung einfliessen, habe es schon 3 mal kontrolliert.


    Sind nur 2 Videoframes gepuffert, könnten aber bis zu 4 Frames (HD) und 8 (SD) sein.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Nur um meine Gedanken mal zu sortieren:


    Bei mir laufen also konstant Bild und Ton auseinander.


    Die Bildausgabe ist zu langsam, deswegen wird regelmäßig ein Bild weggeworfen -- oder der Ton ist zu schnell.


    Wenn es an der Bildausgabe liegt: Kann es dann an meiner xorg.conf liegen?
    Ich habe definitiv eine 50 Hz -Ausgabe, dass zeigt sowohl xrandr als auch der Fernseher an. Ich meine mich aber auch zu erinnern, dass ich in meiner xorg.conf modeline(s) definiert habe.
    Kann da ein leichter "pitch" herkommen, der bei mir die Probleme verursacht?


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    Ich kann zwar nicht mehr nachvollziehen, mit welchem dist-upgrade dies Problem entstanden sind, ich habe aber den Eindruck, dass das hier geschilderte Problem letztlich in Zusammenhang mit späteren "invalid PES video packet"-Meldungen steht. Es scheint so zu sein, dass softhddevice Pakete aussortiert, die eigentlich ok sind. Es gibt hier im Portal eine Reihe solcher Threads.

    4x yaVDR 0.7: ASUS P5N7A-VM // 2*TeVii S460 // Atric mit Lirc // 4*1,5TB // 7" TFT

    Im Aufbau: VDR-UHD mit nVidia GT1030 unter Ubuntu 20.04

    Zitat von r371769

    Ich kann zwar nicht mehr nachvollziehen, mit welchem dist-upgrade dies Problem entstanden sind, ich habe aber den Eindruck, dass das hier geschilderte Problem letztlich in Zusammenhang mit späteren "invalid PES video packet"-Meldungen steht. Es scheint so zu sein, dass softhddevice Pakete aussortiert, die eigentlich ok sind. Es gibt hier im Portal eine Reihe solcher Threads.


    Dass die "invalid PES video packet" oder "empty Packet" Meldungen im Zusammenhang mit den bei mir vorliegenden Problemen stehen, meine ich ausschließen zu können.


    Auch wenn es im Log-Auszug oben wegen der Debug-Meldungen nicht so gut rauskommt: Ich verliere kontinuierlich ca. 20 - 30 ms "Abstand" von Audio zu Video pro 15 sec. Das gleicht softhddevice dann durch den Framedrop aus. Ich habe also sehr regelmäßig diese Framedropmeldungen.
    Glücklicherweise "sehe" ich auch nicht _alle_ Framedrops auf dem Bildschirm, man erkennt aber doch regelmäßig leichte Ruckler.


    Die "invalid PES video packet" oder "empty Packet" Meldungen kenne ich auch, kommt vielleicht alle 10 Minuten mal vor. Auch danach mag es zu einem Framedrop kommen, dann ist der Fehler aber wieder ausgeglichen. Diese Fehler bringen IMHO das System nicht _dauerhaft_ aus dem Takt.


    johns: Du hast recht, wenn ich bei dem letzten commit ohne die frame-drop Meldungen (57af9863673b29e4322dd8336bb38696661bebc4) DEBUG setze, erscheinen diese dort ebenso. War also dort auch kein besserer Sync, sondern ist da halt im log nicht so aufgefallen.


    Trotzdem bin ich mir sicher, dass ich die framedrop Meldungen früher deutlich seltener hatte. Das Board selbst habe ich nicht geändert, GraKa habe ich zwar mal ne andere reingesteckt, macht aber bezüglich der framedrop Meldungen keinen Unterschied.
    Geändert habe ich aber meine xorg.conf (Neuer Fernseher, der alte lief zum Schluß längere Zeit mit 1280x720@50). Daher meine Frage, ob sich die Probleme bei mir vielleicht mit der Anpassung der xorg.conf eingeschlichen haben können. Bewusst zeitlich direkt in Verbindung bringen kann ich es nicht, aber möglich wäre es.


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

    Du kannst mit glxgears und v-sync testen, welche Framerate deine Ausgabe hat.
    Du kannst in xorg.conf Option "ModeDebug" "true" machen, dann sollte etwas
    mehr Informationen über den Mode kommen.


    An dem kurzen Stück Log kann ich keine Regelmässigkeit erkennen.
    Wenn du aber ein längeres Stück hast und eine Konstante Veränderung siehst,
    dann ist es sehr wahrscheinlich, das entweder die Video oder Audiorate daneben
    liegt.


    Sollte es an Audio liegen müsste 6 Kanal mehr driften als 2 Kanal.


    Anbei mal ein Patch der den Sync weniger scharf stellt.
    Der ändert aber nichts, wenn der Bildschirm mit 50.xxx Hz läuft, da dann
    der Sync immer an einem Ende hängt.


    Jeder kann die Frame Drops und Dups beobachten.
    Einfach im Menu SoftHdDevice aufrufen, dort werden die Zähler angezeigt.
    Aber keinen Schock bekommen wenn da schon hohe sind, die Dups/Drops/Missed
    zählen seit dem Einschalten und beim Umschalten, Pause oder Standby entstehen
    immer welche.


    Entscheidend ist; wärend man guckt sollte nur die Gesamt hochzählen.


    Johns

    Dateien

    greater_sync.diff 1,53 kB – 105 Downloads

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    So, passt wieder!


    Es lage bei mir tatsächlich an der Modeline


    Ich hatte mir mit cvt folgende Modeline generiert:


    Code
    # cvt 1920 1080 50
# 1920x1080 49.93 Hz (CVT 2.07M9) hsync: 55.62 kHz; pclk: 141.50 MHz
Modeline "1920x1080_50.00"  141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync


    Als ich mir die jetzt noch mal den Kommentar von wegen "49.93 Hz" angeschaut habe, wurde mir so langsam klar wo der Fehler liegt.
    Wobei cvt ja angeblich "VESA-kompatible" Timings generiert. Aber irgendwas war da ja auch, dass VESA 1920x1080 != 1080p ist ...


    Habs mir jetzt mit der Pixelclock (der 141.50) "feinjustiert"

    Code
    Modeline "1920x1080"  141.70  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync


    Damit ist das Audiodelay jetzt wie "angetackert", null Drift


    Bei dieser Gelegenheit mal wieder vielen Dank an Johne für den tollen Support und das geniale softhddevice !!!


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden