AviSynth 2.5 in D2S einbinden

  • Moin Leute
    Bin mal wieder neugierig.
    Wie kann ich AviSynth 2.5 in D2S einbinden,bzw wo muß ich die Verknüpfung erstellen?
    MPEG2Dec oder
    Inverse telecine oder
    BMP subtitler oder
    BMP Loader? 
    oder bei allen vieren?
    Und was bringts mir (never change a running system????)

    THX
    Tom

  • Hallo,
    seit der neusten Version von D2S kannst du bei derInstallation entscheiden welche Avisynth Version du nehmen willst. Der Rest macht DVD2SVD, du kannst praktisch sofort loslegen.

    MfG
    Morpheus

  • Ja, die AviSynth-Version wird bei der Installation festgelegt; wie kommst du darauf, das innerhalb des Skriptes festlegen zu können?! Das Skript wird ja von AviSynth geladen und verarbeitet.

    Das wäre ja, als ob du in einem Texteditor festlegen könntest, welches Betriebssystem dein PC zum Starten verwendet... :D

  • Man konnte ja auch zwischen mpeg2dec und mpeg2dec2 wählen, also lag meine
    Vermutung nahe, hier das neue AviSynth einzubinden.
    Hat sich jedoch erledigt, habe D2S einfach neu installiert.
    Nur eine Frage noch:
    Ist AviSynth 2.5 besser als AviSynth 2 bzw. wo liegen die unterschiede

    Tom

  • AviSynth 2.5 unterstützt noch zusätzlich einen Farbraum (glaube YUV12) für die Verarbeitung. Das ist der Hauptunterschied. Für unsere Videobearbeitung im PAL-System ist nur der YUV4:2:2 interessant.

  • Hallo,
    Avisynth 2.5x soll auch schneller sein. Wird zumindest geschrieben, hab selber auch gerade erste 2.5x installiert und hab deshalb noch keine eigenen Erfahrungen.

    MfG
    Morpheus

  • AviSynth 2.5 arbeitet standardmäßig im YV12-Farbraum, der dem Subsampling in DVDs besonders ähnlich ist; dadurch fallen unnötige Farbraumkonvertierungen weg, wodurch die Verarbeitung schneller wird. Siehe auch den Beitrag 4:x:x und YUV-Varianten im doom9-Ghost-Forum.

    Jedoch können die meisten Programme, die Videos verarbeiten, ausgerechnet das YV12-Format nicht lesen, weil es weniger pixel-, sondern mehr farbkanalorientiert ist:

    • Bei RGB wird z.B. die Rot-, Grün- und Blau-Komponente für einen einzelnen Pixel gespeichert, die Farbe eines Pixels erhält man also aus drei aufeinanderfolgenden Bytes.
    • Bei YUY2 (eine bei AviSynth 2.0x verwendete YUV-Variante) werden die Helligkeits-Informationen (Y-Komponente) für 2 Pixel nacheinander gespeichert, und danach die U- und V-Komponente als Mittelwert dieser beiden Pixel - die Farbe von zwei Pixeln wird also in vier aufeinanderfolgenden Bytes gespeichert.
    • YV12 jedoch speichert erst mal sämtliche Y-Komponenten-Werte aller Pixel des Bildes, dann sämtliche U- und V-Komponenten-Werte. Bis man also die Farbe eines Pixels hat, muss man erst mal das gesamte Bild aufbauen.


    Weil dieses Format von vielen Programmen nicht verstanden wird, muss man u.U. am Ende doch noch eine Farbraum-Konvertierung in das AVS-Skript einbauen. Bisher können nur VirtualDubMod, der MainActor MPEG Encoder und die aktuellste CCE-Version damit umgehen (zumindest sind das die, von denen ich es weiss).

  • Hallo LigH,

    und wieder was gelernt. Ich habe mich bis jetzt noch nicht mit YV12 auseinander gesetzt.
    Als Vorteil ist für mich zu Erkennen, das die Farben besser gehandelt werden, was qualitativ einen Vorteil hat. Dieser Vorteil verschwindet doch wieder durch die menschliche Sehfähigkeit. Das Auge ist doch viel empfindlicher für Helligkeiten als für Farben und durch diesen Umstand hat man sich doch für die Datenreduktion auf Basis des YUV-Farbraumes durch gerungen.

    Theoretisch müsse der YV12-Farbraum auch minimal Detailtreuer sein. Dafür müsste dann der Encoder auch so arbeiten und ob er das so macht ist fraglich. Du sprichst an, das vor der Ausgabe vorher zum größten Teil der Farbraum wieder geändert werden muss. Damit wäre doch der Geschwindigkeitsvorteil wieder weg vom AviS. 2.5.
    Jetzt stellt sich die Frage, wie handelt der aktuelle CCE diesen Farbraum, aber das wird ein großes Geheimnis der Entwickler sein.

    Ich weis nicht. Irgendwie kann ich mich nicht dazu durchringen AviS. 2.5 zu installieren. Quelle hat YUV 4:2:2 und Endformat hat YUV 4:2:2 bei PAL. Zumindest kenne ich wenigsten AviS. 2 gut genug bei der Script-Steuerung und bei AviS. 2.5 müsste ich mir erst wieder an die neuen Befehle gewöhnen, auch wenn diese logischer von der Syntax sein sollten. ;)

  • Zitat

    Original von Gleitz
    Theoretisch müsse der YV12-Farbraum auch minimal Detailtreuer sein.

    Eigentlich nicht: Während YUY2 für Farbinformationen (U/V) den Mittelwert von zwei nebeneinander liegenden Pixeln verwendet (4:2:0) und so auf durchschnittlich 16 Bits pro Pixel kommt, wird bei YV12 der Mittelwert von zwei neben- und zwei untereinander liegenden Pixeln gebildet (4:2:2), also ist das Bild im Chroma-Anteil eigentlich unschärfer. Bei der Umwandlung von YV12 nach YUY2 muss also der Chroma-Wert vertikal verdoppelt oder interpoliert werden, je nach dem ob eher Geschwindigkeit oder Qualität zählen soll. Daher ist auch Field-Verarbeitung auf DVDs eigentlich notwendig (Mittelwertbildung über Zeilen können bei Interlacing ganz schlimme Mischfarben erzeugen, deshalb sind optimierte Konvertierungen dafür auch so wichtig).
    _

    Zitat

    Original von Gleitz
    Du sprichst an, das vor der Ausgabe vorher zum größten Teil der Farbraum wieder geändert werden muss. Damit wäre doch der Geschwindigkeitsvorteil wieder weg vom AviS. 2.5.

    Das ist leider richtig: Der Geschwindigkeitsvorteil von AviSynth 2.5x liegt vor allem darin, den Farbraum nicht konvertieren zu müssen. Kann das Encoder-Programm jedoch dieses Format nicht direkt verarbeiten, ist der Einsatz von AviSynth 2.5x bisher eigentlich nutzlos.
    _

    Zitat

    Original von Gleitz
    Ich weis nicht. Irgendwie kann ich mich nicht dazu durchringen AviS. 2.5 zu installieren. Quelle hat YUV 4:2:2 und Endformat hat YUV 4:2:2 bei PAL.

    DVDs haben 4:2:0. Siehe auch: http://www.dvddemystified.com/dvdfaq.html#3.4 - Pictures are subsampled from 4:2:2 ITU-R BT.601 down to 4:2:0, allocating an average of 12 bits/pixel in Y'CbCr format.
    _

    Zitat

    Original von Gleitz
    Zumindest kenne ich wenigsten AviS. 2 gut genug bei der Script-Steuerung und bei AviS. 2.5 müsste ich mir erst wieder an die neuen Befehle gewöhnen, auch wenn diese logischer von der Syntax sein sollten. ;)

    Die meisten sind 1:1 gleich, neue Befehle gibt es höchstens in der Farbraumkonvertierung und anderen "Kleinigkeiten" (um das im einzelnen zu prüfen, müsste ich es wohl erst installieren, um in der Dokumentation nachzulesen: Die Online-Doku auf avisynth.org ist für meinen Geschmack einfach zu schlecht organisiert).
    __

    P.S.: Ach hier ist der Change-Log: http://www.avisynth.org/index.php?page=ChangeList (man muss nur nach dem richtigen Stichwort suchen...)

  • Zitat

    Original von LigH

    Das ist leider richtig: Der Geschwindigkeitsvorteil von AviSynth 2.5x liegt vor allem darin, den Farbraum nicht konvertieren zu müssen. Kann das Encoder-Programm jedoch dieses Format nicht direkt verarbeiten, ist der Einsatz von AviSynth 2.5x bisher eigentlich nutzlos.


    Das ist nicht richtig.
    Da YV12 weniger Bits braucht, müssen beim Filtern (z.B. Resizen) auch weniger Bits verarbeitet werden. Sprich, wenn man das Resizen in YV12 macht und dann erst in YUY2 konvertiert, geht es schneller.

    Außerdem ist die Verarbeitung von Interlaced besser bei Aviynth 2.5. Z.B. gibt es spezielle Farbraumkonvertierungen, z.B. ConvertToYUY2(interlaced=true).

    Und ich hätte noch eine Frage:
    Wenn die Quelle wirklich YUY2 ist, dann wird sie doch auf bei Avisynth 2.5 weiterhin YUY2 bleiben, oder wird automatisch nach YV12 konvertiert ?
    Bisher sehe ich nämlich so, dass YV12 nur hinzugekommen ist und nicht dass YV12 YUY2 ersetzt hat.

    Gruß
    Arlsair

  • Gut, da hast du alles noch etwas genauer erklärt. Ergänzen wir uns also mal wieder!

    - Natürlich ist auch die sonstige Weiterverarbeitung schneller, wenn weniger Daten vorhanden sind. Aber so mit das langsamste ist wohl eben die Extra-Konvertierung, schätze ich. Wird auch davon abhängen, wie das Verhältnis zwischen Berechnungen und Datentransfer in den Filtern der Filterkette ist: Je höher der Anteil der Berechnung an sämtlichen Vorgängen, umso geringer der zeitliche Verlust durch größeren Datentransfer - zumindest relativ zur Gesamtzeit. Gibt's da Statistiken?!

    - Gesonderte Interlaced-Behandlung ist im YV12-Modus absolut notwendig (wegen vertikalem Chroma-Subsampling ist dann field-orientierte Verarbeitung erforderlich); deshalb ist sie natürlich auch speziell optimiert sinnvoll.

    - AviSynth 2.5 erhält ohne explizite Konvertierung natürlich das Quellformat so lange bei, wie es die verwendeten Filter erlauben. Weil MPEG2DEC3 das Video als YV12 liefert, bleibt es so lange wie möglich YV12. Öffnest du jedoch eine YUY2-Quelle, bleibt das Video möglichst YUY2. Denn jede Konvertierung bringt Verluste.

  • Was meinst du mit Datentransfer ?
    Ich meinte nicht, dass die Datenübertragungskapazitäten von Festplatte und Arbeitsspeicher entlastet werden, sondern dass beim Fitlern weniger Daten ausgelesen und gegeneinander verglichen und interpoliert werden müssen.

    P.S.: Ein positiver Nebeneffekt bei Avisynth 2.5 ist noch, dass sich die Entwickler die Filter überarbeitet haben, damit sie auch mit Avisynth 2.5 funktionieren. Nebenbei sind die Filter dann auch noch verbessert worden. Z.B. funzt der MpegDecoder jetzt ohne Probleme und macht ordentlich Tempo.

    Gruß
    Arlsair

  • Mit Datentransfer meine ich durchaus schon den Transfer von Hauptspeicherblöcken. Bereits der Hauptspeicher-CPU-Transfer ist langsamer als der Zugriff auf den L1-Cache, und meist werden die gesamten Daten eines Video-Frames nicht komplett in den L1 passen.

Jetzt mitmachen!

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