Eigentlich müsste man in VirtualDub auch die Abschnitte mit Werbung Pos1 Ende markieren und aus der Timeline Entf entfernen können, so dass diese Abschnitte beim Speichern ausgelassen werden. Aber daran erinnere ich mich nur in Theorie, praktisch habe ich das selten genutzt.
VirtualDub2 kann auch selbst mit x264 zu MP4 +faststart speichern.
Ich vermute mal: Wenn du Preset und Tuning wählst, fügt Hybrid die Standardwerte für diese Kombination ein. Also eigene Werte immer zuletzt einstellen.
Also dann am besten direkt die Entwickler bei doom9 fragen...
Vielleicht ist es möglich, zunächst eine zusammenhängende Zwischendatei zu speichern, indem man alle Codecs (auch die für Untertitel) im copy-Modus verwendet.
Nochmal zur Tonspur, ob die drin ist oder nicht, und in welchem Format: MediaInfo hilft. Theoretisch könnte es sein, dass sie in einem Format gespeichert wurde, welches ein Mediaplayer erkennt und abspielt, eine Schnittsoftware aber nicht kennt oder ablehnt, weil sie sich aus Gründen der Bearbeitbarkeit auf bestimmte Formate beschränkt.
Alte Versionen von VirtualDub sind sicherlich 32-bit-Applikationen, benutzen also auch nur die 32-bit-Variante von AviSynth+. Um die Vorteile der 64-bit-Variante nutzen zu können, muss man schon ein 64-bit-Programm verwenden. Man braucht dann aber auch alle Plugins in ihrer 64-bit-Version (im plugins64-Verzeichnis von AviSynth+).
FFMS2 generiert erst eine Indexdatei, ebenso wie LSMASHWorks, wenn LwLibavVideoSource benutzt wird. Da du eine MOV-Datei als Quelle hast, die kompatibel zum ISO Base Media Standard ist, könntest du auch LSMASHVideoSource verwenden, die verlässt sich auf den Indexchunk in der MOV-Datei; sollte es hier aber auch zu einem Fehler kommen, ist vielleicht der Index in der MOV-Datei beschädigt, dann hat FFMS2 deshalb funktioniert, weil es seinen eigenen generiert hat.
Ansonsten wird es langsam Zeit, auf AviSynth+ und VirtualDub2 umzusteigen...
Das analoge Videosignal enthält bei PAL 625 Zeilen. Davon enthalten aber nur 576 auch Bildinformationen. Davor und danach gibt es noch Zeilen mit Synchron- und Steuersignalen für Fernseher.
Nur weil das Video halbbildweise digitalisiert wurde, muss der sichtbare Inhalt noch lange nicht interlaced sein. Das wäre im Voraus zu prüfen.
Ich würde mal vermuten, dass der Film im Original mit Kinofilm-Bildrate (24 fps) aufgenommen wurde. Für die PAL-Version wurde er dann sicherlich um 24/25 fps beschleunigt (PAL Speedup). Um ihn wieder zurück zu NTSC-Film (23,976 statt 24,0 fps) zu konvertieren, muss man ihn wahrscheinlich nur wieder entsprechend verlangsamen.
Soweit die Theorie. Als nächstes also eine Bob-Analyse des Materials...
VapourSynth ist eine Alternative zu AviSynth, basierend auf Python, ganz andere Skript-Syntax.
Multithreading in AviSynth wird nur unterstützt, wenn man auch die MT-Variante davon installiert; und AviSynth+ verwendet noch mal eine eigene Variante mit anderen Funktionen zur Steuerung.
Die Firma Oehlbach kennen ... jaaa, wegen unverschämt hoher Wucherpreise, die keine Marke rechtfertigt. 
Sieht aus wie der Neffe von Rumburak 
Eigentlich sollte es nicht 576p25, sondern 576i50 sein. Also auf dem Magnetband in 50 Halbbildern pro Sekunde nacheinander. Digital abgespeichert von vielen Videocodecs allerdings in kombinierten 25 Vollbildern.
Was willst du abschneiden, die Störungen am unteren Rand? Ja, in AviSynth kann man das gleich in einem Resize-Aufruf durchführen, indem man nicht nur Zielbreite und Zielhöhe angibt, sondern zusätzlich noch, welcher rechteckige Ausschnitt auf diese Größe gebracht werden soll. Wenn 50p das Ziel wäre, würde sich 720p50 als Variante anbieten, die zu gewissen Consumer-Videostandards konform wäre. Allerdings wäre das schon eine recht starke Vergrößerung (704×432 auf 1280×720, inklusive Entzerrung), die je nach Methode wohl unterschiedliche Artefakte erzeugen kann. "Scharfe" Techniken würden hier vielleicht Rauschen und Kantenringe zu deutlich hervorheben.
Bobbing ist eine sehr simple Interpolation, die berechnet nur den Mittelwert zwischen den Zeilen der Halbbilder und verschiebt den Inhalt dann leicht in der Höhe, um das Flackern zu vermindern. Dabei werden aus 50 Halbbildern pro Sekunde 50 Vollbilder.
QTGMC macht das grundsätzlich ähnlich, nutzt aber noch Bildinformationen aus angrenzenden Halbbildern für eine Bewegungskompensation, um Bewegungen flüssiger und Kanten gleichmäßiger darzustellen. Auch hier werden aus 50 Halbbildern erstmal 50 Vollbilder pro Sekunde. Wenn du willst, kannst du mit SelectOdd() oder SelectEven() die Hälfte davon wegwerfen.
Unter einem aktuellen AviSynth+ kann ein aktuelles QTGMC von real.finder auch in höher aufgelösten planaren Videoformaten agieren (z.B. YV16, gleiche Farbauflösung wie bei YUY2 oder UYVY), dazu wird aber noch ein Skript mit Helferfunktionen benötigt (Zs_RF_Shared.avsi). Dann sollte u.U. auch gar kein TemporalSmoother mehr verwendet werden (oder eine Variante, die mit den modernen Farbräumen klarkommt).
Mit "halbbildweiser Betrachtung" meine ich: Video in AviSynth öffnen und den Bob()-Filter anwenden. Dann sieht man die auf Vollbild interpolierten Halbbilder so zeitlich nacheinander, wie sie von der Kamera aufgenommen wurden, und kann sich deren zeitliche Entwicklung ganz langsam betrachten.
Die grauen Abschnitte am Anfang und Ende hättest du abschneiden können...
So wie ich das sehe, ist dein Material einwandfrei linear interlaced. Somit sollten auch gute Deinterlacer, die mit Bewegungskompensation arbeiten (am besten QTGMC, einfacher auch TDeint oder Yadif, jeweils anstatt Bob) das ganze wunderschön ruhig kriegen (abgesehen von der wackeligen Freihand-Kameraführung).
Bedenke: Wenn du in AviSynth ein AVI öffnest, geht der Quellfilter von BFF-Reihenfolge aus, weil das für DV meist korrekt ist; auf VHS wirst du aber eher TFF-Reihenfolge haben. Deshalb noch das AssumeTFF() gleich nach dem Quellfilter.
Bedenke auch, dass ein PC-Monitor seinen Inhalt nicht interlaced, sondern progressiv darstellt. Du siehst also eventuell gleichzeitig, was du eigentlich nacheinander sehen solltest. Außerdem kann ein PC-Monitor leicht eine andere eigene Bildwiederholrate als das aufgezeichnete Video haben. Insofern würde ich einen PC-Monitor nicht als zuverlässiges Kriterium ansehen.
Andererseits kann es auch sein, dass das Material vielleicht nicht linear interlaced war, sondern das Ergebnis einer sonderbaren Normwandlung. Das kann man am sichersten prüfen, indem man sich das Video halbbildweise (z.B. nach einem Bob) Schritt für Schritt anschaut. Im Zweifel gern auch einen Ausschnitt mit uns teilen.
Willkommen.
Warum sollte man exakt die selbe Bitrate wie im Original überhaupt brauchen? Eine verlustfreie Konvertierung garantiert das nicht, im Gegenteil. Einziger möglicher Grund: Man will einen Datenträger der gleichen Größe ebenso füllen. Dann würde man aber mit einer Zielgröße arbeiten und eine 2-pass-Konvertierung verwenden, damit der Encoder im ersten Durchlauf Statistikdaten sammeln kann, um die Bitrate für den zweiten Durchlauf auf die Zielgröße herunterzurechnen. Das garantiert aber auch keinen 100% exakten Treffer, ein wenig Zufallsschwankung ist immer drin.
Nachtrag: Feste Bitrate in einem Durchlauf erzeugt im Allgemeinen eher ein Ergebnis mit stärkeren Qualitätsschwankungen, weil der Encoder dann versucht, in jeder Szene etwa die gleiche Bitrate zu erreichen, egal wie unterschiedlich der sichtbare Inhalt der Szenen ist. Das ist relativ nützlich, wenn man das Ergebnis über einen Weg abspielen muss, der eine begrenzte Bandbreite hat (z.B. Internet-Streaming). Für eine Archivierung oder das Abspielen von schnellen Datenträgern ist das aber von Nachteil. Hier will man doch eher eine relativ gleichbleibende Qualität erhalten. Wem da die Größe egal ist, weil auf dem Datenträger genug Platz ist, der wählt CRF; wer eine Zielgröße erreichen muss, weil der Datenträger klein ist, muss 2-pass verwenden.
Jetzt könntest du noch probieren, ob z.B. avs2pipemod auch so leicht verwendet werden kann. Das wäre ein viel kleineres Programm und lädt selbst wahrscheinlich schneller als das riesige ffmpeg.
Laut ffmpeg-Wiki ist die Verwendung des Null-Multiplexers schon die portable Lösung. Dann versucht ffmpeg gar nicht erst, eine Ausgabedatei zu generieren. Deine Antwort in #6 war also optimal.
Eine Ausgabedatei im NUL-Gerät verschwinden zu lassen würde bedeuten, dass erstmal ein anderer Multiplexer vorher Rechenzeit verbraucht. Aber es wäre auch möglich, damit "nichts" zu erzeugen, falls man einen Multiplexer bei der Ausführung testen wollte. Das ist für dich ja nicht wichtig. Grob hätte es etwa so ausgesehen: ffmpeg -i meinscript.avs NUL (dann hätte ffmpeg aber vielleicht beanstandet, dass es nichts zu tun hat).
Oder mit der Ausgabe an das Gerät (NUL unter Windows, /dev/null unter Linux...).
