Beiträge von Sagaras

Zitat von InskayDanork

Ich nutze einen [lexicon]Frameserver[/lexicon], falls das wichtig ist?^^
(Vermutlich ja, warum hab ich das erst jetzt gesagt? *Facepalm*)

Dann liegt das vermutlich daran das die betroffene AVI Datei nicht indexiert werden kann, da Faik Datei glaub ich. Demnach kann diese so nicht geladen werden. Ich weiß es jetzt selbst nicht, aber ich kann mir das gut vorstellen. Was nutzt du denn? [lexicon]Sony Vegas[/lexicon] oder sowas? Wenn die AVI nicht abgespielt werden kann oder entsprechend klein ist, da diese auf andere Datein verweist kann mit FFDVideoSource nicht indexiert werden glaub ich. Dann musst du wohl AVISource nutzen.

Generell wäre es hilfreich zu wissen was du vorhast

Nein, hört auf xD Nicht alles neu machen xD

Erst mal:

LoadPlugin("E:\MeGui\MeGUI\tools\ffms\ffms2.dll")
return FFVideoSource(source="E:\MeGui\tm24fs.avi", threads=2)

ist viel zu viel ;D Ein Return muss nicht angegeben werden, sofern keine Funktion oder andere Bedingung etwas mit dem Video anstellt.
Return ist nur eine Rücksendung der jeweiligen Variable an den Skriptsender.
Vorläufig gerne in Funktionen zu finden ;D
Hier jetzt muss er also nicht angegeben werden, da überflüssig. Weil das Video ja schon ausgegeben wird.

LoadPlugin("E:\MeGui\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource(source="E:\MeGui\tm24fs.avi")

reicht also wenn es so da steht. Eine Löschung der Indexdatei zum besagten Video kann Hilfe verschaffen. Eine Objektinstanz kann nicht erzeugt werden, wenn das betroffene Video mit dem Ladeprozess nicht geladen werden kann. Darum mal eine [lexicon]Mediainfo[/lexicon] zur Datei angeben die geladen werden soll. Eventuell fehlt der Header des Videos.

Wo hast du denn deine Audiospur? Extern als [lexicon]WAV[/lexicon] Datei? Oder Intern in der AVI Datei? Wenn du eine Externe [lexicon]WAV[/lexicon] hast, musst du diese entweder Solo encodieren lassen in [lexicon]MeGUI[/lexicon] mit den dazugehörigen Schnittdaten vom dazugehörigen Video oder du trägst im Skript zusätzlich noch ein:

AVISource("E:\MeGui\tm21fs.avi", audio=false).AssumeFPS(30)
s=WAVSource("E:\MeGui\tm21fs.wav")
AudioDub(s)
ConvertToYV12()

Damit nimmst du eine externe [lexicon]WAV[/lexicon] Datei für dein Video. Solltest du eine externe Audiospur haben. Beim laden der AVS Datei wird dann im oberen Bereich von [lexicon]MeGUI[/lexicon] nun das Video geladen und unten die Audiospur. Du musst beides in Auftrag geben dann.
Das schneiden über den [lexicon]AVS Cutter[/lexicon] erfolgt bei dem Skript hier parallel für Audio und Video.

Zitat von De-M-oN

Aber selbst wenns 2 wären, der performancegewinn wäre quasi im nanosekundenbereich. Bei 30 frames gehts nahezu gleich schnell wie mit dem einen.

Es geht nicht um den Performancegewinn, denn sobald das Skript geladen wurde ist die Datei da. Das ist voll Banane ob es 2 oder 3 oder 5 Frames sind. Ich hab ja auch nur gesagt das es unnötig ist

ImageReader("picture.png", end=0).Lanczos4Resize(1600,900)
ImageWriter("new_picture.png", type="png")

Ist doch viel kürzer.

Bei dir im Bild steht 1/1 Frames und deine Spulenanzeige steht auf Ende. Wenn es wirklich nur 1 [lexicon]Frame[/lexicon] wäre müsste da 0/0 Frames stehen und die Spulenanzeige dürfte sich gar nicht erst bewegen mehr Das macht dieser Skript den ich da eben hingeschrieben habe

Sieht dann in [lexicon]MeGUI[/lexicon] halt so aus in der Leiste oben:

Das hat halt nix mit Performance zu tun, sondern der Skript ist viel kürzer und auch übersichtlicher. Bei zu vielen Angaben, verliert man doch mal die Übersicht irgendwann. Gerade wenn man sowas wie BlankClip(1800, 320,240,"YV12",30000,1001,48000,true,true,$0000FF) hinschreibt schaut doch keine Sau mehr durch und vllt brauch man auch nicht alles davon.
Übersichtlicher und effektiver sind Schlüsselbezeichnungen anzugeben, damit ein anderer den Skript auch verstehen kann. Bei dem Beispiel wäre es:
BlankClip(length=1800, width=320, height=240, pixel_type="YV12", fps=30000, fps_denominator=1001, audio_rate=48000, stereo=true, sixteen_bit=true, color=$00000FF)

Wenn irgendwas davon nicht gebraucht wird kann man es rauswerfen. Ohne Schlüsselbezeichnungsangabe die FPS zum Beispiel rauswerfen aus dem oberen Beispiel würde die FPS auf 1001 stellen, den Denominator auf 48000 usw. Deshalb die Angaben eigentlich

Bei Animate und ApplyRange können keine Schlüsselbezeichnungen verwendet werden, was das ansprechen der zu gebrauchten Schlüsselelemte erschwert. Weil dort kommen nur Argumente rein. Da macht es wieder mehr Sinn Funktionen zu benutzen

Dann ist ja gut xD

Und den Skript hab ich auch optimiert für Bilder. xD Sry. Ich bin irgendwie langsam auf so ein Trip, was den Skript angeht und wo alles korrekt sein muss und optimiert xD Ich bitte da etwas nachsichtig zu sein. xD Ist ja auch nicht böse gemeint xD

Zitat von De-M-oN

Eig. macht das Script doch nur einen Frame? Ist aber auch eh egal, da der performancegewinn wohl im nanosekundenbereich wär xD

Das es nicht einlesbar war, lag an einem falschen Pfad im Script oder er hat versehentlich die PNG in [lexicon]MeGUI[/lexicon] geöffnet statt das Script. Aber höchstwahrscheinlich erstres der Fall.

Dein Skript da erzeugt 2 Frames Das 0te und das 1te Was halt überflüssig ist wenn es nur darum geht das Bild zu speichern.

Auch muss der Skript nur einmal durchlaufen werden. Das reicht wenn die Vorschau für dieses Skript in [lexicon]MeGUI[/lexicon] angezeigt wird oder es in Virtul Dub kurz geladen wird. Dann wird schon die Datei erzeugt. Also kein Encoden oder sowas nötig. Das Skript muss nur geladen werden irgendwo und es muss korrekt sein der Skripttext

Zitat von De-M-oN

Er will nurn Thumbnail skalieren und das geht mit dem Script so einwandfrei. Da brauch ich keine mehreren Frames.

Jo, dann lasst doch den Start und Endframe einfach weg dafür Dein Bild beträgt doch eh nur ein [lexicon]Frame[/lexicon] mit dem gleichen Bild. Und eine ausgabe ohne sonstirgendwas.

Demnach erstellt er auch nur ein Bild wenn das hier steht:
ImageReader("L:\Test\Testaufnahme\Logo.png", 0,0, 1).Lanczos4Resize(1600,900)
ImageWriter("L:\Test\Testaufnahme\Logo Neu.png", type="png")

1 [lexicon]Frame[/lexicon] nur. Warum unnötig noch Frames dazudichten?

Zitat von Sazoga

Aber so mach ich das immer, das Script ist von De-M-oN und jetzt geht ja auch wieder alles, trotz 0, 1, 1 Aber danke für den [lexicon]VirtualDub[/lexicon] Tipp, wobei ich dir nicht ganz folgen kann, is ja komplizierter als C++ xD

Das ist nicht komplizierter als C++ Sondern einfache Logik anhand der Funktion die gegeben ist mit dem Befehl.

Du hast ja dein Befehl:
ImageReader("D:\Sazoga\CT\CT Fertig.png", 0, 1, 1)

Das ist nix anderes als wenn im Skript steht:
ImageReader(file = "D:\Sazoga\CT\CT Fertig.png", start=0, end=1, fps=1)

Wenn die Reihenfolge der Inputs beibehalten wird, brauchst du keine Bezeichnungen schreiben wie start, end oder frame. Dann reichen auch die alleinigen Inputs dafür.
Lässt du aber eines davon weg, musst du bei den darauf folgenden die Bezeichnungen wieder setzen.

Beispiel:
ImageReader("D:\Sazoga\CT\CT Fertig.png", end=1, fps=1)

Hier wird der Startframe weggelassen, da dieser Standardmäßig sowieso 1 beträgt, alle weiteren Angaben muss ich aber angeben, weil wenn ich sonst nur 1,1 angebe ohne Bezeichnung würde das für Start und Endframe sein. Und somit ist es für Endframe und für die FPS angegeben.

Bei ImageWriter hast du allerdings einen Fehler gemacht, sofern dieser danach folgt.
Du hast halt versucht ein File, eine Datei zu erzeugen, aber dafür Start und Endframe angegeben. Das fürt zu einem Fehler, denn es ist ja keine Bildfolge die du ausgeben willst, sondern ein Bild nur. Da du nur ein [lexicon]Frame[/lexicon] besitzt und das mit einem Bild nur geladen ist, ist eine Bildfolge überflüssig. Wobei du ja auch nur ein File schreiben willst.

Also Bilderfolge mit einem Pfad angeben und einem Start und Endframe und bei einer einzelnen Datei die du erzeugen willst, nur den Endframe angeben der erzeugt werden soll. Oder halt weglassen um den Standartmäßigen Endframe als Bild zu speichern

HALT, da war was falsches im Video ab 2:15 erklärst du das es durch "Convert [lexicon]H.264[/lexicon] tracks to AVI" nicht konvertiert wird. Das ist falsch. Die Bezeichnung ist dort richtig gewählt. Und zwars wird dort auf den unschönen h264vfw konvertiert der dann in AVI per Hack reingeht. Die Konvertierung von h264 -> h264vfw ist also gegeben. Dauert auch nicht lang diese Konvertierung, da sich die Materialien ähneln.

Bedeutet du machst dir ein Hack zu nutze um es für andere Programme lesbar zu machen. Dabei wird das Video an sich durch diese Konvertierung erheblich beschädigt in ihrer Gesamtstruktur.

Es ist aber um auf dein Tutorial zu kommen ein guter Weg MKVs in Sony zu importieren. Dazu brauch man aber keine [lexicon]Codec[/lexicon] Packs und du solltest auch keine hier posten. Das kann unter anderem auch wie gesagt schaden. Da die Codecs gewisse Peripherien haben und du mit einem [lexicon]Codec[/lexicon] Packs diese dann auch völlig ändern kannst und damit die alte Peripherie somit zerstören kannst.

Bei Apple Quicktime ist mitunter auch der h264vfw drin.

In der mit dem [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] und [lexicon]MKV[/lexicon] Merge generierte [lexicon]MKV[/lexicon] Datei befindet sich eine h264 Datei und eine Soundspur. Die h264 Datei ist eine reine Datenansamlung und wird auch als Binärdatei bezeichnet, da diese nicht abspielbar ist. Man kann diese dann aber logischerweise in ein [lexicon]MP4[/lexicon] [lexicon]Container[/lexicon] stecken ohne den eigentliche codierte Datei zu konvertieren.

Wie gesagt, ein guter Weg mit diesem Hack, aber auch mit Folgen bestückt. Da sich halt die ganze Strucktur des h264 ändert für diesen AVI Hack. Weil an sich kann man kein h264 in eine AVI reinpacken. Das ist Fakt.

Zitat von Sazoga

ImageReader("D:\Sazoga\CT\CT Fertig.png", 0, 1, 1).Lanczos4Resize(1600,900)
ImageWriter("D:\Sazoga\CT\CT Fertig encodiert.png", 1, 1, "png")

Hier wird ein Fehler begangen und das nicht grad beim Reader.

Und zwars fängt das beim Image Reader so an:
ImageReader(Clip, Start [lexicon]Frame[/lexicon], End [lexicon]Frame[/lexicon], FPS)

Bei dir also: ImageReader("D:\Sazoga\CT\CT Fertig.png", start=0, end=1, fps=1)

soweit so gut, du hast also 1 [lexicon]Frame[/lexicon] grad mal. Sprich 1 einziges Bild geladen damit. Nix weiter. Und möchtest nun ein Bild erzeugen von [lexicon]Frame[/lexicon] 1 bis [lexicon]Frame[/lexicon] 1 was natürlich 0 ergibt.
Da du dir das sparen kannst, würde der Skript also bei ImageWriter so aussehen müssen:
ImageWriter(file="D:\Sazoga\CT\CT Fertig encodiert.png", type="png")

Da du dir Start und Endframe sparen kannst, weil dies dann zu einem Fehler führen würde, da du ja nur ein [lexicon]Frame[/lexicon] geladen hast mit 1 FPS.

Zudem versuchst du mit ImageWriter("D:\Sazoga\CT\CT Fertig encodiert.png", 1, 1, "png") zum einen 1 Datei zu speichern, obwohl du eine Angabe von Start und Ende der Frames machst, was für eine Abspeicherung einer Bilderfolge erst notwendig wäre. Dazu müsstest du nicht file angeben, sondern path und nur den Ordner. Kein Dateinamen. Die Bilder werden dann durchnummeriert.

Zudem kannst du beim ImageReader die Angabe des use_DevIL machen. Ob der genutzt wird oder nicht. Schreibste einfach hinter der fps Angabe. Also (... fps=1, use_DevIL=false)...

Um das mal zu zitieren wofür DevIL gut ist:

Zitat

When false, an attempt is made to parse (E)BMP files with the internal parser, upon failure (prior to v2.56) DevIL processing is invoked. When true, execution skips directly to DevIL processing. You should only need to use this if you have BMP files you don't want read by ImageReader's internal parser

PS: Für den ImageWriter muss man das ganze nicht in [lexicon]MeGUI[/lexicon] encodieren. Da reicht es auch aus den Script nur senden zu lassen, indem man den Skript kurz in Virtual Dub zieht. Und schon ist das Bild auch da im entsprechenden Ordner.

Dank SaintzLP und seinen Problem einen Bereich unkentlich zu machen mit einen Verschwimmeffekt, hat er mich mit seinen Skript inspiriert. Ich habe es dann noch etwas verfeinert und als Funktion verpackt, sodass man nur noch ein Befehl eingeben muss für diesen Effekt.

Hier mal der Code dazu:

######################
# Verschwimmeffekt auf einen Bereich im Bild
# -------------------------------------------------
# Function Verschwimm (clip clip0, int sw, int sh, int ew, int eh, float px, int faktor, int sframe, int eframe) 
# clip0 = Der Clip der geladen wird
# sw, sh, ew, eh = Bildbereich (x,y) - (x2,y2)
# px = der p Wert für den Gaussresizer. 1 = Unscharf, 100 = scharf
# faktor = Der Faktor mit dem verkleinert wird um das Bild unkenntlich zu machen
# sframe und eframe = Start und Ende des Framebereiches auf dem der Filter angewendet wird
######################


AVISource("L:\Test\Testaufnahme\Aladdin.avi")


#Wenn last alleine ist, muss das Video nicht mit last angegeben werden
#Hier sorgt AVISource dafür das der Clip in last kommt. Somit brauch ich kein Clip angeben
#Verschwimm( clip "Video", x1, y1, x2, y2, px, faktor, frame_start, frame_end)
Verschwimm(374, 54, 650, 126, 1, 40, 1389, 5849)
Verschwimm(374, 54, 650, 126, 1, 40, 6169, 7313)


Function Verschwimm (clip clip0, int sw, int sh, int ew, int eh, float px, int faktor, int sframe, int eframe) {
    clip1 = (sframe == 1) ? clip0.Trim(0, sframe-2) :  clip0.Trim(0, sframe-1)
    clip2 = (faktor == 0) ? clip0.Crop(sw, sh, ew, eh) : clip0.GaussResize(clip0.width / faktor, clip0.height / faktor, sw, sh, -clip0.width + ew, -clip0.height + eh, px).Spline64Resize(ew - sw, eh - sh)
    clip2 = Overlay(clip0, clip2, x = sw, y = sh).Trim(sframe, eframe)
    clip3 = clip0.Trim(eframe+1, clip0.framecount-1)
    return (sframe == 0 && eframe == clip0.framecount - 1) ? clip2 : (sframe == 0) ? clip2++clip3 : (eframe == clip0.framecount - 1) ? clip1++clip2 : clip1++clip2++clip3
}

Da wird nix geändert weiter, außer die Laderoutine mit was deine Rohaufnahme in AVISynth geladen wird korrekt. Der Rest bleibt gleich wieder und du bekommst ganz normal nach dem [lexicon]Encodieren[/lexicon] deine [lexicon]MP4[/lexicon] Datei mit [lexicon]x264[/lexicon] encodiert. Sprich [lexicon]MKV[/lexicon]

Sofern man seine Videobearbeitung eh in AVISynth macht ist der RGB32 Farbraum eh am besten geeignet. Da man dort halt mit Masken arbeiten kann

Da finde ich aber das zusammmischen der Audio in AVISynth viel zu unübersichtlich. [lexicon]Audacity[/lexicon] bietet dabei die bessere Kontrolle drüber. Weshalb man auch das Ganze da macht.

Empfehlung ist aber: Bildbearbeitung sollte über AVISynth -> [lexicon]MeGUI[/lexicon] laufen. Sofern du Audio bearbeitest, kannst du sofern die Programme es erlauben in [lexicon]WAV[/lexicon] wieder zu speichern alle Programme nutzen die du willst. Selbst Schrottasia wäre dann ne Option. Naja... blödes Beispiel xD Aber es geht damit auch Wichtig ist nur das du wieder in [lexicon]WAV[/lexicon] das ganze abspeichern kannst.

Zitat von IsItWaterOrH2O

Ich hab mal 'ne Frage: Ist [lexicon]MeGUI[/lexicon] besser als [lexicon]Handbrake[/lexicon] (nur bezogen auf Qualität/Dateigröße) ?

Mit den richtigen Settings auf jedenfall. Zudem bleibt der [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] immer aktuell, was sich natürlich dann auch auf den Encodiervorgang auswirken kann. Qualität und Dateigröße jetzt.
Hast eigentlich nur Vorteile damit

Zitat von DerET

Ich hatte vorhin mal spaßenshalber eine [lexicon]DXTory[/lexicon] Aufnahme in [lexicon]DXTory[/lexicon] Video [lexicon]Codec[/lexicon] @YUV 420 genommen, bei der das gleiche auftrat.

Beim [lexicon]DXTory[/lexicon] [lexicon]Codec[/lexicon] müsste man das auch irgendwie repariert bekommen. Bei [lexicon]Lagarith[/lexicon] hatte ich ja ne Vorlage wo es richtig war und konnte die Position mit dem Hexeditor ausfindig machen. Beim [lexicon]DXTory[/lexicon] [lexicon]Codec[/lexicon] wird vermutlich auch irgendwo so eine Stelle sein, die man ändern müsste. Kann ich aber schlecht einsehen. Das war bei mir jetzt wirklich nur ein Zufallstreffer das im Hexeditor gefunden zu haben. Ohne den [lexicon]Afterburner[/lexicon] hätte ich das auch nicht gefunden.

Das Problem dazu wurde im Thread [ Video-Tutorial ] MeGUI -- x264 - bester Encoder, beste Videoqualität auf Youtube ausgebig diskutiert und es scheint ein kurioses Problem zu sein das momentan meinen Erkenntnisstand nur [lexicon]DXTory[/lexicon] betrifft und den [lexicon]Camtasia[/lexicon] Recorder unter der Verwendung von [lexicon]Lagarith[/lexicon].

Und zwars geht es um die Farbräume. Ein Fehler der mir vor die Augen gekommen war, als ich meine Aufnahmen in AVISynth bearbeitet habe. Mit [lexicon]Lagarith[/lexicon] eingestellt auf Mode: YV12 und "Use Multithreading" gab mir AVISynth korioser Weise ein RGB32 Signal raus für das Video. Passiert bis jetzt wie gesagt wie ich es gehört habe bei [lexicon]DXTory[/lexicon] und dem [lexicon]Camtasia[/lexicon] Recorder.

Der Fehler wird mittels AVISource verursacht. Sprich das Video wird falsch geladen.

Korrektur bei [lexicon]Lagarith[/lexicon] Aufnahmen unter der Verwendung von AVISource in AVISynth
Der [lexicon]MSI Afterburner[/lexicon] scheint aber damit richtig umgehen zu können, wobei ich dann auch ein Reperaturablauf erstellen konnte.

Noch mal als Hinweis bezüglich des [lexicon]Lagarith[/lexicon] Codecs:

Offset D4 - D7

RGB32 = 0000 0000
YUY2 = 0100 0000
YV12 = 0200 0000

Diese sollten dann auch in AVISynth so geladen werden dann.

Fehlerhafte Werte schwanken im Offset D4 - D7 zurzeit bei Aufnahmen mit [lexicon]DXTory[/lexicon] und mit dem [lexicon]Camtasia[/lexicon] Recorder unter Verwendung des [lexicon]Lagarith[/lexicon] Mode: YV12 + "Use Multithreading" werden die Aufnahmen falsch in AVISynth geladen als RGB32 anstatt YV12 wie eingestellt.

Das sollte noch mal als Übersicht dienen.

Reperatur mit nem Hexeditor an jeweiligen Offset wie oben genannt.

Korrektes Laden der Videos mittels FFVideoSource

Statt mit AVISource das ganz zu laden, nehmt am besten FFVideoShow. Dort wird auch der Farbkanal richtig erkannt.
Anwenden tut ihr FFVideoShow wie folgt im Skript bei MeGUI:

LoadPlugin("D:\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("clip.avi")

Der FFShow Plugin sollte bei [lexicon]MeGUI[/lexicon] mit dabei sein

Zitat von Zantos

Aber dann scheint es wirklich an [lexicon]DXTory[/lexicon] zu liegen, dass der unterschiedliche Header generiert.

Nein, es liegt nicht nur an [lexicon]DXTory[/lexicon]. Meine Aufnahme war ja mit dem [lexicon]Camtasia[/lexicon] Recorder gemacht mit dem [lexicon]Lagarith[/lexicon]. De-M-oN nimmt eh mit [lexicon]DXTory[/lexicon] auf und hatte auch den Fehler.

Es scheint also von Aufnahmeprogrammen abzuhängen. Lösung steht ja jetzt da Ist nur seltsam das die Programme das unterschiedlich machen. Der [lexicon]Afterburner[/lexicon] scheint damit richtig umgehen zu können.

Zitat von Zantos

Ich melde das mal promt an die Entwickler xD . Aber immerhin wissen wir jetzt, das es nicht an Avisynth oder [lexicon]MeGUI[/lexicon] liegt.

Ich hab den Fehler gefunden und zwars ist dieser im Header der Videodatei zu finden.

Ab Offset D4 - D7 ist der Fehler zu finden

Weil beim [lexicon]MSI Afterburner[/lexicon] gab es keine Probleme das er den [lexicon]Lagarith[/lexicon] in YV12 geladen hat in AVISynth. Scheint vermutlich Programmspezifisch zu sein der Fehler wie die ihre Headers schreiben.

Auf jedenfall sieht Offset D4 - D7 im [lexicon]Afterburner[/lexicon] wie folgt aus: 0200 0000

Bei der Aufnahme die in AVISynth ein RGB32 ausspuckt und Decompressorfehler ansagt sieht Offset D4 - D7 so aus: 253A 3B13 <- Werte Variiren ständig

Die beim [lexicon]MSI Afterburner[/lexicon] bleiben aber Konstant. Ändere ich die Werte also auf 0200 0000 , dann ist der Fehler behoben und die Aufnahme wird in AVISynth als YV12 geladen.

Zitat von Zantos

Ich melde das mal promt an die Entwickler xD . Aber immerhin wissen wir jetzt, das es nicht an Avisynth oder [lexicon]MeGUI[/lexicon] liegt.

Ja. Definitiv sollte der [lexicon]Codec[/lexicon] noch mal überprüft werden vom Entwickler. Kann ja nicht sein, wenn man in YV12 aufnimmt, er das in RGB32 läd.

Ich meine, sonst kann ich gleich in RGB aufnehmen, was die [lexicon]Festplatte[/lexicon] hinterher in die Knie zwingt xD

Das sollte schleunigst gelöst werden vom Entwickler xD

Zitat von Sazoga

Man, nich schon wieder. Ich starte den [lexicon]AVS Script Creator[/lexicon] und bei Resize 0 0 ist der Haken drin. Ich habe eben ein Video encodiert und das hat jetzt:

LanczosResize(1904,1072) # [lexicon]Lanczos[/lexicon] (Sharp)

Selbst mit nem Profil kommt der Haken wenn ich ein Video reinziehe immer wieder, ich hatte das schonmal, was soll dieser verkackte Scheiß? Das ist jetzt schon das 5. Video, dass ich neu encodieren darf, echt super Programm

Vergessen in der Profil Config auf Update zu klicken, nach dem du den Haken entfernt hast? Weil ich hab hier schon zig Updates von [lexicon]MeGUI[/lexicon] bekommen und die haben meine Profile nicht geändert bezüglich der Einstellungen.