Beiträge von WarpEnterprises

siehe
http://www.avisynth.org/warpenterprises/

RawSource(filename, width, height, pixeltype)

z.B.
RawSource("d:\src6_ref__625.yuv",720,576,"UYVY")
Falls nicht 25fps dann einfach danach ein

AssumeFPS(30)

verwenden.
"pixeltype" ist nicht das interne AviSynth-Format, sondern das Format, indem der YUV-file vorliegt. Dieses wird dann richtig gemappt, allerdings OHNE irgendwelches resampling. Daher geht auch kein 4:4:4, hier müsste nicht nur gemappt, sondern auch konvertiert werden.
Folgende mappings sind implementiert:
RGB, RGBA, BGR, BGRA, YUYV, UYVY

Sie reichen und haben geholfen.
Werde ein Plugin versuchen, dass die Daten beinhart einliest, wo man allerdings alle Parameter angeben muss (Breite, Höhe, Farbraum). Etwas Geduld

Wenn ich recht zusammenfasse, sind also YUV-Dateien headerlose Videodaten im Format YUYV (je 8bit).

Wenn das immer Einzelbilder sind: dafür ein Plugin zu machen, sollte ich schaffen, analog zu ImageSequence.

Kannst du mir ein paar Bilder zukommen lassen? (verschiedene Grössen wären gut, wenn du nicht nur D1 hast) peche at aon dot at

Meinst du mit "Sequenzen" viele Einzelbilder oder gibt es das Ganze auch als eine Art AVI (also ein File mit vielen Bildern drin)?

dazu fällt mir noch ein: eine Anzeige welcher Codec zum Dekodieren verwendet wird, wäre dafür hilfreich, sowohl in AviSynth als auch in TMPG. Im Procoder gibts das z.B.
Wäre (für AviSynth) mal einen Vorschlag an sh0dan wert...

Habt ihr bei den Tests bedacht, das TMPG immer RGB-Input verwendet?
D.h.
- entweder fordert er vom Decoder (z.B. PicVideo, MainConcept-DV,...) RGB, dann wird gleich dort YUV auf RGB gewandelt
- oder er sucht einen Filter, der YUV->RGB kann (z.B. der msyuv.dll).

Beide Varianten sind also von einem externen Codec abhängig, wo man nicht so ohne weiteres sieht, ob dieser CCIR oder 0-255 erwartet.

AviSource(..., pixel_type="RGB") macht also genau das gleiche wie TMPG.
Man sieht also im Beispiel von KIKA, dass PicVideo bei der internen YUY-RGB-Wandlung auf 0...255 wandelt.

TMPG "ohne Kreuzchen" macht für RGB 0-255 ein CCIR-YUV, mit Kreuzchen ein "illegales" mit superblack und superwhite-Anteilen.

PS: mpeg2dec(3) verwendet das TV/PC-Flag von DVD2AVI nicht, vfapi SCHON! Mit mpegdec3 kann also nie ein 0-255-mpeg korrekt in AviSynth gebracht werden.

(das ist mein Wissensstand dazu)

Gemeint ist, dass immer für die ganze jeweilige Zeile eine "Töpfchen"-Statistik gebildet wird.
Für jeden möglichen Helligkeitswert (der gibt die X-Achse) wird für die jeweilige Zeile (die Y-Achse) gezählt, wie oft er vorkommt und danach richtet sich die dargestellte HISTOGRAMM-Helligkeit.

WarpSharp macht eine ganz spezielle Schärf-Methode. Das Bild wird zu Konturen hin "verzerrt"/"gewellt" (deswegen "warp"-Welle)

Pass auf, dass du nicht in den Filter-Wahn verfällst ;D weniger ist oft mehr.
Convolution3D ist m.M. nach ein sehr guter allround-entrauscher.
Danach ein WarpSharp, dass die Konturen schärft.
Und Tweak, wie schon erwähnt.

Wegen einer Server-Umstellung wurde die Adresse geändert auf

http://www.avisynth.org/warpenterprises/

(also ohne ~)

Vielleicht gibts bald einen alias, aber obige geht auf jeden Fall.

An sich sollte man folgende Reihenfolge verwenden:

mpeg2source
mpasource
audiodub
trim + trim + ...

wobei hier egal ist, ob man + oder ++ verwendet, da das clip aus EINER Quelle stammt.
Wie du richtig gefunden hast, ist ++ "sicherer", aber nur relevant wenn beim "vorderen" clip das audio eine andere Länge wie das video hat.

Es bringt keinen Vorteil, das Audio alleine zu trimmen, im Gegenteil. Eigentlich geht gar kein Trim auf ein audio-only clip. Nur weil MPASource ein dummy-video mit liefert, geht das überhaupt (und das war eigentlich nur für Testzwecke drin.)

Die Methode an sich ist optimal fürs Werbung rausschneiden.
Verwende am besten VD-mod mit eingebautem Editor, da kann man am schnellsten die frames abgleichen.

wieso in die Ferne schweifen?

http://www.gleitz.de/vbb3/showthread.php?t=5272

Zitat von Hybrid

scene change bestimmt wie stark bei einem Szenenwechsel geblured werden soll(bitrate niedrighalten/Artefakte vermeiden)

eigentlich noch einfacher: wenn ein Szenenwechsel erkannt wird, erfolgt KEIN zeitliches blurring.

C-API ist die neue Plugin-Schnittstelle.

Die Art, wie erzeugte Plugin-DLLs von AviSynth normalerweise angesprochen werden (der Funktionsaufruf), ist Microsoft-spezifisch, daher gibt es eben diese neue Schnittstelle, die das umgeht.
Das ist aber für den Endanwender völlig egal und in etwa so, wie man ja auch VirtualDub.Filter laden kann (nur braucht man da auch einen anderen Befehl. Im Hintergrund lädt AviSynth auch die C-API-Plugins anders)

Die Conditional-Filter sind wirklich neu bei 2.5 und eigentlich die einzige Neuerung aus Benutzersicht (mehr speed ist keine "Neuerung").

Ausserdem wird 2.0 nicht mehr weiterentwickelt, d.h. es wird kaum oder gar nicht Bugfixes und sicher keine funktionalen Erweiterungen geben (die Cond.Filter würden z.B. prinzipiell auch auf 2.0 machbar sein)

Was auch neu ist, aber (noch) wenig genützt wird, ist echter multichannel-support, nur ist da das Problem, wie man diese aus AviSynth wieder rauskriegt...

Habt ja eh beide recht.
Der CCE verwendet einen externen Decoder für YV12, für z.B. RGB braucht er keinen externen.
Da die internen Umwandlungsroutinen vom AviSynth sehr gut optimiert sind, ist es das beste, diese zu verwenden (es sei denn, die lesende Anwendung kann selber YV12, wie z.B. VD-mod)

Das Filter verwendet eine neue interne AviSynth-Schnittstelle.
Möglich, dass davon der Fehler kommt.
An sich sollte die Syntax verwirrend, aber richtig sein (da der Parameter "bob" ein Clip-Typ ist)

Geht es mit angegebenem LAST?

AviSource(...) #wird also zu LAST=AviSource()

SmartDecimate(LAST, bob=smoothdeinterlace(LAST, doublerate=true))

Write() und String(variable, format):
http://www.avisynth.org/users/warpente…ll_20030920.zip

Version.FadeIn(50).ConvertToYV12       # ein test-video# print von frame number, Zeit und AverageLuma für diesen Frame# Chr(34) ist notwendig, da man sonst keine Anführungszeichen in einen String bekommtWrite(last, filename, "current_frame", "time(" + chr(34) + " %H:%M:%S " + chr(34) + ")", "AverageLuma")

Details in der (engl.) Doku.

Gut dass Kika sein Anwendungsbeispiel erwähnte: jetzt hab ich auch eingebaut, dass man eine Zeile NICHT ausgibt.

VORSICHT: das Clip, das man im Write dem AverageLuma füttert, darf man DANACH nicht mehr verwenden, sonst wird das ganze irgendwie rekursiv und crasht (also einfach eine tmp-Variable einbauen - kostet nichts, da eh alles im cache).

Die String-Funktion ist wie die eingebaute, kann aber optional mit einem Formatstring gesteuert werden:

String(1.23, "%f")     '1.23'
String(1.23, "%5.1f")  '  1.2'
String(1.23, "%1.3f")  '1.230'

ich werds eher als reine String-Ausgabe machen und die string()-Funktion entsprechend erweitern (ist eh fällig und was ich im Code gesehen habe ganz leicht mit einem zweiten Argument machbar).

Mal "Werbung" in eigener Sache:

Ich habe ein Plugin geschrieben, mit dem die Aufnahmezeit und/oder der Timestamp eines DV-AVIs ins Bild eingeblendet werden kann.

Dabei kann allerlei (das Format,...) konfiguriert werden (Details siehe HIER), aber die einfache Version geht so:

LoadPlugin("c:\myprojects\dvinfo\release\dvinfo.dll")
file = "c:\myprojects\type2.avi" # damit man den Filenamen nur einmal tippen muss
Avisource(file)          # das eigentliche Video öffnen
DVInfo(file) # den Timestamp dazulesen und aufs Video draufmalen

Vorsicht: DVInfo weiss nichts von AviSource, sondern verwendet lediglich di e frame-Nummer, um selber im AVI-file den Zeitstempel zu suchen.
Wenn also die files oder frame-Nummern nicht zusammen passen, kommt Müll raus --> DVInfo immer gleich hinter der AVISource verwenden.

Mal "Werbung" in eigener Sache:

Ich habe ein Plugin geschrieben, mit dem die Aufnahmezeit und/oder der Timestamp eines DV-AVIs ins Bild eingeblendet werden kann.

Dabei kann allerlei (das Format,...) konfiguriert werden (Details siehe HIER), aber die einfache Version geht so:

LoadPlugin("c:\myprojects\dvinfo\release\dvinfo.dll")
file = "c:\myprojects\type2.avi" # damit man den Filenamen nur einmal tippen muss
Avisource(file)          # das eigentliche Video öffnen
DVInfo(file) # den Timestamp dazulesen und aufs Video draufmalen

Vorsicht: DVInfo weiss nichts von AviSource, sondern verwendet lediglich di e frame-Nummer, um selber im AVI-file den Zeitstempel zu suchen.
Wenn also die files oder frame-Nummern nicht zusammen passen, kommt Müll raus --> DVInfo immer gleich hinter der AVISource verwenden.

Call wird hier (durch das -2) nur 1x VOR dem encoding aufgerufen (Call ist ja eher gedacht zum Aufrufen von anderen Programmen oder batch-files).

Die Variablen, die von FrameEvaluate gesetzt werden, werden von Call einfach nicht gelesen.
Es gibt auch keine Funktion "Ausgabe in File".

Evtl. geht es, wenn du Call selbst von einem FrameEvaluate aufrufen lässt (ist aber ziemlich brutal, da ich mir nicht sicher bin, was passiert, wenn Call / NicEcho zu oft fast gleichzeitig aufgerufen werden).

Die sauberste Lösung wäre eine eigene Funktion "String-Ausgabe in Datei zur Laufzeit".

(vielleicht hab ich Zeit dazu, dürfte nämlich ganz einfach und generell recht nützlich sein).