Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
unschwer zu erkennen ist das eine x86 also 32-Bit Anwendung, sämtliche darin enthaltene Programme sind 32-bit right?
Die beiden haben doch zwei Beiträge über dir geschrieben, dass MeGUI nur die Oberfläche ist und die enthaltenen Tools unabhängig davon wieviel Bit MeGUI hat, in 64 Bit laufen können, weil sie für sich funktionieren und über MeGUI nur angesteuert werden.
Wenn ich mein 4:4:4 material über den SSM in 4:2:2 konvertiere und MeGUI das dann auch so encodieren soll, muss ich den csp i444 befehl nur in 422 ändern?
jop, aber warum willst du das machen? o.o
Etwas Kodierzeit sparen. In YUV444 aufnehmen und skalieren und in YUV422 später kodieren.
Dateigröße wird so meiner Erfahrung nach eher nicht gespart, aber vielleicht waren meine Tests auch allesamt Ausnahmefälle.
Dateigröße wird nicht wirklich gespart, ich glaub zwischen YV12 und YV24 sind es nur etwa 10% Unterschied, so war das also bisher bei mir.
Aber wenn ich schon in 444 aufnehme, würde ich auch in 444 hochladen, damit die Resizer von Youtube noch davon profitieren.
jop, aber warum willst du das machen? o.o
Ja wie Kayten schon sagt Kodierzeit sparen. Video 1 vom aktuellen Projekt hat satte 2h40 Minuten gedauert,
in 4:2:2 dürfte das ja spürbar schneller gehen. Und ob Dateigröße gespart wird weiß ich nicht.. müsste aber eigentlich auch,
da ja doch mehr Informationen verworfen und weniger beibehalten werden = kleinere Dateigröße.
Aber wenn ich schon in 444 aufnehme, würde ich auch in 444 hochladen, damit die Resizer von Youtube noch davon profitieren.
Ich skaliere eh nur auf 1152 und VP9 bekomme ich seit zwei drei Wochen auch nicht mehr.
Dateigröße wird nicht wirklich gespart, ich glaub zwischen YV12 und YV24 sind es nur etwa 10% Unterschied
Das sind bei meinen aktuellen 7,x GB für die erste Folge fast 1GB gespart 
Hast du schon die bframes auf 0 gestellt?
Bframes sind auf 3. Waren das die die nur relevant sind, wenn man Lokal schauen will, bezüglich der Referenzframes beim decodieren?
Und ob Dateigröße gespart wird weiß ich nicht.. müsste aber eigentlich auch,
da ja doch mehr Informationen verworfen und weniger beibehalten werden = kleinere Dateigröße.
Darauf würde ich mich nicht verlassen. Siehe: Encoding-Talk
Dann lieber Preset von Slow auf Medium ändern oder den Encode anderweitig beschleunigen. Das Auslassen der B-Frames würde die Dateigröße erhöhen, wenn ich mich nicht irre.
Preset ist schon auf Medium. Kann auch die CRF erhöhen ist derzeit bei 17, aber wieso nicht auf YUV4:2:2 gehen?
Das Auslassen der B-Frames würde die Dateigröße erhöhen, wenn ich mich nicht irre.
Jop, aber umso komplexer das Video ist umso geringer ist der Effekt der B-Frames auf die Dateigröße und der Geschwindigkeitsunterschied ist nicht gerade ohne, da sie doch einiges an Leistung brauchen.
Was für einen Nachteil bringt sich wenn ich die Bframes auf 0 setze?
Schau mal in den vorherigen Beitrag, da steht es drin. 
wieso nicht auf YUV4:2:2 gehen?
Der Geschwindigkeitsvorteil fällt aus meiner Sicht eher gering aus, da eine Konvertierung durchgeführt werden muss (YUV444 > YUV422), die einen Teil des Geschwindigkeitsschubs wieder auffrisst.
Bei mir lag der Vorteil von YUV420 (!) gegenüber YUV444 bei ~5FPS, ausgehend von ~42FPS vs. ~37FPS, bzw. ~3FPS, ausgehend von ~13FPS vs. ~10FPS.
Presets und Auflösungen mal außen vor gelassen.
Schau mal in den vorherigen Beitrag, da steht es drin.
Ja, dass die Dateigröße steigen soll, aber ich meinte welche Funktion die B-Frames im Video haben.
Ich habe ja gefragt ob das was mit den Referenz-Frames auf sich hat, bezüglich lokaler Abspielbarkeit.
Das war der letzte Stand den ich noch in Erinnerung habe.
Wie man lokal im Video hin und her springen kann ist von dem I-Frames abhängig und diese sind über den GOP geregelt.
Die B-Frames sind hauptsächlich wenn nicht sogar nur für die Kompression wichtig.
Ah, stimmt. Man hat die Wahl zwischen schnellerem Encoding zulasten der Dateigröße oder man nimmt mehr Zeit für's encodieren, dass besser komprimiert wird, ich erinnere mich. Nun aber so oder so fehlt die Zeit vorne oder hinten, ob ich nun länger hochlade und kürzer encodiere oder andersherum..
Das ist ein Faktor den du wieder austesten musst, ob dir die hohere Geschwindigkeit was bringt oder ob es durch die größere Datei aufgefressen wird.
Das Encoding, was Geschwindigkeit und Dateigröße angeht, muss jeder für sich austesten.
Genau so kannst du auch du B-Frames auf 0 stellen und den CRF dann auf 18, durch den höheren CRF müssten die Dateien dann sogar kleiner als vorher werden, obwohl die B-Frames auf 0 sind.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!