[2.0.2] Verpixelte Aufnahmen

    Seit ~ VDR 1.7.29 habe ich in Aufnahmen öfter Verpixelungen. Meistens drei bis vier mal in einer Minute und dann nichts mehr.
    Das trat erst so ab drei bis fünf gleichzeitigen Aufnahmen auf.


    Ich hatte zuerst markad und meine Festplatte (Datenengpass) in verdacht gehabt. Aber durch Zufall bin ich hier irgendwo auf eine Änderung in der transfer.c gestoßen:


    Code
    #define MAXRETRIES 	20 // max. number of retries for a single TS packet (5)
#define RETRYWAIT  	5 // time (in ms) between two retries

    Ich habe die MAXRETRIES von 5 auf 20 erhöht und nun keine Verpixelungen mehr fest gestellt. Die Werte wurden ja drastisch reduziert. Für einen sicheren Betrieb auch bei mehreren Aufnahmen schlage ich anstelle 5/5 die Werte 50/10 vor.

    MegaV0lt


    Hmm, interessanter Input, habe sporadisch bei Aufnahmen z.B. von "SYFY HD" auch kleinere Bild-Fehler und fragte mich schon woher die wohl kommen könnten. Diese Aufnahmen laufen auch meist parallel zu anderen, was Deiner Beschreibung entspricht, daher werde ich das mal testen.


    Aber warum 50/10, wenn Dein Problem doch auch mit 20/5 gelöst war? Ist es nicht sinnvoller die Werte gerade nur so stark zu erhöhen, das es keine Issues mehr gibt, ohne weiteren Impakt zu erzeugen?


    Regards
    fnu

    HowTo: APT pinning

    Die früheren Werte waren wohl im Bereich 100/10 (1000ms). Meie Tests sind noch nicht abgeschlossen. Leider habe ich sehr viele Aufgnahmen und ich arbeite mich erst langsam vor. Zumindest habe ich sei der Änderung keine Verpixelungen mehr entdeckt. Aber ein wenig Sicherheitspuffer wäre nicht schlecht. Und da es ja Jahrelang mit 100/10 ging, wäre eine halbierung auf 50/10 doch genug. Ich frage mich nur, warum der Wert so drastisch geändert wurde? Da waren Probleme ja vorher zu sehen...


    Ich glaube aber irgendwo gelesen zu haben, dass Klaus den Wert in der nächsten Version wieder erhöhen will.

    Die Werte wurden verringert, weil es bei laufenden Aufnahmen auf dem primären Device und gleichzeitgem Transfer-Mode vom selben Device zu Störungen in den Aufnahmen kam, wenn das Ausgabedevice blockierte und die Daten nicht annahm. Insofern wundert es mich schon etwas, daß hier ein Problem mit Aufnahmen durch *Vergrößern* dieser Werte behoben worden sein soll. Je größer diese Werte nämlich sind, um so höher wäre die Wahrscheinlichkeit, daß Daten in den Aufnahmen wegen Pufferüberläufen verloren gingen. Bei niedrigeren Werten würde höchstenfalls die Live-Wiedergabe im Transfer-Mode gestört werden, aber Aufnahmen sollten auf jeden Fall OK sein.
    Oder übersehe ich da was?


    Klaus

    Nun leider bin ich kein Programmiere. Fakt ist nur, dass früher (1.7.28) bis zu fünf aufnahemn liefen und gleichzeitig eine abgespielt werden konnte. Im Moment sieht es zumindestens bei mir danach aus, als ob die Erhöhung auf 20 das Problem erst mal beseitigt hat. Könnte da markad mit rein spielen? Die Verpixelungen sind immer da gewesen, wo eine andere Aufnahme startete (+ 1 Min.). Darum hatte ich auch markad in verdacht. Das ganze aber erst ab drei oder mehr zeitgleichen Aufnahmen. Es muss also irgendwas mit Bandbreite oder Last zu tun haben.


    Wie groß sind denn die Puffer? Vielleicht war die Änderung von 1.000 ms auf 25 ms auch nur einfach zu viel des Guten?

    Zitat von MegaV0lt

    Nun leider bin ich kein Programmiere. Fakt ist nur, dass früher (1.7.28) bis zu fünf aufnahemn liefen und gleichzeitig eine abgespielt werden konnte. Im Moment sieht es zumindestens bei mir danach aus, als ob die Erhöhung auf 20 das Problem erst mal beseitigt hat. Könnte da markad mit rein spielen? Die Verpixelungen sind immer da gewesen, wo eine andere Aufnahme startete (+ 1 Min.). Darum hatte ich auch markad in verdacht. Das ganze aber erst ab drei oder mehr zeitgleichen Aufnahmen. Es muss also irgendwas mit Bandbreite oder Last zu tun haben.


    Wie groß sind denn die Puffer? Vielleicht war die Änderung von 1.000 ms auf 25 ms auch nur einfach zu viel des Guten?


    Also ich versuche nochmal, es zu erklären: die empfangenen TS-Datenpakete werden in cDevice::Action() der Reihe nach jedem an diesem Device hängenden cReceiver angeboten. Einer dieser cReceiver ist der vom Transfer-Mode für die Live-Wiedergabe. Die Funktion cReceiver::Receive(), über die ein cReceiver die TS-Pakete erhält, muß so schnell wie möglich zurückkehren, um den Betrieb nicht zu blockieren. Die cReceiver der Aufnahmen kopieren lediglich das jeweilige TS-Paket in ihren lokalen Puffer und kehren danach sofort zurück. Bei cTransfer gab es mit der alten FF-Karte das Problem, daß diese sich z.B. bei HD-Daten "verschluckte" und die Daten nicht mehr sofort annahm, sondern den vorgegebenen Timeout überschritt. Da dieser recht lang war konnte es passieren, daß in einem solchen Fall einige der hereinkommenden TS-Pakete verloren gingen, was zu Störungen in den Aufnahmen führte.
    Angenommen man macht den Timeout für den Transfer-Mode unendlich kurz, so daß ein TS-Paket dem Ausgabedevice nur ein einziges Mal angeboten wird und die Funktion sofort zurückkehrt, dann kann es zu keinen Störungen der Aufnahmen kommen. Macht man den Timeout dagegen beliebig lang, so kann es u.U. wieder zu Störungen kommen. Eine Verlängerung des Timeouts kann daher meiner Meinung nach niemals zu einer Behebung von Störungen in Aufnahmen führen - eher ist das Gegenteil der Fall.
    Ich muß daher im Moment davon ausgehen, daß dein Problem durch irgend etwas anderes behoben worden ist, aber nicht durch die Vergrößerung der genannten Werte.


    Klaus

    Ich hatte mal ein ähnliches Problem, da wurden aber ring buffer overflows angezeigt, seit dem vergrößere ich immer den entsprechenden Puffer.


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

    Ich erinnere mich, dass vor der Änderung auf 20 hin und wieder "TS packet not acepted in transfermode" (sinngemäß) in Log stand. Seither nicht mehr.

    Immer noch . Mal mehr mal weniger. Ich habe jetzt im Log das gesehen:


    Blöde mehrfache PID-Wechsel während des Films! Das gibt sicher auch Störungen. Kann man das irgendwie lösen? Muss denn die Aufnahme stoppen, wenn so ein Wechsel ist?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden