MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

@360GameTv
Du müsstest eigentlich nur noch den Resize-Befehl hinzuschreiben. Am besten so: Spline16Resize(3200,1800)

Zitat von Julien

Spline16Resize(3200,1800)

Nutzt man nicht inzwischen Spline100? o.o

Zitat von GelberDrache92

Nutzt man nicht inzwischen Spline100? o.o

Ist wohl eine Frage des persönlichen Geschmacks. Hier gibt es mehr Infos dazu: MeGUI -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

Nenn mir ein Vorteil den ich dadurch hätte? Ich sehe für mich, in meinen Videobereich, keinen. Außerdem müsste ich mich da erst wieder einlesen usw, Im Moment weiß ich wie alles funktioniert und was am Ende rauskommt

@Julien

Danke!

mfg

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.

Jetzt hast du mich falsch verstanden xD
Ich wollte eigentlich nur wissen ob das Output i422 stehen bleiben soll da ja durch das Skript YV16 vorgeschrieben ist.
Dadurch das ja der Input mit i422 draußen ist muss er sich ja denn Wert außem Skript bzw aus dem Videomaterial holen.
Und ich wollte nur deswegen wissen ob das Output auch noch gebracht wird da er sich das da ja auch aus dem Skript bzw außem Videomaterial auslesen könnte

P.s. Da hat man schon denn Unterschied zwischen RGB24 also auf Youtube YV16 und YV12

RGB24

YV12

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

Hei, ich hab ein kleines Problem. In letzter Zeit loopt sich meine Tonspur am Ende der Aufnahme immer kurz d.h. wenn ich jetzt z.B. Tschüss sage dann wiederholt sich das eine Sekunde später und dann ist das Video zu Ende. Ich hatte das Vorher nie aber jetzt kommt das plötzlich. Ich nehme in 30FPS auf, [lexicon]Sony Vegas[/lexicon] ist auf 30FPS gestellt und das Skript hat auch 30FPS eingeschrieben also kann es ja daran nicht liegen oder? Ich nehme mit [lexicon]DXTory[/lexicon] auf, exportiere mir dann die Audiospur und bearbeite sie in [lexicon]Audacity[/lexicon]. In [lexicon]Audacity[/lexicon]/der Rohaufnahme ist der Loop nicht zu hören. Ich hoffe mir kann da einer helfen da mich das schon sehr stört.

Du hast du Tonspure in [lexicon]Sony Vegas[/lexicon] und gibts sie übern Framserever an [lexicon]MeGui[/lexicon]?
Wenn ja, dann hast du da schon das Problem.
Einfach direkt aus [lexicon]Sony Vegas[/lexicon] als [lexicon]Flac[/lexicon] raus und das Problem ist weg.

Perfekt! Danke klappt

Ich hoffe das passt hier. Mal eine Frage, ich habe eine Text mit farbigen Verlauf. In [lexicon]Sony Vegas[/lexicon] und [lexicon]Megui[/lexicon] Vorschau sieht das astrein aus, rendere ich das Video und schau es mir über MPC mit Demons Einstellungen an, ist der Farbverlauf weg und die Schrift ist kaum noch lesbar, auf YT das selbe? Wie kann das sein bzw wo ist der Fehler?

Vegas / [lexicon]Megui[/lexicon] Screen

http://i.imgur.com/RR3ZhBf.jpg

MPC Screen

http://i.imgur.com/1hN8dqg.jpg

So sieht das dann auch auf YT aus (nicht dieses Video, ist ein experimentielles Vidoe um einiges zu testen aber bei anderen Videos wo ich die Schrift schon so benutzt habe)

So ich komm nochmal auf das Thema zurück mit:
"Wir sollen doch am besten Motion Blure vom Spiel benutzen"

Abgesehen von Spielen wo das [lexicon]Motion Blur[/lexicon] einfach nur übertrieben ist.
Müsste nicht eine Aufnahme ohne [lexicon]Motion Blur[/lexicon] am Ende besser aus sehen als eine mit?
Gerade im Bezug aufs [lexicon]Hochskalieren[/lexicon].
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.
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?

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.

Ok...
Gut das stimmt natürlich das eine MB der in RGB arbeitet besser arbeiten kann als einer in YuY2....
Gut kann natürlich auch sein das ich immer MB von Spielen im Kopf habe die einfach nur grauenhaft sind xD

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

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 Sagaras

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.

Das ist eine Erklärung die ich auch so akzeptieren kann

Keiner ne Idee?