Infoseite // Tips: AVISynth Tricks Teil 2– Wie funktioniert AVISynth?

Newsmeldung von slashCAM:


Tips: Tips: AVISynth Tricks Teil 2– Wie funktioniert AVISynth? von rudi - 16 Nov 2010 15:29:00
AVISynth ist ein sehr komplexer Frameserver, dem wir eine größere Artikelserie widmen wollen. Im zweiten Teil wollen wir einmal kurz und einfach beschreiben, wie AVISynth grundsätzlich funktioniert.
zum ganzen Artikel



Antwort von tommyb:

AVCHD lässt sich weitaus besser mittels "ffmpegsource2" importieren. Dabei werden die fehleranfälligen DirectShowFilter umgangen und der Stream nativ ausgelesen.

Arbeitet man hingegen mit DS-Filtern, ist oftmals das Seeking nicht Framegenau und es können extreme Decodingfehler entstehen die erst ab dem nächsten Keyframe wieder "weggehen".

FFmpegsource2 gibt es hier:

http://code.google.com/p/ffmpegsource/

Syntax ist z.B:
ffvideosource("blabla.m2ts")



Antwort von rudi:

AVCHD lässt sich weitaus besser mittels "ffmpegsource2" importieren. Dabei werden die fehleranfälligen DirectShowFilter umgangen und der Stream nativ ausgelesen. Super, Danke für den Hinweis, werde ich sicherlich an der einen oder anderen Stelle einbauen.

Hast du Erfahrungen wie es mit der Performance aussieht? Laut Webseite klingt das zwar gut für den Import (Index sei Dank), aber wohl auf Kosten der Performance (FFMS2 does not provide you with a good solution for realtime playback, since it needs to index the input file before you can retreive frames or audio samples.)

Außerdem klingt es so, als ob es auf Multiprozessor-Systemen vieleicht mit Multi-Threaded Funktionen Probleme gibt (FFMS2's video frame and audio sample retrieval functions are not threadsafe; you may only have one request going at a time.)



Antwort von lofi:

Wenn beide Postings stimmen, bleibt für mich am Ende doch nur
das Umkodieren in ein Intermediate-Format oder der native
AVCHD-Import im NLE, so es den hat. Eure AVISynth-Reihe
hatte in mir den Wunsch aufkommen lassen, per Frame-Server
für den Proxy-Schnitt Material in halber Aulösung an Premiere zu schicken und für's Rendern im Frame-Server einfach nur die Auflösung wieder aufs Original zu ändern. Das hätte den Charme gehabt, völlig ohne Intermediate-Dateien auszukommen.

Mein Problem ist die AVCHD-Performance mit meinem Premiere CS4 auf meinem 2*2,5 GHz-Notebook (Edius-User weghören).
Deshalb werde ich es bei meinem nächsten Projekt dann doch mit
Proxy-Schnitt in Premiere (siehe http://help.adobe.com/en_US/PremierePro ... 7f74a.html) versuchen. Das bedeutet aber, daß ich das Material
zweimal ins Intermediate (bei mir Canopus HQ) kodieren muß, einmal in höchster
Qualität für das Rendern am Ende und einmal in reduzierter Auflösung für den Schnitt. Zusätzlich werde ich für den Schnitt noch das Previw-Renderformat herunter-tunen (siehe http://forums.adobe.com/thread/390600?tstart=0).

Zum Thema zurück:
Wofür ist das Ganze dann gut, wenn es die beschriebenen Macken mit DirectShowSource gibt ?



Antwort von tommyb:

ffmpegsource2 ist wesentlich stabiler als DirectShowSource - zumindest was die Bildfehler-rate betrifft, denn die ist bei ffmpegsource2 nicht vorhanden - DS hingegen ist ziemlich fehleranfällig weil hier eben viele verschiedene Decoder genutzt werden können (ffdshow mit ffmpeg, ffdshow mit libavcodec, andere Decoder, etc.).


Performance-mäßig ist nur das indizieren am Anfang ein Problem - d.h. beim Laden in z.B. VirtualDub wird eine Index-Datei erstellt. Diese wird allerdings nur ein einziges Mal erstellt und im Ordner der Quelldatei abgelegt. Lädt man das ganze später nochmal in VirtualDub, wird direkt auf den Index zugegriffen.

Das Decoding selbst läuft Single-Threaded ziemlich gut und vorallem in Echtzeit mit z.B. 1080p25 (auf Core i7 860). Es gibt nebenbei noch einen Entwicklungszweig der Multithreaded arbeitet - hier schafft man dann auch noch 1080p50 ohne Probleme.

Die MT-Version vom Plugin ist nach meinen Erfahrungen recht stabil, aufgrund der besonderen Herausforderung von Multithreading verzichte ich derzeit noch auf den Produktiven Einsatz dieser Version.

Wenn man sowieso das Script mit komplexen Plugins vollhaut, ist es prinzipiell egal ob das Decoding mit 25 oder 50 oder 80,9fps läuft, wenn die gesamte Geschwindigkeit irgendwo bei 3fps liegt.



Wie schnell decodiert wird, kann man übrigens so rauskriegen: ffvideosource("datei.mp4") assumefps(1000) Dieses Script wirft man in VirtualDub und drückt dann F5. Es wird dann einfach abgespielt. Abhängig von der Leistung des gesamten Systems kommt man auf eine bestimmte Bildrate. Theoretisch wären 1000 fps drin - aber das ist natürlich nicht möglich. Die Decoding-Geschnwindigkeit richtet sich nämlich bei diesem Verfahren rein nach der festgelegten FPS-Rate im Videostream - ergo kann man nur mit dem Script oben richtiges Benchmarking des Plugins machen.



Antwort von tommyb:

@lofi
Avisynth ist primär nicht unbedingt als ein Zwischenschritt für die Erstellung von Proxy-Dateien gedacht, weil es zum einen von den meisten Programmen nicht unterstützt wird, zum anderen muss da Decoding nicht in Echtzeit ablaufen (dafür ist Avisynth ursprünglich auch nicht ausgelegt gewesen).



Aaaaaber:

Wenn man einen haufen AVCHD-Files hat, kann man sich mit ein wenig "Basteln" z.B. eine Batch Datei erstellen die mittels Avisynth und ffmpeg besser verarbeitbare Intermediate-Dateien erstellen kann - völlig automatisiert.

Zwar kann ffmpeg AVCHD Files auch direkt importieren, aber hier gibt es eine hohe Fehleranfälligkeit weil ffmpeg recht selten gepflegt wird und auch eine etwas niedrigere Geschwindigkeit beim Decoding hat. Avisynth-Files jedoch arbeiten problemlos mit ffmpeg.



Antwort von Markus_Krippner:

Hab mir etz auch mal Avisynth gesaugt.

Leider passiert hier bei mir GARNIX, wenn ich versuche, eine Script-Datei in einem Player zu öffnen. Egal, welcher Player.

Woran könnte das liegen ?

..markus :-)



Antwort von tommyb:

Du musst es in VirtualDub ziehen.

Nur wenige Player (z.B. MediaPlayer Classic) können Avisynth-Scripte abspielen.