VHS-Material mit VirtualDub / StaxRip restaurieren (filtern per VDF / AviSynth)

  • Wer oben eine ungerade Anzahl Zeilen wegschneidet, ändert die Halbbildreihenfolge (TFF / BFF).

    Passiert das auch bei Automatik Crop das sich die Halbbildreihenfolge ändert?
    Das hört sich ja garnicht gut an... ( Wenn man Manuell mit AviSynth cropt, muss man dann statt AssumeTFF() jetzt BFF angeben )?
    Ich dachte man muß ein Video croppen bevor man es ins gewünschte Zielformat umwandelt, um den Encoder zu entlasten ( Bei schwarzen Ränder wird zu stark gerechnet )

    Wenn ich bei StaxRip "Auto Crop" mache, bekomme ich ganz andere Zahlen als wie bei AvsPmod
    Dann stimmt auch wieder der SAR wert.
    Ich kann das Croppen mit AviSynth ja auch ganz weglassen und hinterher mit StaxRip beim encoden zu x264 automatisch vornehmen lassen..

    Meine Vorstellung ist folgende:

    Das uncompr. AVI Video: Lagarith YUV 4:2:2 soll mit AviSynth per QTGMC script:

    Nr.1 > DeInterlaced
    Nr.2 > EZDenoise=2.5
    Nr.3 > bischen schärfe
    Nr.4 > ein wenig die farben auffrischen..

    Das ganze wird dann per "Fast Recompress" in eine neue AVI Datei zurück an den Codec: Lagarith YUV 4:2:2 geschrieben

    [Blockierte Grafik: http://img.xrmb2.net/images/210665.png]

    [Blockierte Grafik: http://img.xrmb2.net/images/522780.png]


    Danach wird StaxRip geöffnet: Auto Crop, eventuell Resize und zu x264 im MKV Container umgewandelt.

    Was meint Ihr?



    Gecroppte Videos sind nicht deutlich besser komprimierbar, dafür aber eventuell inkompatibel mit Consumer-Playern.

    Passiert das auch bei Automatik Crop das Videos inkompatibel mit Consumer Playern werden können?

  • Zitat

    Ich kann das Croppen mit AviSynth ja auch ganz weglassen

    Kann ich nur sehr selten.
    Früher gab es Filter die nicht ganz bis an die Ränder filtern konnten,da habe ich der Einfachheitshalber
    erstmal gecropt und in der nachfolgenden Zeile wieder einen gleich grossen schwarzen Rand drangebordert.

    Problem bei flirrenden Ränder.........der anschliessenden Encoder erkennt diese Stellen als Bewegung im Bild....was er eigentlich tunlichst sein lassen sollte.er soll sich um den "eigentlichen" Bildinhalt kümmern.
    Fazit:die Bildquali wird viel besser und der Script wird auch bedeutend schneller abgearbeitet.

    StaxRip habe ich nicht.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Passiert das auch bei Automatik Crop das sich die Halbbildreihenfolge ändert?

    Die Automatik wird vielleicht oben nur in Schritten von je 2 Zeilen croppen, um das zu vermeiden. Wer weiß... ausprobieren.

    Wenn man Manuell mit AviSynth cropt, muss man dann statt AssumeTFF() jetzt BFF angeben?

    Wenn die obere Anzahl Zeilen ungerade ist.

    Könntest du dir bitte mal bildlich vorstellen, warum das so ist? "Top Field First" = Oberes Halbbild zuerst, also zuerst die obere Zeile. Die eine croppst du weg ...


    Ich dachte man muß ein Video croppen bevor man es ins gewünschte Zielformat umwandelt, um den Encoder zu entlasten ( Bei schwarzen Ränder wird zu stark gerechnet )

    Kommt drauf an, wie viel der Bildfläche die schwarzen Ränder ausmachen, und wie stabil sie sind. Wegen weniger als je 16 Pixel rund herum mach ich mir kein AR kaputt. Da lohnt sich höchstens, den Rand mit der AviSynth-Funktion "Letterbox" scharfkantig und stabil schwarz zu färben.

    Das H.264-Videoformat (MPEG4-AVC) hat deutlich weniger Probleme mit Rändern, die nicht genau 8 oder 16 Pixel breit sind, als die älteren Formate (MPEG1, MPEG2, MPEG4-ASP), welche nur die Diskrete Cosinus-Transformation verwenden, bei denen Makroblöcke immer 16×16 Pixel groß sind; in H.264 gibt es auch welche mit 8 und 4 Pixeln.

    Croppen lohnt sich nur, wenn die unbenutzte Bildfläche erheblich ist, wenn z.B. ein Cinemascope-Film gezeigt wird (so um die 2,3:1 als Seitenverhältnis des interessanten Bildanteils) oder ein 4:3-Film "pillarboxed" in 16:9 ausgestrahlt wurde (schwarz links und rechts). Das aber nur, wenn das Zielformat und der Player gecroppte Bildflächen unterstützen.

    Wenn dein Ziel beispielsweise DVD Video oder kompatibles Blu-ray bzw. AVCHD wäre, dann wären ausschließlich ein paar exakt spezifizierte Bildauflösungen erlaubt. Und nur exakt diese. Da ist Croppen verboten. Da könntest du nur letterboxen, um den Rand zu stabilisieren.

    Wird es dagegen nur so eine Kopie ohne eng spezifiziertes Format, für den PC oder für einen toleranten Mediaplayer, der sich das Bild selber zentriert oder zoomt, dann schnippel halt...


    Passiert das auch bei Automatik Crop das Videos inkompatibel mit Consumer Playern werden können?

    Warum sollte es ein Unterschied sein, ob das Croppen automatisch oder manuell passiert ist?

    Wenn der Player das Zielformat mit beliebiger Höhe und Breite unterstützt, kannst du croppen.
    Wenn der Player das Zielformat nur mit exakt spezifizierter Höhe und Breite unterstützt, darfst du nicht croppen.

    Hängt also ganz erheblich vom Zielformat ab. "Mal so MKV mit H.264" kann wahrscheinlich gecroppt werden.


  • Könntest du dir bitte mal bildlich vorstellen, warum das so ist? "Top Field First" = Oberes Halbbild zuerst, also zuerst die obere Zeile. Die eine croppst du weg ...

    Das verstehe ich leider nicht :(


    Wenn dein Ziel beispielsweise DVD Video oder kompatibles Blu-ray bzw. AVCHD wäre, dann wären ausschließlich ein paar exakt spezifizierte Bildauflösungen erlaubt. Und nur exakt diese. Da ist Croppen verboten. Da könntest du nur letterboxen, um den Rand zu stabilisieren.

    Gut zu wissen :)
    Zielformat: DVD (MPEG2) = Niemals Croppen!
    Da heißt wenn ich ein VHS Video mit viel überschüssigen schwarzen Ränder habe, dann muss es bei MPEG2 mit rein.
    Wie gut das H264 mein Traumformat ist.


    Wird es dagegen nur so eine Kopie ohne eng spezifiziertes Format, für den PC oder für einen toleranten Mediaplayer, der sich das Bild selber zentriert oder zoomt, dann schnippel halt...

    Aber dann stimmt der SAR wert nicht mehr :(
    Und bei StaxRip kann man das Video nicht weiter verwenden, weil es wohl eine Sperr / Schutz funktion ist.
    Ich muss immer bestimmte Crop Werte treffen, damit ich keine Fehlermeldung erhalte.
    z.B. mein jetziges Video hat Crop(16,8, -16, -8)
    Alle werte DAR, SAR und PAR sind im grünen Bereich und ich darf weiter machen laut StaxRip. ( Siehe Bild. 2 ganz unten )


    Warum sollte es ein Unterschied sein, ob das Croppen automatisch oder manuell passiert ist?

    Und zwar wegen folgenden Problem:

    AvsPmod meldet unzulässige Crop-Werte.
    Die Auto-crop funktion scheint mit AvsPmod nicht zu funktionieren!

    Achtung, großes Bild!

    http://img.xrmb2.net/images/818002.png


    Lade ich jetzt das selbe Video in StaxRip, funktioniert die Auto-crop funktion auf anhieb!

    Ich muß ja irgendwie die richtigen Crop werte ermitteln können zwecks DAR, SAR und PAR!
    Mit StaxRip ist das kein Problem, da stimmt auch hinterher der DAR, SAR und der PAR wert usw...

    Oder ich muß es mir umständlich machen:
    Jedes Video was ich bearbeiten möchte, muss ich 1x in StaxRip laden lassen um den Richtigen Crop wert herauszufinden,
    um ihn dann hinterher in AvsPmod eintragen zu können:

    Achtung, großes Bild!

    http://img.xrmb2.net/images/978900.png

  • In der Formel DAR = PAR * SAR ist DAR = Display Aspect Ratio gerade die Auflösung die man erhält, wenn man das gespeicherte Pixel Array (SAR) mit dem Größenverhältnis der Pixels (PAR) multipliziert.
    Das das ein Display Aspect Ratio auch das Verhältnis der Breite und Höhe eines Bildschirms ist, steht das nicht im Weg. :)

  • Das Problem ist vermutlich, dass Yv12 cropping nur in 2er Schritten erlaubt

    Okay, dann mache ich das jetzt so:
    Jedes Video was ich bearbeiten möchte, werde ich 1x in StaxRip laden um den Richtigen Crop wert herauszufinden. ( AutoCrop funzt in StaxRip )
    Diesen Crop Wert trage ich dann bei Zeile. 17 in AvsPmod ein.

    Könntest du dir kurz mein Bild anschauen und mir sagen ob das Script soweit okay ist?

    http://img.xrmb2.net/images/978900.png

  • Danke :)

    Code
    [URL]http://img.xrmb2.net/images/978900.png[/URL]
    
    
    .
    .
    .
    16.) QTGMC(Preset=Medium",EZDenoise=2.5, NoisePreset="Slow")
    17.) Crop(16,8, -16, -8)
    18.) SelectEven()

    Was mir eingefallen ist, müsste ich nicht zwischen Zeile 16. + 17. einen neuen SetMode() setzen?
    Zuerst wird ja das Video DeInterlaced danach wird es doch gecropt ( Das sind doch schonmal 2 Prozess vorgänge )

  • Alles klar :)

    Noch mal kurz zur Übersicht...


    SetMTmode(int mode, int threads)

    Place this at the first line in the avs file to enable temporal (that is more than one frame is processed at the same time) multithreading. Use it later in the script to change the mode for the filters below it.

    mode int (2, default 1-6)
    there are 6 modes, numbered from 1 to 6.

    • Mode 0 - there is no mode 0 to be set by user. Set to mode 5 or 6 instead.
    • Mode 1 is the fastest but only works with a few filters. - One filter instance per call in script, no guarding from Avisynth, only for filters that are designed for this mode, like distributor().
    • Mode 2 should work with most filters but uses more memory. - One filter instance per call in script, Avisynth guards requests for output. The mode to use with source filters. (Mode 5 will do for them too, but is overkill and should be avoided.)
    • Mode 3 should work with some of the filters that don't work with mode 2 but it is slower. - Each call in script produces N (number of threads) instances of filter. Use for the rest.
    • Mode 4 is a combination of mode 2 and 3 and should work with even more filters but is both slower and uses more memory.
    • Mode 5 is the slowest (slower than not using SetMTMode) but should work with all filters that don't require linear frameserving (that is the frames come in order: frame 0,1,2,...,last).
    • Mode 6 is a modified mode 5 that might be slightly faster.

    A more technical explanation is available here: MT_modes_explained

    threads int = 0
    number of threads to use. Set to 0 to set it to the number of processors available. It is not possible to change the number of threads other than in the first SetMTMode.


    Modus 2 ist der schnellste, verlässt sich aber darauf, dass die Filter threadsicher sind. Sind sie es nicht ...

    Mode 1 ist der schnellste?

    Ich habe es mal grob mit einem Online Translator übersetzt...

    Mode 0 - es gibt keinen Modus 0 der vom Anwender eingestellt wird. Stellen Sie den Modus 5 oder 6 statt.
    Mode 1 - ist der schnellste, funktioniert aber nur mit ein paar Filter. - Ein Filter Instanz pro Anruf im Skript, keine Bewachung von Avisynth, nur für Filter, die für diesen Modus ausgelegt sind, wie Händler ().
    Mode 2 - sollte mit den meisten Filter arbeiten, verwendet aber mehr Speicher. - Ein Filter Instanz pro Anruf im Skript, Avisynth Wachen Anfragen für die Ausgabe. Der Modus mit Source Filter zu verwenden.
    (Mode 5 wird es für sie tun, ist aber übertrieben und sollte vermieden werden.)

    Mode 3 - sollte mit einigen der Filter, die nicht mit dem Modus 2 funktionieren arbeiten. ist aber langsamer. - Jeder Anruf im Skript erzeugt N (Anzahl der Threads) Instanzen des Filters. Verwenden Sie den Rest.
    Mode 4 - ist eine Kombination aus Mode 2 und 3 und sollte mit noch weitere Filter arbeiten, ist aber sowohl langsamer und benötigt mehr Speicherplatz.
    Mode 5 - ist die langsamste (langsamer als nicht mit SetMTMode), sollte aber bei allen Filtern, die keine Arbeit lineare Frameserving (das ist der Rahmen in Ordnung kommen: frame 0,1,2, ..., last).
    Mode 6 - ist eine modifizierte Modus 5, der etwas schneller könnte.

  • In der Formel DAR = PAR * SAR ist DAR = Display Aspect Ratio gerade die Auflösung die man erhält, wenn man das gespeicherte Pixel Array (SAR) mit dem Größenverhältnis der Pixels (PAR) multipliziert.

    Ich hab' mir das mal ausgedruckt & über's Bett gehängt ... vielleicht hilft's ja. :)

Jetzt mitmachen!

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