Beiträge von Sagaras

Zitat von GelberDrache92

Aber versucht man nicht trotzdem eine gewisse Schärfe im Bild zu halten?

Joa. Aber willst du wirklich die [lexicon]Motion Blur[/lexicon] Frames einen Videos scharf haben? Ist das nicht etwas Fail dann? Weil ist doch dann gar nicht Sinn und Zweck eines [lexicon]Motion Blur[/lexicon] Effektes.

Das nachhaltige Auftragen des Motion Blurs im [lexicon]SSM[/lexicon] z.B. geschieht nach der Skalierung. Einfach weil dieser [lexicon]Motion Blur[/lexicon] das gesamte Video und all seine Frames betrifft. Bedeutet das selbst ruhige Stellen mit leichter Bewegung einem [lexicon]Motion Blur[/lexicon] ausgesetzt sind. Würde dieser Effekt vor der Skalierung auftreten, würde das Bild mehr verwaschen sein als sonstwas. Ist auch nicht im Interesse der User.

Das MB eines Spieles ist aber geziehlt an bestimmten Punkten im Spiel nur zu beobachten und nicht über sämtliche Frames.

Mal so in Kurzfassung:
Spiele mit gezieltem [lexicon]Motion Blur[/lexicon] via [lexicon]GPU[/lexicon] Erzeugung in einem Spiel ist um vieles besser als eine nachträgliche [lexicon]Motion Blur[/lexicon] Erzeugung auf dem Video. Auf dem Video wird es über sämtliche Frames sonst gemacht, im Spiel allerdings geziehlt nur auf Bewegungsabschnitte die vom Spiel für MB ausgewählt wurden.

Edit:
Zudem steigt die Encodegeschwindigkeit wenn MB nicht auf das Video nachträglich aufgesetzt werden muss. Die [lexicon]CPU[/lexicon] Berechnung für diesen [lexicon]Filter[/lexicon] würde dann entfallen. Resultat: schnellere Encodierung. Daher ist [lexicon]Motion Blur[/lexicon] Nutzung in Spielen eine gute Sache seine Videos später besser aussehen zu lassen.

Wer [lexicon]Motion Blur[/lexicon] nicht mag in Spielen, sollte sich dann halt nicht wundern warum das Video sich langsam in Pixelbrei verwandelt auf YT.

Inkomplexes Material braucht z.B. kein [lexicon]Motion Blur[/lexicon]. Sachen wie GBA, [lexicon]SNES[/lexicon], [lexicon]NES[/lexicon], Sega, Amiga, etc. pp.
Natürlich kann darunter das ein oder andere Game mit viel Bewegung (Renngames wo sich der Hintergrund ständig ändert) selbst bei solch alten Konsolen zu einem Pixelsalat sich mutieren auf YT.
Da muss man dann denk ich mal sehen wie man das am besten macht. Da die meisten dieser Konsolen bis eine max [lexicon]Auflösung[/lexicon] von 640x480 hatten (PS2 könnte sogar 1280*1024 erreichen, wenn der Videospeicher nicht 4MB betragen würde ^^)
Aber im Grunde sind alle alten Konsolen im 640x480 Modus. Und gerade da macht es Sinn im RGB Mode aufzunehmen. Weil dann braucht man da kein [lexicon]Motion Blur[/lexicon] um den Pixelbrei zu entgehen später, sondern es wird mit 2 Skalierungen gearbeitet die das Bild später auf 1440p oder höher so gut aussehen lassen mit dem Effekt das man [lexicon]Bitrate[/lexicon] sparrt. Das ist aber dann wieder eine ganz andere Geschichte.

Würdest du denken das das hier vorher eine 256x224 Aufnahme war: https://www.youtube.com/watch?v=8P5NYyeS2iE
Ist mir doch gut gelungen die Skalierung von 256x224 auf 1080p, oder? (1080p reicht meist bei solchen Games)
Und vor allem wäre das später durch die Skalierer sehr Bitratenfreundlich. Gut für schnelle Games, da akurat Skaliert wurde und die Pixel nicht mehr Farbe und somit mehr Speicher einnehmen.

Bei [lexicon]Motion Blur[/lexicon] hingegen wird darauf gearbeitet mehr die gleiche Farbkombination auf mehrere Pixel zu übertragen (Verwischeffekt) um mehr Speicher zu sparen für das Bild.

Zitat von GelberDrache92

Ich würde einfach mal behaupten das ein Bild das kein [lexicon]Motion Blur[/lexicon] hat sauberer hochskaliert werden müsste als eins mit Motion Blure.

Exakt. Es wäre sauberer. ABER... bedenke das wenn es [lexicon]Motion Blur[/lexicon] vor der Skalierung hat es weitaus besser komprimierbarer ist nach der Skalierung.

Ein [lexicon]Motion Blur[/lexicon] behandeltes Video hat ja bereits den Effekt drin das Bewegungen verschwimmen. Um diesen Effekt nicht scharfkantik hochzuskalieren wird Spline16 oder Spline100 genommen um es sanft hochzuskalieren. Bedeutet: Der MB Effekt wird besser, da die genannten Skalierer diesen Effekt ein wenig verstärken. Was bleibt ist ein komprimierbareres Bild als vorher. Weniger Bitratenverbrauch, weniger Pixelbrei, mehr Bildqualität.

Zitat von GelberDrache92

Weil ein Bild mit [lexicon]Motion Blur[/lexicon] ja bereits verwaschen ist und durch die Hochskalierung müsste dieser Effekt doch noch verschlimmert werden, oder?

Verschlimmern? Jein. Er trägt ja positiv dazu bei. Die Skalierung macht den [lexicon]GPU[/lexicon] generierten MB viel weicher, da der [lexicon]GPU[/lexicon] generierte MB im RGB Farbraum vorliegt. Je weicher, desto weniger [lexicon]Bitrate[/lexicon] wird benötigt.

Und im Grunde sieht man es nachher ja eh nicht. Man dreht sich im Spiel -> [lexicon]Motion Blur[/lexicon] wird aktiv -> Umgebung verschwimmt. Man bleibt stehen im Game -> [lexicon]Motion Blur[/lexicon] hält an -> Umgebung wird klar.

[lexicon]Motion Blur[/lexicon] soll ja verwaschen. Wird der Effekt bei der Hochskalierung ein wenig verstärkt, bringt das eigentlich nur für das Bild selbst vorteile.

Hmmm... wie könnte man es noch beschreiben? Stell dir am besten mal vor um dir herum kreist ein roter viereckiger Kasten der immer schneller wird. Dein Auge kommt irgendwann nicht mehr mit und es entsteht [lexicon]Motion Blur[/lexicon] für dein Auge. Jetzt haste das auch noch mit einer Kamera aufgenommen und der Effekt ist dort auch zu sehen, da die Kamera den gleichen physikalischen Gesetzen folgt wie es dein Auge auch tut.

Das Video wird hochskaliert und es tritt mit Spline16/100 ein Verstärkungseffekt auf. Die Übergänge sind viel weicher und sehen dann nicht nur besser aus, sondern sind auch Platzsparender. Stell dir vor du hättest dann mit Point Resize hochskaliert. Dann hätte das Bild gewiss mehr Speicherplatz verbraucht.

Der Output muss dann schon stehen bleiben mit i422 oder i444. Je nachdem. Sonst nimmt er den Standard Output-csp von i420

Und hier mal ein Skaliertest wo die Quelle einmal RGB, einmal YUY2 und einmal YV12 war und dann erst skaliert wurde:
http://www.mediafire.com/downl…gleich_nach_Skalierung.7z

Ich denke den Unterschied sieht man. Würde ich das RGB Skalierte in YV12 wieder skalieren, würde es nicht so schlimm aussehen wie jetzt das YV12 skalierte.

Das ist der Vorteil an höheren Farbräumen.

Edit: Schau am besten mal auf die Bilddateigröße. YV12 ist das größte. Bräuchte auch mehr [lexicon]Bitrate[/lexicon] beim Video. RGB ist sauber geworden, verbraucht weniger, weil kein Geschmiere entstanden ist beim skalieren

Zitat von GelberDrache92

Hei da kann ich doch nichts für
Ich mach nur Copy & Paste xD
Aber der Output soll auf i422 bleiben?

Edit: So hat schon mal geklappt, mit [lexicon]Motion Blur[/lexicon] hat es auch geklappt
So jetzt wird ein Vollvideo gemacht mit 3 Minuten etwas länge

P.s. Ist das mit dem 10Bit Encod Normal das es mir 66% Leistung frisst?

So hier ist das mal das Ergebnis

Alles anzeigen

Dein gesamt Video ist aber nicht RGB24 am Ende. Deine Quelle ist nur RGB24 und der Resize wurde in RGB24 gemacht. Aber nicht der Encode. i422 = YUY2 oder YV16. Halt ein 4:2:2 Planar.

Gleiches auch für das YV12 Video. Wenn du die gleiche RGB Quelle nimmst, wird im [lexicon]SSM[/lexicon] erst in RGB skaliert und dann erst in YV12 konvertiert.

Und hauptsächlich Skalierer profitieren von RGB Material.

Der Entsprechende Encode in eine Farbunterabtastung von 4:4:4 ist nur das i-Tüpfelchen.
Ein Encode in 4:2:2 oder gar 4:2:0 durch RGB Quelle und Saklierung in 4:4:4 ist dennoch recht gut.

Also für einen Vergleich würde ich empfehlen, bei gleicher Quellaufnahme ala RGB folgendes zu machen:

YV24 Encode 4:4:4:
RGB Aufnahme -> YV24 Konvertierung ([lexicon]SSM[/lexicon]) -> YV24 Encode

YUY2/YV16 Encode 4:2:2:
RGB/YUY2 Aufnahme -> YUY2 Konvertierung ([lexicon]SSM[/lexicon]) + für 64Bit Encode ein ConvertToYV16() ergänzen. -> YUY2, YV16 Encode

YV12 Encode 4:2:0:
RGB/YUY2/YV12 Aufnahme -> YV12 Konvertierung ([lexicon]SSM[/lexicon]) + YV12 Encode

Um ein entsprechenden Skaliertest zu machen für die Farbräume muss vorher der Farbraum konvertiert werden. Sprich bei deinem Vergleich zwischen YUY2/YV16 und YV12 so:

YUY2:
RGB Aufnahme -> YUY2 Konvertierung (Manuell in [lexicon]SSM[/lexicon] nach AVISource hinschreiben) -> YUY2 Skalierung -> ConvertToYV16() für 64Bit Encode -> 4:2:2 Encode

YV12:
RGB Aufnahme -> YV12 Konvertierung (Manuell in [lexicon]SSM[/lexicon] nach AVISource hinschreiben) -> YV12 Skalierung -> 4:2:0 Encode

Das müssteste machen um den Skalierunterschied optisch im Bild zu sehen, sonst skalierst du von der RGB Aufnahme immer in der Farbunterabtastung 4:4:4 und der ist nun mal sauber und dann wird erst der Farbraum geändert.

Ist halt später wenn es in 4:4:4 skaliert wurde und du nur am Ende den Farbraum wechselst kaum Optisch merkbar im Bild ob nun 4:4:4 encode war oder nicht. Das muss man dann nah im Detail betrachten dann. Sprich Video downloaden von YT und ein Bild zu Bild Vergleich machen. Dann könnte man was ersehen bei unteren Auflösungsstufen.

Denn: Ob nun 4:4:4 oder 4:2:2 in 4:2:0 auf YT konvertiert wird oder man selbst in 4:2:0 konvertiert ist bei YT egal für die höste Auflösungsstufe des Videos. Rein Skalierer profitieren von höheren Farbräumen. Bedeutet: YT Skaliert als erstes und konvertiert als zweites. Da die Auflösungsstufen auf YT fest sind, sind so ziemlich alle Mod2 Fähig. Daher profitieren höhere Farbräume auch beim runterskalieren der anderen Auflösungsstufen.

Das ist aber halt nur das i-Tüpfelchen. Man kann es machen, man muss es nicht. Allein das eine RGB oder YUY2 Aufnahme dazu am Anfang des ganzen benötigt wird für das ganze Vorhaben.

Denn YV12 in einen höheren Farbraum zu stecken oder YUY2 in YV24 zu bringen ist halt total Sinnfrei und sollte vermieden werden. Gibt aber halt auch Sachen, da muss man das einfach machen.

Weil dein Input-csp auf i444 steht. Lass Input-csp mal einfach weg.

Zitat von GelberDrache92

Wenn erst nach der Skalierung der Farbraum verändert wird, warum hat er dann das RGB24 Skript genommen obwohl erst nach der Skalierung auf YV24 geändert wurde?

Hatte das Skript doch gar nicht erst. Dein erstes Skript was ich gesehen hatte am Anfang war das da in deinem Beitrag:
MeGUI -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

Dort hatte dein Skript ein RGB24 Output. Folglich erkennt die Pipeline es nicht unt konvertiert es in YV12 und dann encodierste das YV12 Material wieder in YV24 hoch. Effekt halt nicht erziehlt.

Dein Encode hier:
MeGUI -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

war schon wesentlich besser. Weil dort haste in YV24 konvertiert das Skript. Folglich erkennt die Pipeline das nun und konvertiert da nix rum. Damit ist der Output in YV24 auch besser gegeben.

Das [lexicon]Rohmaterial[/lexicon] wie es aus der AVS kommt muss passen.
[lexicon]x264[/lexicon].exe würde so ziemlich jeden Farbraum der AVS erkennen.
Aber die Pipeline um AVS Datein für den 64Bit [lexicon]Encoder[/lexicon] nutzbar zu machen benötigt YV12, YV16 und YV24 Input.

Und nun zum ganzen:
RGB32, RGB24, YV24 = Farbunterabtastung von 4:4:4
YUY2, YV16 = Farbunterabtastung von 4:2:2
YV12 = Farbunterabtastung von 4:2:0

Somit sind YUY2 und YV16 zwars identisch von der Farbunterabtastung, jedoch nicht vom Aufbau. Genauso wie RGB32, RGB24 und YV24 identisch sind in der Farbunterabtastung aber halt nicht vom Aufbau.

Was du eigentlich machst ist diese Farbunterabtastung beizubehalten so gut es geht. Denn 4:4:4 ist das schärfste und akkurateste was es gibt.
4:2:2 verschmiert Farben (Chromaanteil) Horizontal
4:2:0 verschmiert die Farben in allen Ausrichtungen.

Also: RGB Aufnahme (4:4:4) in den [lexicon]SSM[/lexicon] geladen wird im RGB24 Mode Skaliert und dann erst in die neue Farbauflösung konvertiert. Sprich nach der Skalierung wird z.B. in YUY2 konvertiert.

Da YUY2 nicht von der Pipeline erkannt wird machste aus YUY2 halt YV16 und hast somit eine 4:2:2 Encode.

Von einer höheren Farbauflösung in eine niedriegeren zu gehen ist ok. Jedoch nicht umgekehrt. Umgekehrt sollte man es versuchen zu vermeiden wenn es sich vermeiden lässt.

So sollte es Qualitativ angeordnet sein. Von Hoch auf niedrig:
RGB32 (Samt [lexicon]Alphakanal[/lexicon]) -> RGB24 = YV24 -> YUY2 = YV16 -> YV12 -> Y8 (Y8 = ohne Chroma. Reines Luma Video)

RGB32 und RGB24 unterscheidet nur den [lexicon]Alphakanal[/lexicon]. Der ist aber bei Aufnahmen meist überflüssig, da man ja bei einer Aufnahme meist nie eine Farbe wählen kann die Transparent sein soll. Üblich also das man von RGB32 für Videobearbeitungen es in RGB24 ändert.

Zitat von GelberDrache92

Weil ich geh davon aus das ein Skript von links nach rechts abgearbeitet wird.
Das heißt erst kommt die Piplin und dann das Skript o.o

Denkfehler deinerseits. Die Parameter kann man anordnen wie man lustig ist.

[lexicon]MeGUI[/lexicon] macht es folgendermaßen:
programm --preset slow --crf 18.0 --output "output" "input"

Und du machst das halt so in der Command:
x264.exe --preset slow --crf 18.0 --output "output" "input"

oder halt mit der Pipeline:
avs4x264.exe --x264-binary "x264.exe" --preset slow --crf 18.0 --output "output" "input"

Aus dem Input bezieht er dann seine Informationen alleine und ruft sich selbst noch mal auf. Nur halt mit Angabe von Frames, FPS, [lexicon]Auflösung[/lexicon] und Farbraum. Sprich alle Inputwerte zieht er sich alleine aus der AVS.

Und dann erst nimmt er sich die Parameter vor die angegeben wurden.

Du darfst da nicht Stur von links nach rechts lesen. Es sind Parameter die sonstwie stehen dürfen

Bei YUY2 machste folgendes:

YUY2 oder RGB24 Aufnahme -> In den [lexicon]SSM[/lexicon] laden und auf YUY2 Konvertierung gehen.

Dann wenn MB und alle [lexicon]Filter[/lexicon] eingestellt sind, gehst du in die AVS Sektion im [lexicon]SSM[/lexicon] und gibst ein als letztes in die [lexicon]Filter[/lexicon] Verarbeitungszone:
ConvertToYV16()

Das wars dann.
Denn YUY2 und YV16 haben beide eine Farbunterabtastung von 4:2:2

Im [lexicon]SSM[/lexicon] wird immer nach dem Skalieren konvertiert. Darum kann man auch wenn das Video im Skript als YUY2 vorliegt ohne Verlust in YV16 konvertieren. Es ändert sich ledeglich der Aufbau des Farbraumes, jedoch nicht die Farbunterabtastung.

Und im [lexicon]Encoder[/lexicon] halt statt i444 nur i422 angeben:
avs4x264mod.exe --x264-binary "x264_64.exe" --preset slow --crf 18.0 --aq-strength 1.25 --output-csp "i422" --output "C:\Temp\Test_YV16_422.264" "C:\Temp\Test_YV16_422.avs"

Also noch mal von vorne:

RGB Aufnahme -> Im [lexicon]SSM[/lexicon] laden und in YV24 konvertieren (RGB und YV24 haben beide eine Farbunterabtastung von 4:4:4. Aber nur YV24 wird von der Pipeline als 4:4:4 erkannt, wärend RGB in YV12 konvertiert wird, da die Pipeline darauf standardmäßig ausgelegt ist.)

Und dann encodierste dieses Skript.

Müsste dann ungefähr so aussehen dieser 4:4:4 Encode: Bild

Nicht gut, wenn da steht das er in YV12 konvertiert, damit ist der Effekt hinfällig.

Hab eben mal nachgeschaut. avs4x264mod kann AVS Datein nur im Farbraum YV12, YV16 und YV24 erkennen.

YV12 - 4:2:0 (Standard)
YV16 - 4:2:2
YV24 - 4:4:4

Sprich dein RGB Video muss in YV24 konvertiert werden. Erst dann bekommste von der Pipeline nicht die entsprechende Warnung das dein Video in YV12 konvertiert wird. Dann hätteste den Effekt für ein reinen 4:4:4 Encode.

Dann erkennt er aber auch 101 Frames. Das sind die, die du angegeben hast im Skript. Nämlich von 0 bis 100 sind 101 Frames.

Was ich aber jetzt auch nicht verstehe warum er 1 I, 14 P und 35 B Frames nur erkennt. Hmm...

Mach aber erst mal den einen Fehler da weg. Vllt erledigt sich das andere von alleine. Wenn nicht, müssen wa mal schauen woran es liegt bei dir da.

Beim Encode ein Abbruch bekommen vllt? Ich denke hier wäre das interessant was der Encode dazu sagt. Also nicht die [lexicon]Mediainfo[/lexicon], sondern der Encodeprozess.

Zitat von GelberDrache92

Und ich hab momentan das Problem das ich fehlerhafte Videos bekomme:
img5.fotos-hochladen.net/uploads/test1duajg9obn.png

Dieses Problem kann entstehen durch das Abspielen des Videos dessen Farbunterabtastung nicht richtig decodiert werden kann für den entsprechenden Codecs.

Da wird dir De-M-oN denk ich weiterhelfen können bezüglich des [lexicon]MPC-HC[/lexicon].

Im Skript selbst denk ich mal das es da kein Problem gibt ;D Das wird wie gesagt ein Decodierproblem sein.

Zitat von GelberDrache92

Aber wie sieht des jetzt aus im Skript kommt ja am Ende 4:2:2 raus.
Im Konsolenbefehl steht aber noch das der Output 4:4:4 sein soll, muss das nicht noch angepasst werden?

Hatte ich schon geschrieben im Edit. Du musst ledeglich i444 in i422 umbenennen im Konsolenbefehl.

Ich picke dir das mal raus aus der Funktion, damit du das siehst:

### Lade Plugins und setze die globalen Variablen ###
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\SplineResize.dll")
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\mvtools2.dll")
Global breite = 3200
Global hoehe = 1800
Global AR = 0


### Lade Videoquellen ###
SetMTMode(3,2)
AVIload("A:\Test\Aufnahme\25fps_2560x1440_RGB24.avi", 0, 0, 0, -0, -0)


### Filter Verarbeitungszone ###
SetMTMode(2)
sum = MSuper(pel = 2)
MFlowBlur(sum, MAnalyse(sum, isb = true), MAnalyse(sum, isb = false), blur = 5.0)


ConvertToYV16()


### Funktion für Video-Laderoutine ###
Function AVIload (String file, int loading, int cl, int co, int cr, int cu) {
    (loading == 1) ? FFIndex(file) : nop()
    clip0 = (loading == 3) ? LWLibavVideoSource(file) : (loading == 2) ? Import(file).KillAudio() : (loading == 1) ? FFVideoSource(file, threads=1) : AVISource(file, false)
    rate1 = (Round(Float(clip0.framerate * 1000)) / 1000) / 2
    rate2 = Round(clip0.framerate) / 2
    rate = (rate1 == rate2) ? 1 : 1001
    ratefaktor = (rate == 1001) ? 1000 : 1
    clip1 = (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate)
    clip1 = clip1.Crop(cl, co, cr, cu)
    clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24() : clip1.ConvertToRGB24() : clip1
    clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.Spline100Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline100Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe)) : clip1.Spline100Resize(breite, hoehe).ConvertToYUY2(matrix = "Rec601")
    back = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (0 == 1) ? ImageReader("", 0, clip1.framecount, clip1.framerate).ChangeFPS(round(clip1.framerate) * ratefaktor, rate).Spline100Resize(breite, hoehe).ConvertToYUY2(matrix = "Rec601") : BlankClip(clip1.framecount, breite, hoehe, "YUY2", round(Clip1.framerate) * ratefaktor, rate).KillAudio() : clip1
    Return (clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYUY2(matrix = "Rec601") : (AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2) : clip1
}

So, Zeile 29 geht es los:
Und zwars wird in Zeile 29 erfragt ob bei der neuen [lexicon]Auflösung[/lexicon] unter Berücksichtigung des Seitenverhältnisses ein ungerader Wert entsteht. Ein ungerader Wert darf zum Beispiel nicht auftreten bei YV12 Material und YUY2 Material. Eines der Werte muss immer Mod 2 Fähig sein. Würde eine [lexicon]Auflösung[/lexicon] einen ungeraden Wert ergeben, dann wird es in RGB24 konvertiert. Die Zeile 29 ist aber ledeglich nur für den Aspect Ratio Teil da und auch nur dann wirksam wenn der Haken dafür gesetzt wurde.

Zeile 30:
Der Clip wird hier in allen Bereichen (Sprich auch unter der Aspect Ratio Voraussicht) Resized auf die neue Größe.
Hier findeste 2 Konstelationen für den Resize. Einmal wenn AR an ist und einmal wenn es aus ist. Der Resize sieht in dieser Zeile dann so aus:
Einmal mit AR:
Clip1.Spline100Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline100Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe))

Und einmal ohne AR:
clip1.Spline100Resize(breite, hoehe).ConvertToYUY2(matrix = "Rec601")

Zeile 31:
Ist wieder für den AR Teil interessant. Hier wird ein Hintergrundbild oder ein BlankClip dfür genutzt um das Video aus Zeile 30 draufzupacken. Zeile 31 ist erst dann aktiv, wenn AR an ist.
Hier wird nun das Hintergrundbild (Oft im RGB Mode) auf eine neue [lexicon]Auflösung[/lexicon] skaliert und dann in den entsprechenden Farbraum konvertiert. Wärend bei Blankclip gleich die feste größe und der Farbraum bestimmt werden kann.
Hintergrundbild (Jetzt leer, weil im [lexicon]SSM[/lexicon] nicht angekreuzt):
ImageReader("", 0, clip1.framecount, clip1.framerate).ChangeFPS(round(clip1.framerate) * ratefaktor, rate).Spline100Resize(breite, hoehe).ConvertToYUY2(matrix = "Rec601")

Und BlankClip:
BlankClip(clip1.framecount, breite, hoehe, "YUY2", round(Clip1.framerate) * ratefaktor, rate).KillAudio()

Tritt keines dieser beiden Sachen ein, liegt der Clip ohne AR vor. Dann wird der Clip 1:1 durchgezogen. (Darum wurde in Zeile 30 auch schon in Farbraum xyz konvertiert, wenn AR nicht aktiv ist)

Zeile 32:
Sollte ein Clip einen anderen Farbraum haben, aber Ziel und Quellauflösung identisch sein, so wird hier auch so ein Clip in den gewünschten Farbraum konvertiert.
(clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYUY2(matrix = "Rec601")

Sollte AR aktiv sein, wird nun Hintergrund und Clip zusammengeführt mit Overlay. Sprich: Ein Hintergrundbild oder das Blankclip aus Zeile 31 wird nun mit dem Clip aus Zeile 30 zusammengesetzt.
Da in Zeile 31 sowohl Hintergrundbild und BlankClip im gewünschten Farbraum vorlagen wie man es im [lexicon]SSM[/lexicon] eingestellt hatte, so wird nun durch das aufsetzen des auf diese durch das Clip, das Clip selbst nun in diesen Farbraum konvertiert.
(AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2)

Sollte AR nicht aktiv sein, so wird nur der Clip zurückgegeben. Und der ist ja schon seit Zeile 30 im gewünschten Farbraum

Du siehst also: Zuerst wird skaliert, dann konvertiert. Nur in Sonderfällen unter der Bedingung das AR aktiv ist, kann es sein das in ein höheren Farbraum konvertiert wird, um auch in ungeraden nicht Mod 2 Fähigen Auflösungen zu skalieren.

Daher wird in Zeile 29 auch geprüft für AR ob die entsprechende neue [lexicon]Auflösung[/lexicon] Mod 2 Fähig ist.
Es ist selten der Fall, aber auch ich habe Videos hier die für eine AR Skalierung später nicht Mod 2 Fähig waren.

Als Beispiel mal ein Video mit folgender [lexicon]Auflösung[/lexicon]:
720 x 416 YV12

Das soll nun auf 1080p 16:9 hochskaliert werden unter AR Voraussetzung:
(720 * 1080) / 416 = 1869,2307692307692307692307692308

Und schon gibt es ein Fehler. YV12 kann das nicht erkennen. Selbst wenn es gerundet wird auf 1869.
Also müsste bei diesem Video in einen höheren Farbraum konvertiert werden. Und da bietet sich RGB halt an. Denn nur im RGB / YV24 Farbraum ist alles Mod 1 Fähig und kann so die 1869 verwerten. Daher siehst du im Skript oftmals dieses ceil zu stehen. Das ist nur zum runden da. Und wie gesagt: Nur für den AR Modus wichtig alles.

Ist AR deaktiviert wird knallhart wie immer das Video auch aussehen mag in 16:9 1080p skaliert.

Zitat von GelberDrache92

Wenn ich auf einen Output von 4:2:2 gehe müsste das nicht dann auch im Konsolen befehl angepasst werden?

Jap. Statt i444 nimmste dann i422

RGB Aufnahme -> in RGB/YV24 skalieren lassen -> dann in YUY2 konvertieren -> [lexicon]Motion Blur[/lexicon] nutzen -> in YV16 konvertieren -> dem [lexicon]CLI[/lexicon] [lexicon]x264[/lexicon] 64Bit [lexicon]Encoder[/lexicon] anbieten über die Pipeline.

Ergebnis ist somit defiitiv besser als üblich. Vor allem arbeiten die Skalierer mit 4:4:4 Farbunterabtatung Material und profitieren dort schon.

Denk aber daran das der [lexicon]SSM[/lexicon] nur einmal Farbraum konvertiert, sollte es aktivert sein. Für üblich immer nach dem Skalieren.

Also:
RGB Aufnahme -> in [lexicon]SSM[/lexicon] in YUY2 konvertieren und somit MB nutzbar machen -> Nach Skriptspeicherung manuell ganz unten im Skript am besten in einer neuen Zeile den Eintrag:
ConvertToYV16()
machen und dann mit dem 10Bit [lexicon]Encoder[/lexicon] [lexicon]encodieren[/lexicon] lassen. Ergebnis wird ein YUY2/YV16 Video. (Beide Planar sind wie gesagt 4:2:2 in der Farbunterabtastung und in dieser Hinsicht identisch.)

Da sollteste dich mit [lexicon]Batch[/lexicon] Datein etwas auseinandersetzen. Solche "Stapel"-Verarbeitungsdatein sollten da doch hilfreich dann sein bei dem was du machen möchtest

Zitat von De-M-oN

Du hast es aber auf [lexicon]x264[/lexicon] geschoben und nicht auf die pipeline. Das wollte ich nur korrigieren. Denn [lexicon]x264[/lexicon] kann sehr wohl auch andere inputs annehmen.

Tschuldigung

Der 64 Bit [lexicon]Encoder[/lexicon] hat doch nix mit dem 32 Bit [lexicon]AVISynth[/lexicon] zu tun ;D Der [lexicon]Encoder[/lexicon] encodiert nur. Der brauch keine [lexicon]Filter[/lexicon].
Du darfst [lexicon]Rendern[/lexicon] und [lexicon]Encodieren[/lexicon] nicht in einen Pott werfen. Das sind zwei unterschiedliche paar Schuhe. Bei [lexicon]AVISynth[/lexicon] und [lexicon]x264[/lexicon] ([lexicon]CLI[/lexicon]) sollte man das eigentlich merken wer berechnet und wer verschlüsselt ;D

Ein gutes Beispiel hatte ich vor 2 Wochen gehabt. Ein Skript was ganz normal lief. Konnte es auch in XVID [lexicon]encodieren[/lexicon] und solche Scherze. Aber was nicht ging war der Encode mit [lexicon]x264[/lexicon]. Und das [lexicon]lag[/lexicon] einfach daran das er für den Encode über 2GB hinaus ging. Ab 2GB ist nämlich Schluss beim 32Bit [lexicon]Encoder[/lexicon]. Das kann dann folgende Ursachen haben: Entweder braucht [lexicon]AVISynth[/lexicon] ein gewissen Speicher und konnte ihn nicht für den [lexicon]Encoder[/lexicon] bereitstellen oder man übersteigt die 2GB indem man z.B. 3GB zum [lexicon]encodieren[/lexicon] benötigt, weil die Umrechnung sehr schwer sind. Das liegt dann meist an der Größe der Frames. Beides wird dann mit einen Malloc size begrüßt von [lexicon]x264[/lexicon].

Um mehr als 2GB nutzen zu können an Speicher für die Berechnungen, nimmt man den 64Bit [lexicon]Encoder[/lexicon]. Hier kann es dann nur Seitens [lexicon]AVISynth[/lexicon] zu fehlern kommen bezüglich der Speichernutzung, weil die ist mit [lexicon]AVISynth[/lexicon] 32Bit halt auf 2GB begrenzt. Tritt aber erst in Kraft wenn zu viele [lexicon]Filter[/lexicon] wirken oder zuviele Quellen geladen wurden.

Für [lexicon]AVISynth[/lexicon] gibt es aber noch eine 64Bit Variante. Aber dann halt ohne MT. Dieses [lexicon]AVISynth[/lexicon] nennt sich dann [lexicon]AVISynth[/lexicon]++ und hat eine modifizierte Standardsyntax bezüglich der Skripte. Normale [lexicon]AVISynth[/lexicon] Skripte gehen damit aber auch. Nur dann ist halt die Frage wie kompatibel die [lexicon]Filter[/lexicon] dann sind.

[lexicon]Blockbuster[/lexicon] ist nicht gleich [lexicon]Motion Blur[/lexicon]. Wenn [lexicon]Blockbuster[/lexicon] geht, weil du in YV24 konvertiert hast, ist das super. Jedoch kannste damit [lexicon]Motion Blur[/lexicon] nicht ersetzen. Aber... [lexicon]Motion Blur[/lexicon] kann man ja unter Umständen vom Spiel erzeugen lassen und wenn es nur ein Mod ist der das tut.

Zudem verursacht [lexicon]Motion Blur[/lexicon] eh Bewegungsunschärfe indem er Frames an bestimmten Punkten Blurt. Daher ist YUY2 und YV12 so eine Art Verstärker dafür fürs Verschmieren xD

Wüsste jetzt aber nicht pauschal was ebenfalls [lexicon]Motion Blur[/lexicon] in [lexicon]AVISynth[/lexicon] erzeugen kann für RGB oder YV24 Material.

Zitat von De-M-oN

Das betrifft aber nur und wirklich NUR die avs4x264mod.exe und nicht [lexicon]x264[/lexicon].

Ja. Aber ohne die Pipeline wird es schwer AVS Skripte zu laden Müssten se alle noch mal [lexicon]Lossless[/lexicon] speichern sonst xD

RGB24, RGB32 und YV24 sind allesamt von der Farbunterabtastung identisch. Es ist egal was du von diesen 3 nimmst. Nur der [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] und einige [lexicon]Filter[/lexicon] im [lexicon]SSM[/lexicon] unterstützen YV24 besser.

Sprich RGB aufnehmen, im [lexicon]SSM[/lexicon] in YV24 konvertieren und glücklich sein das mehr [lexicon]Filter[/lexicon] funktionieren. ;D

Und der [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] encodiert auch nur in YV24. Kann aber auch ein RGB Output CSP erzeugen, wenn es sein muss. Aber ich denke YV24 ist RGB so weit es geht identisch, bis auf den Farbraumaufbau. Farbunterabtastung ist identisch und somit auch das Bild im Endeffekt.

Zitat von GelberDrache92

Jetzt würde dann die Bearbeitung mit RGB gehen nur würde das was am ende rauskommt YV12 sein?
Also müsste ich über die Konsole das Skript starten damit ich am Ende auch noch immer RGB habe?

Einen 4:4:4 Planar, ja.

Zitat von GelberDrache92

Das heißt dadurch das ich [lexicon]Motion Blur[/lexicon] nicht nutzen kann müsste ich auf [lexicon]Blockbuster[/lexicon] zurück greifen und dann in YV24 aufnehmen?

Die meisten Aufnahmeprogramme nehmen aber in RGB dann auf, statt YV24. Aber halt 4:4:4. Am Ende sind YV24 und RGB identisch.

Zitat von GelberDrache92

Kurze frage... ab welcher [lexicon]Auflösung[/lexicon] gibt Youtube 1440p?

1170p glaub ich war das minimale um 1440p zu bekommen.

Zitat von GelberDrache92

Punkt 1. Skripte kann ich nicht mehr nutzen?

Im Skript müssen nur der entsprechenden Zeilen rauskommentiert oder rausgelöscht werden und kann dann weiter genutzt werden. Es dürfen wie gesagt für ein RGB Video keine [lexicon]Filter[/lexicon] genutzt werden die ein anderen Farbraum bevorzugen.

Hätteste dein RGB Video in YV24 konvertiert, wäre auch noch nicht mal was passiert, denn beides sind 4:4:4 Farbräume. Da würde dann z.B. Tweak wieder gehen, da Tweak nur ein YUV Farbraum braucht.

Es würde nur MSuper nicht gehen, da er wie du es schon selbst geschriebe hast nur YV12 und YUY2 haben möchte.

Halt ein bisschen abwegen. Mit dem [lexicon]Encoder[/lexicon] wird ja auch nicht in ein RGB Video encodiert später, sondern in ein entsprechenden YUV Farbraum wie YV24, YUY2, YV16, YV12

Zitat von GelberDrache92

Punkt 2. Konsole?

Türlich Konsole. [lexicon]MeGUI[/lexicon] will ja schließlich alles in YV12 wandeln.

So ruft man sie auf:
Auf alten Systemen wie XP oder Vista klickt man auf Start -> Ausführen und erhält dann so ein Fenster:
Bild1
Nach der Eingabe von CMD einfach auf OK noch klicken.

Bei Vista oder höher mit dem neuen Style sieht es so aus:
Bild2

Nachdem CMD offen ist, wechselt man ins [lexicon]MeGUI[/lexicon] Unterverzeichnis wo sich der [lexicon]x264[/lexicon] 10Bit [lexicon]Encoder[/lexicon] befindet (der 8Bit [lexicon]Encoder[/lexicon] ist das normale [lexicon]x264[/lexicon] Verzeichnis. Ich gehe hier mal auf den 10Bit [lexicon]Encoder[/lexicon] ein.)

Auf 64Bit sieht das ungefähr so aus:
Bild3

Und auf 32Bit sieht es so aus:
Bild4

Nach einem Enter nach dieser langen Eingabe würde er das AVS Skript [lexicon]encodieren[/lexicon] in *.264 was man dann wieder mit MKVMerge [lexicon]muxen[/lexicon] müsste.

Den [lexicon]Encoder[/lexicon] kann man aber auch anders nutzen. Im [lexicon]AvsPmod[/lexicon] z.B. ist es möglich externe [lexicon]Encoder[/lexicon] zu nutzen. Naja, man gibt einfach diesen langen Parameter halt als Externen [lexicon]Encoder[/lexicon] an.

Auch möglich: Die Verwendung von [lexicon]Batch[/lexicon] Datein die dann den Encode via Click schon machen.

MSuper ist ein [lexicon]Filter[/lexicon] der ein YUV Farbraum benötigt wie YV12 und YUY2.

Wenn man ein RGB Video im [lexicon]SSM[/lexicon] nimmt, ist man natürlich etwas eingeschränkt was die [lexicon]Filter[/lexicon] betrifft.

Sowas wie Tweak, [lexicon]Blockbuster[/lexicon] etc. sind [lexicon]Filter[/lexicon] die ein YUV Farbraum benötigen. Die [lexicon]Filter[/lexicon] sind darauf geeicht mit Luma und Chroma in diesen speziellen Modi zu kontrollieren. Ein RGB Video ist jedoch alles andere als in Luma und Chroma unterteilt. Auch die Farbunterabtastungen sind verschieden. Um das alles zu berücksichtigen müssten diese Mathematischen Algorithmen für die entsprechenden Farbräume in den Filtern auch einprogrammiert werden.

Und nun ist die entscheidene Frage: Welcher Farbraum wird am häufigsten verwendet? Natürlich die Sparsamsten wie YV12, YUY2
Es sind die bekanntesten und gebräuchlichsten Farbräume. RGB und YV24 sind Sonderfälle.

Ich habe YV24 und RGB24 im [lexicon]SSM[/lexicon] erlaubt, da es vor allem Spiele gewidmet ist. Denn gerade Spiele die im RGB32 oder RGB24 Mode auf dem Rechner laufen und auch im AVS Skript im RGB Mode skaliert werden, können 100% bessere Bildergebnisse erziehlen.

[lexicon]MeGUI[/lexicon] konvertiert alles in YV12 für die Videos.

Aber ist ja egal, denn sowohl 64 als auch 32 Bit [lexicon]Encoder[/lexicon] kann man für AVS Skripte in der Konsole wie gewohnt in [lexicon]MeGUI[/lexicon] auch [lexicon]encodieren[/lexicon] + in den gewünschten Farbraum.

Für den 64Bit [lexicon]Encoder[/lexicon] ist nur wichtig:
AVS YUY2 muss in YV16 konvertiert werden (Es handelt sich dabei um 4:2:2 Planer und sehen identisch aus später)

Für 64Bit in der Konsole:
avs4x264mod.exe --x264-binary "x264-10b_64.exe" --preset slow --crf 18.0 --aq-strength 1.25 --input-csp "i444" --output-csp "i444" --output "output.264" "RGB.avs"

Für 32Bit in der Konsole:
x264-10b.exe --preset slow --crf 18.0 --aq-strength 1.25 --input-csp "i444" --output-csp "i444" --output "output.264" "RGB.avs"

Sieht beides fast identisch aus. Nur für den 64Bit [lexicon]Encoder[/lexicon] muss eine Pipeline her, damit AVS Skripte encodiert werden können. Zudem kann der 64Bit [lexicon]Encoder[/lexicon] wie gesagt nur YV12, YV16 und RGB Input erkennen. Wenn er das nicht erkennt, konvertiert er das immer erst in YV12.

Das ganze Unterfangen bringt YT zum einen eine bessere Quelle die absolut sauber wär von Chroma Verschmierung und zum anderen eignet sich solch eine Quelle für eine bessere Encodierung in YV12. So würde die YV12 Konvertierung nur von YT noch stattfinden.

Das wäre aber nur das i-Tüpfelchen auf dem ganzen Kuchen

In erster Linie profitieren die Skalierer von RGB Quellen mehr als alles andere.