Hilfe zu Einstellungen bzgl. Renderzeiten

Zitat von DrWolfsherz

und schneiden werde ich wohl nicht mehr so viel (bis gar nicht mehr), weil umständlich ohne Ende

Auch mein größer Kritikpunkt

Zitat von DrWolfsherz

Was den Upload angeht, und wieso ich nicht gleich Lossless hochlade... Ich möchte nicht jeden Monat eine neue Festplatte kaufen um meine Let's Plays aufzubewahren... Was, wenn YouTube mal nicht mehr ist? Dann soll alles futsch sein? Nee, ich bewahre die gerenderten Dateien auf, wie wohl die meisten.

Du hältst es für wahrscheinlich das GOOGLE mal nicht mehr sein könnte? Ich glaube vorher muss das ganze Internet aussterben, bevor Google ausm Internet verschwindet.

Doch ich schmeiß das alles wech, wenns auf Youtube ist. Anfangs hab ich auch horten wollen, aber irgendwann werden auch die verlustcodierten Dateien sich summieren. Und ich bau jetzt hier kein Festplattenlager auf.
Die Dateien sind via mehreren Kopien auf den Youtube Servern gesichert. Es gibt keinen sichereren Ort seine Videos zu sichern als auf Youtube. Abgesehen von der Recodierung, aber wenn man die ID 315 Codierung von denen schnappt die ab 1750 Pixel Videhöhe beginnt, sieht deren Codierung schon nahezu bis vollständig wie dein Quellvideo aus.

Zitat von DrWolfsherz

Außerdem habe ich beim SSM immer das Problem gehabt, dass ich meine Audiospur vom Mikrofon nicht von Mono auf Stereo hochmischen konnte... Und zwar indem er nur den linken Kanal benutzt, da ansonsten die Lautstärke halbiert ist

In Stereo aufnehmen, die Spuren extrahieren, dann in einem Audiobearbeitungsprogramm den rechten Kanal entfernen und den linken behalten: NICHT(!) Konvertieren. Dann isses wieder 50% leiser wegen dem Mischverhältnis (!)

Zitat von DrWolfsherz

Audiotracks über SSM exportiert und via Audacity die Mikrofonspur zu Mono umgewandelt ohne Lautstärkeverlust.

Wenn du wirklich konvertiert hast, statt nur den rechten Kanal zu entfernen, fänd ichs überraschend wenn sich die Lautstärke nicht geändert haben sollte.

Zitat von DrWolfsherz

Zum einen hat sich die Renderzeit von vormals ca. 2 x Videolänge auf ca. 0,5 x Videolänge verkürzt (WUNDERBAR!)

x264cli ist ja auch erheblich effizienter + Farbkonvertierungswegfall bzw allgemein die Verarbeitung der NLE weg.

Zitat von DrWolfsherz

Ich muss sagen, das gefällt mir so weit ziemlich gut. Klar ist die Bearbeitung jetzt wirklich etwas mühsamer, und schneiden werde ich wohl nicht mehr so viel (bis gar nicht mehr), weil umständlich ohne Ende

Geht eig. Nicht verkrampfen dabei. Nutzt die Vorschau von SSM und dann isses doch auch recht komfortabel. Komplexer wirds ja erst, wenn du Stellen aus dem Video an anderen Positionen verschieben willst.
Aber einfach nur paar Dinge lediglich rausschmeißen aus dem Video ist eig. kein unterschied zu einer Timeline NLE, du spulst in virtualdub halt durch und gibst in SSM die framebereiche an, die du behalten willst.

Zitat von DrWolfsherz

Zu dem Hochskalieren: Das sieht aber nicht so gut aus, als würde ich in der Einstellung spielen, oder?

Spline36 macht recht gute Ergebnisse, aber wenn du direkt in 1440p spielen kannst, umso besser. Da würde sich dann auch anbieten auf 3200x1800 anschließend zu skalieren, dann kämest du an den ID 315 Encode von Youtube ran, der wie gesagt fast komplett wie die Quelle aussieht. Voraussetzung ist natürlich das Youtube deine Videos zu VP9 codiert.

Zitat von DrWolfsherz

ich bin selber ganz beeindruckt.

Naja deine CPU ist jetzt aber ja auch nicht komplett scheiße nech
___

Also bei 200 mbit Upload würd ich dennoch nich lange fackeln und lossless arbeiten. Kombiniert mit einem RAID 0 Festplattensystem wirst dich wundern, wie das die Codierung nochmal beschleunigt, weil so ja die ganzen Lossy Mechanismen wegfallen.
etwaige Auflösungsskalierung würde dennoch wieder ein bisschen bremsen. Lossless Upload auf Youtube ergibt auch bestes Material für deren Re-encode deines Videos.

Chroma Subsampling auf 4:4:4 bei Aufnahme und Codierung hilft auch nochmal der Qualität

PS: Die zig MeGUI Screenshots kannste dir sparen in Zukunft. Steht doch alles unten in der Commandline ;D Kopier uns also nur diese ;D

Bei MeGUI müsstest du in x264 config rein und bei custom commandline dann:

--output-csp i444

SSM müsste dafür auf YV24 gestellt werden bei Farbe.
MeGUI's Frage ob YV12 konvertierung geaddet werden soll natürlich dann verneinen.

Guck aber vorher nach ob YUV 4:4:4 nicht zu viel ist für vor allem deine Festplatte. Das wird nämlich spürbar mehr Speicher benötigen.

Der Auflösungsskalierer freut sich zb auch über solche Quelle.

>16bit kann man machen für Filter.
>48khz kann für den Kompressor besser sein.

Für Youtube dann aber wieder auf 48khz, 16bit gehen. Bei 16bit dann ein Dithering verwenden. Aber erst als letzte Speicherung dann auf 16bit gehen und dithern. Dithern absolut nur einmalig und ganz am Ende machen.

Da DXTory und co leider bei 16bit truncaten, statt dithern, könnte eine 32bit Aufnahme sogar ziemlich Sinn machen.

Wenn du schon Video nicht Lossless machen willst, würd ich zumindest Audio Lossless machen. Das wäre dann das FLAC Format. Auf höchste Kompression gestellt kommt ungefähr 50% der WAVE Größe raus.

Zitat von DrWolfsherz

Aus diversen Gründen bleibe ich aber noch bei 1080p was die Videos angeht.

Mach wenigstens 2048x1152. Sonst kommt auf youtube nur pampe raus.

Zitat von DrWolfsherz

Der wichtigste ist, dass immer noch die allermeisten Leute eben 1080p Bildschirme zu Hause stehen haben. Wenn sie dann ein Spiel von z.B. 1440p runterskaliert auf 1080p anschauen, ist Schrift und andere Feinheiten nicht mehr so hübsch anzusehen. Als Beispiel ist hier RimWorld zu nehmen, dass ich derzeit auf dem Kanal laufen habe. Nach Experimenten mit 1440p haben einige Zuschauer tatsächlich die kleine und nicht mehr gut lesbare Schrift bemängelt: Zu Recht.

Dann skalier wenigstens hoch. Aber 1080p ist auf Youtube = Garantierte Pampe. Dann haste vllt die Schrift größer, aber trotzdem scheiße lesbar, weil so schön runterkomprimiert

Ich persönlich würde in das spielen, was dein Monitor nativ kann. Ist doch kacke, wenn du selber mit interpoliertem Bild seitens Monitors spielen müsstest + noch schlechtere Spielgrafik. Würde ich persönlich ja nicht wollen. Noch hinzukommend, das Youtube wie gesagt dir dann auch dein Video viel stärker runterkomprimiert.

Ja.
_
Ja. Aber avs4x264mod.exe die den 32bit Input pipelined zu 64bit x264, damit du trotz 32bit avisynth mit 64bit x264 codieren kannst, kann nur YV12, YV16 und YV24.
MagicYUV nimmt aber im YUV 4:4:4 Interleaved auf, nicht die Planar Variante YV24. Daher muss es von SSM zu YV24 konvertiert werden. Hier entsteht kein Verlust, da nur von Interleaved auf Planar gewechselt wird, die Chroma bleibt ja bei 4:4:4 dann.

Bei 4:2:2 Aufnahme musste YUY2 nehmen und den Haken mit dem YV16 fix drin belassen.

Zitat von De-M-oN

MagicYUV nimmt aber im YUV 4:4:4 Interleaved auf, nicht die Planar Variante YV24. Daher muss es von SSM zu YV24 konvertiert werden.

Nö. MagicYUV nimmt in YV24 und nicht in I444 auf. Was willst du denn mit I444 anfangen?
Willst du das AVISynth es als RGB32 einlesen tut? xD Ich glaube nicht. Daher ist auch bei der Decompression bei YUV 4:4:4 kein Haken drin ;D

Siehe selbst unter Internal compressed format: https://magicyuv.com/index.php…res/13-colorspace-support

Der compress input Format ist das was MagicYUV akzeptieren kann an Farbräumen. MagicYUV selbst kopiert den Farbraum oder konvertiert entsprechend je nachdem wie man ihn einstellt unter mode(conversion)

Zitat von Sagaras

Nö. MagicYUV nimmt in YV24 und nicht in I444 auf. Was willst du denn mit I444 anfangen?
Willst du das AVISynth es als RGB32 einlesen tut? xD Ich glaube nicht. Daher ist auch bei der Decompression bei YUV 4:4:4 kein Haken drin ;D

Na dann müsste ja sogar ein "Gleich" hier funktionieren bei SSM?

Naja ich kenns eig. nur das immer in Interleaved gearbeitet wird von den Lossless vfw Codecs, außer DXTory Codec, der benutzt ja auch YV24 bei 4:4:4.
Aber gut dann isses bei 4:4:4 wohl anders xD

Zitat von De-M-oN

Na dann müsste ja sogar ein "Gleich" hier funktionieren bei SSM?

Kannst du dann machen, ja.

Zitat von Sagaras

MagicYUV nimmt in YV24 und nicht in I444 auf

Ich entschuldige mich. YV24 und I444 sind das gleiche.
Der Unterschied liegt bei der Kanal Reihenfolge

YV24 = Y, V, U
I444 = Y, U, V

Wenn man YV24 in I444 ändern möchte kann man ja UV tauschen lassen mit AVISynth z.B. mit SwapUV

Aber das ändert nix am Bild und auch nix daran das es sich um Planar handelt.

Edit:
YUV444i wäre die korrekte Bezeichnung für eine interleaved Variante für YUV444
Findest du aber in keinem Codec den ihr hier im Forum benutzt. Weder in MagicYUV, noch bei UTVideo, noch bei Lagarith.

In der Regel werden Planar verwendet um Speicher zu sparen.
Mit YUV444i würdest du vermutlich eine größere Datei erhalten als mit RGB24

Zitat von De-M-oN

Naja ich kenns eig. nur das immer in Interleaved gearbeitet wird von den Lossless vfw Codecs, außer DXTory Codec, der benutzt ja auch YV24 bei 4:4:4.
Aber gut dann isses bei 4:4:4 wohl anders xD

Du denkst zu kompliziert vermutlich

Pass auf: Interleaved heißt erst mal das jedes Bild verschachtelt gespeichert wird. Das heißt das jede Farbe einzeln separat gespeichert wird. Dazu gehört:
RGB32, RGB24, YUY2 und Y8

Das wird meist bevorzugt, da es die einfachste Variante ist beim Programmieren.
Y8 kann beide Varianten fahren. Dem ist das egal

Alles was auf Planar läuft wird in separaten Blöcken in den Speicher geschrieben. Und das steht im Kontrast zu der Verschachtelten Variante.
Dazu gehört:
AYUV, YV24, YV16, YV12 und Y8

Bei YUY2 kannst du verschiedene Varianten anwenden wie du die Kanäle darstellst (Interleaved):
YUY2 = UYVY, YUYV
I422 = YUYV, YVYU

Bei YV12 gibt es lediglich (Planar):
YV12 = YVU
I420 = YUV

Und RGB kannst du auch anders darstellen (Interleaved):
RGB = BGR

In BGR nimmt z.B. Fraps auf, was AVISynth nicht erkennt und es als RGB32 einlesen tut, obwohl die BGR Variante von Fraps 24Bit ist.

Von NV12 ist NV21 die Variante mit dem Vertauschten Kanal (Semi - Planar).
NV12 = YUV
NV21 = YVU

Die NV Farbräume sind Semi-Planar Modelle. 2 Planar statt 1. 1 Planar für Luminanz und 1 Planar für Chrominanz
Die NV Farbräume sind aufgrund dessen auch viel besser zu Wirtschaften wenn man sie speichern will. Geht viel schneller

Edit:
Bei nem Planar hast du lediglich nur Y, U und V als ein Planar.

Mach lieber zur Sicherheit im SSM nicht auf gleich, sondern auf YUY2.

Dann biste dir 100% Sicher das da auch YUV 4:2:2 Farbraum durchgeht. Und wenn es vorher schon YUY2 ist, dann macht SSM bzw. AVISynth mit den ConvertToYUY2 auch nix mehr dran, dann schleust der das einfach durch.

Kannste machen wie du möchtest.

Bei 4:2:2 Aufnahme in jedem Fall YUY2 bei SSM, sonst greift der YV16 Fix von SSM nicht und den brauchste hier in jedem Fall.

Zitat von DrWolfsherz

Ist es tatsächlich besser in YUV444 hochzuladen? Bringt das eine spürbare Verbesserung?

Mach dir selbst ein Bild.

Far Cry Primal, UT Video RGB, High 10
Far Cry Primal, UT Video RGB, RAW!

Wenn du findest, dass das zweite Video um Welten besser aussieht, lohnt es sich für dich vielleicht sogar, einen höheren Farbraum hochzuladen.

In YUV444 zu kodieren ändert meiner Erfahrung nach überhaupt nichts an der Dateigröße, nur die Kodierung dauert etwas länger. Nimmt man aber sowieso bereits in YUV444 auf, um eine gute Ausgangsbasis für die Skalierung zu besitzen, so wäre der Geschwindigkeitsvorteil durch eine finale Konvertierung nach YUV420 ziemlich gering. Die Konvertierung selbst frisst den Vorteil größtenteils wieder auf, sodass man bei Skalierung idealerweise komplett in YUV444 arbeiten sollte.

Könnte ich beispielsweise problemlos in 1800p aufnehmen, so würde ich es direkt in YUV420 machen, um sowohl die HDDs zu entlasten als auch die Kodierung zu beschleunigen. Da ich aktuell aber auf 1440p limitiert bin, kann man den höheren Farbraum für die Skalierung nutzen.

@Julien
Hast du MediaInfos zu beiden Varianten?

Zitat von Kayten

Hast du MediaInfos zu beiden Varianten?

Wenn, dann habe ich sie irgendwo hier im Forum gelassen... Die Videos habe ich ja schon mal im Encoding-Thread verlinkt. Aber ich glaube die Mediainfos gibt es nicht mehr.
Ist eigentlich auch egal, es war ja nur ein Test um zu sehen, wie gut YouTube skalieren kann mit RGB-Material. Und für mein Empfinden ist alles über 4:2:0 extrem unnötig, sofern man nicht gerade mehrere einen Pixel breite Linien mit Rot (255,0,0), Grün (0,255,0) und Blau (0,0,255) im Video hat.