Tool zum finden von Bildfehlern in Videostreams. Gibts sowas?

  • Hin und wieder schleichen sich bei mir Bildfehler während des encodes ein. Die sind nicht reproduzierbar, und rühren meist daher, das der Rechner grade irgendwo mal für ein paar Sekunden "hängenbleibt". An der Stelle, wo der encode grade dran ist, ist dann oft (gefühlt 50%) ein Bildfehler, der mich natürlich stört.


    Mit nur 2gig Ram passierte das quasi immer, wenn der physische ram zu klein wurde, das problem hat sich jetzt mit 8gig erledigt, aber es ist immer noch nicht ganz weg.


    2 Fehlerarten sind konnte ich ausmachen:
    1) Es schleicht sich ein Frame (oder auch nur Teile eines Frames) ein, der da gar nicht hingehört. Wenn es nur ein Teil eines Frames ist, ist der seltsam mit dem original überlagert.
    2) Manchmal ist zwar alles in der richtigen Reihenfolge, aber Teile eines frames (oder auch ganze Frames) haben einen seltsamen Grün- oder Rotstich.


    Ich benutze jeweils aktuelle versionen von
    ffvideosource
    Mdegrain
    fft3dgpu
    removegrain


    Der Fehler trat bei diversen avisynth-versionen auf, auch den offiziellen Builds, dennoch vermute ich den Fehler bei der Avisynth-bearbeitung, denn wenn ich mal einfach eine .mkv an x264 verfüttert hab, habe ich den fehler noch nicht gesehen. Jedoch hab ich das nicht sooo oft gemacht, um da wirklich sicher zu sein. Der Fehler ist ja leider nicht provozierbar, sondern tritt auf, oder eben nicht...


    Bisher schreib ich mir immer die Framenummer auf, wo der grade ungefähr dran war, und schau es mir nachher aufmerksam an, und wenn da was nicht stimmt, wird der Teil repariert. Dabei kann einem aber mal was durch die lappen gehen, was mich dann bei einem Videoabend ziemlich fuchsen würde...


    Gibt es eine Möglichkeit diese Suche nach Bildfehlern zu automatisieren? Irgendein tool, was nach "ungereimtheiten" im Stream sucht? Es geht immer nur um 1 Frame, was sich DEUTLICH von allen anderen Unterscheidet, daher sollte das THEORETISCH algorithmisch auffindbar sein. Hat jemand schonmal sowas gesehen?

  • Wenn es ein Datenfehler wäre, der den Decoder zum Absturz bringt oder zumindest einen internen Fehlerstatus provoziert, könnte VirtualDub mit der Funktion "Scan video stream for errors" im Video-Menü eventuell helfen, vielleicht sogar selbst dann, wenn die Decodierung über AviSynth läuft (aber die Nutzung der VirtualDub-Import-Plugins von {moitah oder} fcchandler könnte vielleicht eher bemerkbare Fehlerzustände auslösen).


    Wenn aber der Decoder stabil bleibt, dann müsste man direkt aufeinander folgende Bilder miteinander vergleichen und sehr kurze Unterschiede (Dauer von 2 Frames, weil hier zum vorherigen und nachfolgenden Bild je ein "Szenenwechsel" passiert) suchen. Das ginge vielleicht mit einer Frametyp-Analyse der 1st-pass-Statistik, wenn das möglich ist (kenne aber so gerade kein Programm dafür), oder mit der Logdatei-Ausgabe von Compare zwischen "dem Clip" und "der Kopie des Clips, dem man mit Trim das erste Bild weggeschnitten hat". Das dann vielleicht als CSV in eine Tabellenkalkulation laden, als Graph darstellen und nach spitzen Nadeln schauen ...

  • Und wenn Du dann weißt, dass im fertigen Encode der Frame Nr. 124678 fehlerhaft ist, dann machst Du ... was ?



    Zitat

    Dabei kann einem aber mal was durch die lappen gehen, was mich dann bei einem Videoabend ziemlich fuchsen würde...


    Schon klar, Fehler ist Fehler. Aaaaber ...


    Zitat

    Es geht immer nur um 1 Frame


    ... das is' ja nu nix, was den Videoabend zum kompletten Disaster werden lässt. Die meisten Zuschauer bemerken so etwas erst gar nicht.



    - Könnte (muss aber nicht) mit ffvideosource zusammenhängen. Ich trau' dem Ding nie so richtig über den Weg ...


    - Speicherprobleme: vielleicht kann man am Avisynth-Script etwas "drehen". Vor allem aber empfiehlt es sich -- ich vermute dass Du zumindest mit 720p, wenn nicht gar mit 1080i/p herumwerkelst -- eine Piping-Lösung Avisynth-->x264 zu verwenden, was das Problem der 2GB-Grenze auf jeden Fall deutlich entschärfen sollte.

  • Zitat

    Und wenn Du dann weißt, dass im fertigen Encode der Frame Nr. 124678 fehlerhaft ist, dann machst Du ... was ?


    Ersetzen mit dem gleichen Frame aus dem 2.Capturestream.
    Ist schon länger bekannt dass Huffyuv und Lagarith da auch ab und an lustig verpixelte Frames zaubern können.

    Zitat


    Die meisten Zuschauer bemerken so etwas erst gar nicht.


    Exakt,hier fällts auch nur auf wenn das Codiertool was meckert.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Klar, der fehler ist nicht groß, aber ich ärgere mich über sowas... sonst wahrscheinlich keiner... aber ohne eine latente Grund-Unzufriedenheit wird man ja auch nicht permanent besser^^


    Zitat

    Und wenn Du dann weißt, dass im fertigen Encode der Frame Nr. 124678 fehlerhaft ist, dann machst Du ... was ?


    Ich mach nur avc(x264) in mkv.
    Dann schneide ich mit mkvmerge das betroffene stück raus, füge in die source.avs ein passendes "trim(x,y)" an, mache den Teil neu, und setze die Soße am Ende wieder zusammen. Funktioniert prima, wenn mkvmerge halt syst*****ingt auch nicht beliebig schneiden kann, sondern nur an IDR-Frames. Das macht es aber offensichtlich richtig, denn es gibt keine Bildfehler.


    @piping:
    mach ich im moment notgedrungen wei ich das avisynth64 noch nicht ans Laufen brachte, mit Lord Mulders x64-gui. Das ist zwar etwas off-topic, aber wenn ich das gleiche Script von avisynth32 mit avisynth64 bearbeite, dann messe ich Geschwindigkeit in sekunden pro frame ;-) Grund noch nicht rausgefunden. Ich hab aber 8gig ram, muss ich da immer noch pipen?


    Das Skript sieht so aus: (mit trim beispiel)

    Code
    1. SetMTMode(5)FFVideoSource("video.mkv")AssumeFPS(23.976)ConvertToYV12()Crop(0,138,0,-142)SetMTMode(2)super = MSuper(pel=1, sharp=1) backward_vec3 = MAnalyse(super, isb = true, delta = 3, overlap=4, blksize=16, truemotion=false) backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4, blksize=16, truemotion=false) backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4, blksize=16, truemotion=false) forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4, blksize=16, truemotion=false) forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4, blksize=16, truemotion=false) forward_vec3 = MAnalyse(super, isb = false, delta = 3, overlap=4, blksize=16, truemotion=false) MDegrain3(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD = 400)fft3dgpu(beta=1, sigma=0, plane=4, bt=-1, mode=1, sharpen=0.5, precision=2, bw=64, bh=64, degrid=1, wintype=1)#trim(114463,-1076)


    x264 aufruf ist:

    Code
    1. x264-x64.exe --preset slow --tune film --crf 18.0 --ref 8 --bframes 8 --output "output.mkv" "source.avs"


    LigH:
    Danke! Wird demächst getestet, Update kommt!

  • @Dispatcher:


    Fehler!



    Man darf keine GPU-Filter unter Multithreading ausführen. Weder SetMTmode, noch MT().
    (Der GPU-Filter wird nur in einem Thread "richtig" arbeiten, was in den restlichen Threads produziert wird ist inkorrekt.)


    Du müsstest da zumindest ein SetMTmode(5) direkt vor den fft3dgpu setzen, und dann wieder SetMTmode(2) direkt danach.


    Oder, was ich in diesem Fall vorziehen würde: Statt FFT3dGPU gleich den "normalen" FFT3dFilter nehmen. Der hat mit Multithreading nämlich keine Probleme.

  • mysteriös... ist das normal, das es unter 32bit MT so klappt, aber unter 64bit nicht? Würde doch sagen, wenn diese Probleme auftauchen, dann bei beiden varianten, oder?


    @fft3dfilter: Ich möchte so viel cpu wie möglich für den encode nutzen, und fft3dfilter ist nunmal cpuintensiv, daher entfällt das. Hier wird das ding auch nur zum nachschärfen nach der aufwändigen Rauschfilterung genommen.


    Wie siehts bei 64bit mit piping aus? Notwendig?

  • > ist das normal, das es unter 32bit MT so klappt, aber unter 64bit nicht?


    Keine Ahnung. 64bit Avisynth nehm ich nimmer ... ist instabil, hab keinen Bock auf völlig zufällige Abstürze.


    Unter 32bit hab ich mit einem Differenz-Script nachgewiesen, dass GPU-plus-multithreading irgendwas produziert, aber nicht das was es soll.


    Piping sollte unter 64bit nicht nötig sein, die 2GB-Grenze gibt's da ja nicht. Dafür musste halt fleißig beten, dass es nicht aus reiner Laune zwischendurch abstürzt.

  • Blöderweise habe ich heute morgen alle meine Beispiele mit den Fehlern gelöscht, daher muss ich jetzt erstmal wieder welche auflaufen lassen, ehe ich mir die Vorschläge aus LigHs erstem Beitrag genauer anschauen kann. Im Moment hab ich aber nen Kampf mit avisynth64, denn ich gleich in einem anderen Thread beschreibe.

  • Die Abarbeitung in versch.Schritte aufteilen.
    Statt in einem Script.


    Es sieht auch so aus,gemäss erstem Beitrag,dass da Windows wärend der Scriptabarbeitung,was auf die HDD schreibt.
    Ich vermute mal hier wird Win-7 eingesetzt.


    Indizierung auf dieser Captureplatte abschalten,unteren Haken rausnehmen,wie im Bild gezeigt.
    Defender nicht auf "manuell" sondern unter Dienste deaktivieren.
    Ev.noch....System / Aufgabenplanung / Aufgabenplanungsbibliothek / Microsoft / Windows / Diagnosis
    Hier nun den Eintrag "Scheduled" deaktivieren.


    Ev.auch mal das Tool DPC Latency Checker laufen lassen und beobachten.


    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Sicher, kann man machen. Allerdings reden wir aktuell nicht von SD-Briefmarkengröße, sondern von 1080p FullHD. Und es ist nicht immer praktisch, wenn man für ein 2-Stunden-Video cca. 200 GigaByte an temporären Daten zu schreiben hat...


    Ist es nicht viel handlicher, wenn man einfach ein korrektes Avisynth-Script schreibt, anstatt eines fehlerhaften? Dann braucht man sich den Stiefel mit "Temporärvideo so groß wie ne ganze Festplatte" nicht anzuziehen. ;)

  • Unbedingt...


    Aber dann muss man auch die Ursache für den Fehler verstehen und wissen, wie man ihn vermeiden kann. Und wenn fehlerhafte Parallelverarbeitung die Ursache ist, dann muss man sich erst mal in die Materie eindenken können. Was "Reentranz" ist, wissen teilweise noch nicht mal einige Programmierer ... :rolleyes:

  • Zitat

    Ist es nicht viel handlicher, wenn man einfach ein korrektes Avisynth-Script schreibt, anstatt eines fehlerhaften?


    Einfacher...ja..eigentlich schon...aber leider nicht jedermanns Sache.
    Darum meinte ich ja auch das Script "unterteilen" ev.kommt man so auf den Fehler.
    Ist ja nur mal für diesen Fall vorzunehmen.
    Hat man den Fehler gefunden...Didée hat ihn berichtigt....ists ja gut.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Hallo zusammen,


    ich hab jetzt LigHs Vorschlag aus dem 2. Beitrag dieses Threads einmal ausprobiert, und der funktioniert so wie er soll. Danach werden die einzelbilder mit ihrem Nachfolger per compare(a,b, "logfile.log") verglichen, und die Abweichung in einem Wert gemessen.


    Kann man diese Analyse auch laufen lassen, ohne den Videostream durchlaufen zu lassen? (damit es halt schneller läuft)


    Die auftretenden Bildfehler treten deutlich als 2 aufeinanderfolgende peaks (Wert ca 50) aus dem Grundrauschen (zwischen 1 und 12) zu Tage, ebenso wie jeder Filmschnitt mit nur einem Peak. Damit ist das Entscheidungskriterium gefunden, um das automatisch auswerten zu lassen, da es jetzt ziemlich nervig ist, eine txt mit 250.000 Zeilen durchzusuchen, ob da irgendwo 2 "hohe" Werte hintereinander auftauchen.


    Kennt jemand eine einfache Methode, das automatisch auszuwerten?


    Mir schwebt jetzt grob ein Weg vor, der über Matlab läuft, und den gleitenden Durchschnitt über 2 Elemente mit dem Durchschnitt der z.B. 100 benachbarten Frames vergleicht, und bei einer abweichung von mehr als einem Schwellenwert (noch zu entscheiden), die entsprechende laufende Nummer ausspuckt... In Matlab würde ich das wohl hinbekommen. Das ist einer der Momente, indem ich mir wünschte, ich hätte mal etwas mehr programmiert... vllt. grabe ich nochmal meine rudimentären c++-kenntnisse aus^^ Damit wär es wahrscheinlich viel simpler.


    Vorschläge willkommen!


    Grüße, Dis