Beiträge von mm85

    ich bin noch nicht dazugekommen mich der Sache wieder anzunehmen, da das ganze so "nebenher" läuft. Werde es aber sobald ich etwas Zeit habe testen. YV12 wäre in meinem Fall nicht das Problem, da anschließend eh in H.264 encodet werden soll. 4:2:2 ist was die Abspielgeräte (ich möchte möglichst viele abdecken - vom Smartphone, PC, Tablet, etc.) nicht das Ideale in Hinblick auf Kompatibilität.

    Was müsste ich als Laie auf dem Screenshot erkennen? Dass das Bild zwischen TGMC Interlaced und QTGMC 50p nicht pixel-identisch ist? Wäre das nicht zu erwarten? Lässt sich aus dem Screenshot etwas bzgl. der Qualität ableiten?

    Ein 50p Master kann/sollte man behalten, um alle möglichen Versionen daraus erzeugen zu können.

    Ich würde in Interlaced capturen (oder machen lassen wie in meinem Fall). Das ganze als uncompressed AVI zur Archivierung. Alle anderen Schritte sind m.M. nach Verlustbehaftet - auch das Deinterlacing. Wer sagt uns dass das Deinterlacing in 15 Jahren nicht besser ist als heute? (schauen wir doch mal 15 Jahre zurück - ich denke Ihr wisst was ich meine.)

    Auch im Codec mach mich mal unbeliebt :D - HuffYUV wird hier immer mit einer ZIP-Datei verglichen. Das stimmt grundsätzlich - der Codec ist lossless. Nur was man bedenken sollte ist, dass ZIP ein Industrie-Standard ist, welcher auf allen möglichen Plattformen implementiert ist. Davon ist HuffYUV leider noch Meilenweit entfernt (gibt es den Codec auch für Linux, Mac, etc?). Für die Langzeitarchivierung würde ich daher nur uncompr. AVI nehmen.

    So kann ich auch in 20 Jahren ggf. die "optimierung" des Quellmaterials nach dem dann aktuellen Stand der Technik machen und habe hierfür meine uncrompressed, interlaced Dateien... außer Speicherplatz kostet das ganze nichts (und der ist heute sehr billig für Archivierung).

    Zu später Stunde bin ich viell. auf eine Fährte gestoßen. Mir kam der Gedanke ob es viell. nicht an AVISynth sondern an Virtual Dub liegt. Daher habe ich jetzt mal MeGUI verwendet und habe aus meinem Avisynth Script eine H.264 MP4 Datei erstellen lassen.

    Ich hab den Vorgang mehrfach wiederholt - in der Datei die MeGui erzeugt hat, sind keine Framefehler zu finden. Macht das für euch Sinn?

    So ein Update: Ich habe jetzt mein Script etwas umgebaut anhand dem Beispiel von LigH:

    Code
    SetMTMode(3, 4)AVISource("Input.avi")Preroll(video=50, audio=2.0)AssumeTFFSetMTMode(2)ConvertToYV12(interlaced=true)Crop(12,2,-12,-8)AddBorders(12,2,12,8)QTGMC( Preset="slow", FPSDivisor=2 )return(last)

    Leider immer noch fehlerhafte Frames:

    [Blockierte Grafik: https://dl.dropboxusercontent.com/u/15500634/forum.gleitz.info/QTGMC_MT_FrameError4.jpg]

    Fehler tritt auch mit mt_masktools-26.dll vom 18.04.2011 auf. Im VirtualDub habe ich als Decompression und Output Farbraum natürlich YV12 angegeben.... Hat noch jemand Ideen?

    Die neuen DLLs sind ohne Zweifel schneller - daher würde ich dort gerne aufsetzen, allerdings ist der Fehler der gleiche wie bei den alten DLLs. Ich werde die kommenden Tagen das ganze auf einem anderen PC noch versuchen, wobei ich befürchte das das Ergebnis das gleich sein wird.

    Es mach auch keinen Unterschied ob meine Input.avi Sound hat oder nicht - der Fehler tritt bei beiden auf sobald MT aktiviert ist.

    Hier noch die Infos aus MediaInfo zu meiner Ausgangsdatei:

    Also dann lieber schnell und mit Fehlern? Hast du wenigstens mal die Geschwindigkeit mit den neueren DLLs gemessen und mit der alten Konfiguration verglichen? Hast du dir mal ueberlegt wieviel Zeit du verschwendest mit dem Rumprobieren mit AVSMT?

    Alt: 5-6 fps, Neu 8 fps, MT: 25fps

    Die Werte sind alle noch nicht top. Das finale encoden mit allem drum und dran werde ich auf einer leistungsstärkeren Maschine machen. Dort habe ich mehr als genug CPUs und Kerne, sodass MT hier sinnvoll wäre.

    Ich sehe gerade das du laut deiner Auflistung gar nicht AviSynth MT benutzt:

    Sollte aber sein:

    Bitte um Aufklärung.
    Zuerst die "normale" AviSynth Installation, dann die modifizierte avisynth.dll (MT) Version ins C:\Windows\SysWOW64\ Verzeichnis kopieren/einfügen.

    Sorry da hab ich einen Fehler beim Abschreiben gemacht - hab die avisynth.dll vom 20.02.2015 schon die ganze Zeit im Einsatz. Habs in meinem ursprünglichen Beitrag angepasst. Danke für den Hinweis.

    Mit QTGMC 3.33 gleicher Fehler:

    [Blockierte Grafik: https://dl.dropboxusercontent.com/u/15500634/forum.gleitz.info/QTGMC_MT_FrameError3.jpg]

    Gearbeitet wurde in YV12..... kannst du mir mal deine DLLs schicken / posten?

    Ich habe mit Avisynth MT/QTGMC auch manchmal Probleme. Versuch mal folgendes:

    1. Loesche diese DLLs:


    2. Kopiere diese in das Plugin-Verzeichnis

    Die MVTools2 Version ist intern multi-threaded und somit deutlich schneller auch ohne Avisynth MT.

    Habe es nun probiert auch mit ConvertToYV12(interlaced=true) . Jetzt läuft AVISynth - aber der Fehler bleibt. Ich habe wieder verschobene / kaputte Frames wie in meinem ersten Post (aber die FPS ist höher :-D)

    Ich habe mit Avisynth MT/QTGMC auch manchmal Probleme. Versuch mal folgendes:

    1. Loesche diese DLLs:


    2. Kopiere diese in das Plugin-Verzeichnis

    Die MVTools2 Version ist intern multi-threaded und somit deutlich schneller auch ohne Avisynth MT.

    Mit diesen Dateien erhalte ich einen Fehler von QTMGC:

    [Blockierte Grafik: https://dl.dropboxusercontent.com/u/15500634/forum.gleitz.info/Interleaved2Planar.jpg]

    Ohne QTGMC gehts - aber da tritt der Fehler ja nicht auf....

    Bei der aktuellsten MT-Version gab es noch eine Korrektur, die defekte Audio-Streams betraf; gibt es das Problem seitdem, oder auch noch mit einer vorherigen Version?

    Hilft eventuell die Verwendung eines längeren Preroll()?

    Das ist mein erstes Projekt mit AVISynth, daher weis ich nicht ob es vorher schon Probleme gab :-D. Preroll werde ich versuchen....

    @Grucho2004: Danke für die Dateien ich werde das ganze heute Abend ausprobieren. Ich habe in der Mittagspause noch ein paar Tests gemacht. Jetzt war der Fehler leider nicht mehr so eindeutig wie gestern Abend. Aber es gab auch jetzt Frames, welche dort nicht hingehören:

    [Blockierte Grafik: https://dl.dropboxusercontent.com/u/15500634/forum.gleitz.info/QTGMC_MT_FrameError2.jpg]

    Frame 604 ist aus einer Einstellung welche ca. 20 Frames später erst beginnt??? Es scheint mir so als würden die Threads einzeln ihre arbeit verrichten, aber beim zusammensetzen passt etwas nicht.

    Ich werde die neuen / alten Dateien probieren und berichten...

    Hallo zusammen,


    ich kämpfe seit ein paar Stunden mit AVISynth MT und QTGMC. Ich habe Videos in uncompressed AVI YUY2. Diese lade ich mit AVISynth in VirtualDub (Versionen stehen unten). Sobald ich in der zweiten Zeile meines .avs Scriptes bei SetMTMode mehr als einen Thread angebe, kommt es zu einem merkwürdigen Fehler:


    [Blockierte Grafik: https://dl.dropboxusercontent.com/u/15500634/forum.gleitz.info/QTGMC_MT_FrameError.jpg]


    Der Fehler ist reproduzierbar und folgender Zusammenhang ist mir aufgefallen:
    1 Threads: SetMTMode(3, 1) -> kein Fehler
    2 Threads: SetMTMode(3, 2) -> Fehler bei Frame 166
    2 Threads: SetMTMode(3, 3) -> Fehler bei Frame 331
    4 Threads: SetMTMode(3, 4) -> Fehler bei Frame 332


    Der Fehler tritt nur auf wenn QTGMC aktiviert ist - kommentiere ich die Zeile im .avs Script aus, passiert dies nicht. In VDub habe ich folgende Konfiguration für die Tests verwendet:
    - Keine VDub Filter
    - Full processing mode
    - Input Color YUY2
    - Output Color YUY2
    - Compression: uncompressed


    Hat hier jemand einen Tipp wie ich das hinbekomme? Ohne MT ist das ganze sehr sehr langsam - ich w¸rde schon gerne MT nutzen, nur mit defekten Frames bringts natürlich auch nichts.


    Ich habe folgende Installationsdateien verwendet:
    QTGMC 32-bit Plugins [Vit-Mod]
    SEt AviSynth 2.6 MT 2015.02.20 (avisynth_20150220.7z)
    AviSynth 2.6.0 RC1 (AviSynth_150114.exe)
    VirtualDub 1.10.4 (build 35491) 32bit


    AVISynth PlugIns:
    AddGrainC.dll 1.5.2.0 19.04.2011
    ChromaShift.dll ------- 04.11.2003
    dfttest.dll 1.8.0.0 19.04.2011
    DirectShowSource.dll 2.6.0.2 13.01.2015
    EEDI2.dll 0.9.2.0 07.06.2006
    eedi3.dll 0.9.1.0 23.07.2010
    FFT3DFilter.dll 2.1.1.0 19.04.2011
    mt_masktools-25.dll ------- 19.04.2011
    mvtools2.dll 2.5.11.2 18.04.2011
    nnedi.dll 1.3.0.0 20.09.2007
    nnedi2.dll 1.6.0.0 23.07.2010
    nnedi3.dll 0.9.4.0 09.09.2011
    RemoveGrainSSE2.dll ------- 19.04.2011
    RepairSSE2.dll ------- 19.04.2011
    SSE2Tools.dll ------- 11.04.2005
    TCPDeliver.dll 1.0.0.6 21.12.2008
    TDeint.dll 1.1.0.0 19.04.2011
    VerticalCleanerSSE2.dll ------- 19.04.2011
    yadif.dll 1.7.0.0 08.10.2009
    QTGMC-3.32.avsi ------- 07.06.2011
    colors_rgb.avsi ------- 05.07.2005


    C:\Windows\SysWOW64\avisynth.dll 2.6.0.5 20.02.2015
    C:\Windows\SysWOW64\fftw3.dll ------- 18.07.2009
    C:\Windows\SysWOW64\libfftw3f-3.dll ------- 18.07.2009

    So hier mal wieder ein Update mit einem Vergleich bzgl. den Farbfahnen:

    [Blockierte Grafik: https://dl.dropboxusercontent.com/u/15500634/for…/Farbfahnen.jpg]

    https://dl.dropboxusercontent.com/u/15500634/for…/Farbfahnen.jpg

    Aufnahmen von links nach rechts:
    - S522_RAW
    - S522
    - 5.200
    - MD835
    - V8000 Edit=On

    Wie Goldwingfahrer schreibt hängt die Qualität sehr stark von der Aufnahmesituation ab. Das war damals in den 90ern eine Amateur-Kamera. Aber im wesentlichen geht es um den Bildinhalt - HD Material hatte ich auch nie erwartet.
    Es macht auch wirtschaftlich keinen Sinn, jeden einzelnen Clip mit einem anderen Zuspieler zu digitalisieren. Ich denke so wie in den anderen Threads diskutiert bleibe ich beim 522_RAW und uncompressed AVI Format.


    "Irgendwie habe ich das Gefühl dass mir der Micrsoft-eigene msyuv Farbfahnen/ leichte Schlieren ins Bild zaubert."

    Meinst du das Problem entsteht beim capturen / speichern oder erst beim Abspielen? Die msyuv.dll ist lt. MS nur für die Farbkonvertierung in RGB zuständig - wäre also somit nur beim Playback involviert. Sieht man die Farbfahnen auf einem Screenshot? Wenn ja, kann ich anbieten den gleichen Screenshot bei mir unter Mac OS X zu machen - viell. ist ein Unterschied sichtbar. Oder bringt das nichts?

    Danke für die Antworten! Ich habe mich am WE noch weiter mit dem Thema beschäftigt. Auch wenn es schwer Nachvollziehbar scheint: Mein Entschluss fällt auf uncompressed AVI - es sei denn jemand hat Einwände bzgl. der Qualität. Der benötigte Speicherplatz ist in meinem Anwendungsfall kein Problem. Die Gründe:

    - Sicherheit und Plattformunabhängigkeit da uncompr. AVI auf jeder Plattform gelesen werden kann.
    - Unabhängig von "OpenSource" Entwicklung wie bei HuffYUY_MT
    - Höhere Sicherheit bei einer beschädigten Datei / Wiederherstellung - bei komprimierten Daten ist die Wahrscheinlichkeit größer, dass die Daten durch einen Strukturellen Fehler nicht mehr rekonstruierbar sind

    Ich möchte alte Familien Videos digital archivieren. In diesem Thread geht es nicht um ein Format für den "täglichen" Gebrauch, sondern zur Archivierung. Technisch sollen die Filme auf zwei unterschiedlichen Festplatten an zwei unterschiedlichen Standorten aufbewahrt werden. Ziel sollte es sein, dass die Videos in einem Format gespeichert werden, welches hoffentlich auch in 20 oder noch späteren Jahren relativ Problemlos gelesen und weiterverarbeitet werden kann.
    Falls relevant das Video-Material ist YUY und natürlich interlaced. Speicherplatz ist ein Faktor, aber nur ein sehr sehr kleiner / unwichtiger solange wir pro Minute unter 3,5GB bleiben.

    Gibt es Vorteile von anderen Codecs?
    Hat uncompressed AVI Nachteile?

    PDF hab ich mir angeschaut, werde aber erst am WE dazukommen mich in Ruhe damit auseinanderzusetzen. Jetzt gings mir einfach mal um einen schnellen Test und dachte ich Teile die Ergebnisse mit dem Rest. Zufrieden bin ich mit den Einstellungen bzw. dem Ergebnis auch noch nicht.

    Das Bild mit dem Jungen ist eine heikle Sache - das Vergessen wir lieber wieder schnell :D. Daher müssen wir / ich mit Bildern ohne Personen vorlieb nehmen. Unabhängig davon dachte ich mir, dass es viell. für den ein oder anderen der wie ich nicht so tief im Thema ist, hilfreich ist, wenn immer das selbe Motif verwendet wird. Die Einstellungen müssen eh für jede Aufnahmesituation einzeln angepasst / vorgenommen werden - hier gibts leider kein "one-Size-fits-All"....