Frage zu Videogröße (anfänger)

Einmal deinen kompletten Workflow beschreiben, damit wir am richtigen Punkt optimieren können.

Am besten dazu aus diesem Thread -> Wie stelle ich meine Frage richtig? <- Punkt 1 bis 4 soweit beherzigen.

Wir können nur dann helfen, wenn wir wissen wie du halt vorgehst und deine Einstellungen jeweils sind. Von der Aufnahme bis hin zum finalen Encoding dessen Ergebnis du hochlädst.

Also in der Regel kommt eine fertige Folge bei mir auf ca. 664MB, bei durchschnittlich 25 Minuten Laufzeit und einer Quelldatei von 65GB.

3-5GB ist definitiv zu groß und nicht wirklich gut komprimiert. Womit encodierst du deine Videos? Hier im Forum gibt's gute Tutorials zu h264 bzw. x264 als codec, MeGUI und SSM zum encodieren samt Einstellungen. (Forum->Audio/Video->Tutorials)

Zitat von Chron

3-5GB ist definitiv zu groß und nicht wirklich gut komprimiert.

Muss nicht sein, da es hier auf länge und Komplexität des Videos ankommt.

Zitat von GelberDrache92

Muss nicht sein, da es hier auf länge und Komplexität des Videos ankommt.

Stimmt schon, aber selbst bei Life is Strange kam ich auf 1,2GB. Er spielt Layers of Fear und seine Folgen sind 17-23 Min, da lag ich meist drüber.

Zitat von ElPolloDiablo

Nur 600mb? Was ist den deine Bitrate?
Also bei mir sind es in der Regel 1,4GB bei Datein von einer Länge von 20-25min

Wenn dein Videomaterial keine Stunde ergibt, dann frage ich mich wirklich wie du auf diese hohe Zahl kommst.

Meinst du nicht niedrig? Ich hab CRF auf 17. 660mb war jetzt mein aktuelles Projekt, das ist als Pixel Sidescroller wohl schon 'n Stück leichter. Wenn ich mich recht erinnere lag ich bei Life is Strange und anderen Projekten auch so bei 1,2-1,4GB rum. Aber das ist eben noch weit von 5GB entfernt. Eine Folge geht zwischen 22-26 Minuten.

Gibt's ne Möglichkeit nachträglich auf YT oder so zu schauen, wie groß die hochgeladenen Dateien waren?

Na, 5 GB toppe ich mit jedem Rennspiel.
Aber ich lad halt auch in 4k hoch, während seine Videos 720p haben...

Aber dafür müsste @HOOL uns halt sagen, wie genau er seine Videos vor dem Upload bearbeitet.

Ihr knallt hier mit Zahlen um euch und vergesst letztendlich das ein Video das mit Bitraten encodiert mittels CRF Verfahren, man NIE zu 100% sagen kann wie groß die Datei wird.

Zum einen ist es Abhängig von Auflösung und FPS und Farbraum, zum anderen spielen auch Detailgrade der Frames eine bedeutende Rolle.

Man kann z.B. ein Super Nintendo Tetris Game was in RGB aufgenommen wurde mit z.B. 320x240 und 60FPS gut und gerne mit xBRZ in 1440p60 YV12 mit CRF 23 bei einer Gesamtlänge von 25min gut und gerne mal bis auf 100MB runterbringen.

Warum? Weil das Spiel so dermaßen Inkomplexe Frames hat das man da soviel Bitrate sparen kann. Kaum Bewegung, der größte Teil des Bildes ist das HUD Gitter und ein kleines Feldchen mit ein paar Blöcken rutscht da runter und das nicht mal schnell.

Oder wir haben Spiele wie Far Cry Primal oder Uncharted 4 oder hat man nicht gesehen für ein Grafiknuttenspiel und das Encodierte Video würde bei gleicher Länge und gleichen Einstellungen wie beim Tetrisgame auf über 3GB kommen.

Und das ist einfach so. Es wird halt beim CRF nach Qualität encodiert.
Würde man nach Bitraten encodieren würden die meisten eh aufgeben, weil sie A) das Video nicht einschätzen können wieviel Bitrate notwendig wäre und B) die Qualität der Video wäre nie identisch. Eines würde vllt gut aussehen, weil inkomplexe Frames und das andere würde in ein Meer von Blöcken oder Geschmiere ausarten, weil zu wenig Bitrate.

CRF encodiert in die Videos in VBR und mittels eines Faktors wird die Bitrate entsprechend der Qualität verteilt. Das ist ein enormer Vorteil gerade für Let's Player die ohnehin schon unzufrieden meist sind mit ihren Videos und da immer mehr rausholen wollen. Und das geht momentan mit dem CRF Verfahren am besten.

Bei VP9 kann man sogar ein 2pass CRF Encode durchführen. Das ist richtig gut, dauert aber enorm lange. Eventuell wird das deshalb bei YT dauern und somit auch bessere Encodes mit sich führen.

Der TE soll erst mal sein Workflow beschreiben. Weil wenn ich schon lese das er da mit VLC oder WinFF encodieren möchte oder macht, dann ist sein Workflow eventuell schon verkehrt. Den sollte er halt erst einmal ausführlich schildern. Ansonsten seh ich jetzt nicht was wir da allgemein optimieren müssen.

Vllt. nimmt er mit Shadowplay auf, haut noch Ghosting rein irgendwo und Encodiert noch mal und das Ergebnis wäre zum einen ein trauriges erst mal und zum anderen würde die Datei ja anwachsen, weil da soviele Rauschelemte drin wären im Bild dank Shadowplay was dann als Detail gilt und die Datei daher schon so groß wird beim zweiten Encode.

Wenn man kleine Dateien haben will, entweder A) lossy aufnehmen ohne Bearbeitung und direkt hochladen oder B) Lossless aufnehmen und danach in Ruhe encodieren für eine optimale Dateigröße zum Upload.

Weil Lossy -> Lossy ist meist ein Punkt wo die Datei größer wird.

Denn um von einer Lossy-Quelle keine Qualität zu verlieren ist meist nur ein Lossless Encode danach angebracht.
Schlimmer wird es wenn man Lossy zu noch mehr Lossy encodiert. Dann ist die Qualität nämlich im Arsch.
Und Lossy in ein weniger Lossiges Verhältnis zu encodieren bringt einen auch nicht grad viel, da die Lossy-Quelle meist als decodiertes RAW Material dem Encoder vorliegt, damit dieser das RAW (was in dem Falle schon verlustbehaftet ist) in ein neues Verlustbehaftetes Verhältnis zu bringen. Ergebnis ist das es kaum Auffällt, aber es dennoch Verluste gibt. Würde man das immer weiter machen würde bald nix mehr vom Video übrig bleiben. Generationsverlust halt.

Was ich dir auf jeden Fall sagen kann ist, dass Schritt 2 & 3 zusammen gehören. Wieso machst du nicht in Schritt 2 das gesamte Video samt Intro und Outtro fertig und encodierst nur ein Mal? Wenn du renderst wird dein Video komprimiert, das heißt im Detail, dass Informationen aus dem Rohmaterial die im fertigen Video nicht gebraucht werden verworfen bzw. sinnvoll zusammengefasst werden. Das resultiert in einer kleineren Dateigröße, aber auch in weniger Bildinformation.

Wenn du jetzt nochmal das bereits encodierte Video ein zweites Mal in Premiere encodierst, hat Premiere weniger Informationen auf die es zugreifen kann und das ganze resultiert dann in einer schlechteren Qualität, weil von den sowieso schon komprimierten Bildinformationen weiter Informationen verworfen werden.

Edit:
Wobei ich mich schon immer gefragt habe, warum es eigentlich keine Methode gibt bei der alles 1:1 so gelassen wird wie es ist, wenn man Videos nur zusammenschweißen will.

Zitat von HOOL

Also mein Workflow

Ich will ja niemanden vor den Kopf stoßen, aber so kann da nichts als Pampe bei rumkommen. Pampe die viel Speicherplatz wegnimmt.
Die Quali mit der du in OBS aufnimmst ist ziemlich mies und jeder Render-/Kodiervorgang kostet zusätzlich Qualität.

Wirf' einen Blick hierein: Open Broadcaster [Aufnahme] | Gaming Tutorial-Reihe
Ansonsten wären noch OBS Studio und MSI Afterburner empfehlenswert als kostenlose Aufnahmeprogramme. Kostenpflichtig gäbe es noch Dxtory.

Das nächste wäre die Verarbeitung. Wie bereits erwähnt wirfst du dein Video gleich zwei mal durch den Mixer und dann ist es auch noch ein minder qualitativer. Einmal reicht. Für bessere Verarbeitung mal hier reinschauen: x264vfw für Videoschnittprogramme
Idealer wäre es jedoch, wenn du Premiere komplett weg lassen würdest, falls du nur schneiden solltest.

Zitat von Chron

Wobei ich mich schon immer gefragt habe, warum es eigentlich keine Methode gibt bei der alles 1:1 so gelassen wird wie es ist, wenn man Videos nur zusammenschweißen will.

Ist möglich, dazu müssen aber alle Videos die zusammengefügt werden sollen exakt und ausnahmslos identisch kodiert worden sein.

Zitat von Kayten

Ist möglich, dazu müssen aber alle Videos die zusammengefügt werden sollen exakt und ausnahmslos identisch kodiert worden sein.

Ganz sicher, dass es möglich ist? Und: Warum müssten zwei sonst unidentische Videos auf einen Nenner gebracht werden?
Theoretisch könnte das Programm doch dann auch beide Videos unterscheiden und jedes so lassen wie es ist, bzw. wenn eines an ein anderes "ranencodiert" wird, das erste nicht neu berechnen sondern 1:1 wiederherstellen und das zweite nur neu encodieren.

Die Videos müssen identisch kodiert worden sein, damit zu sie zusammenfügen kannst, siehe MKVToolNix bzw. mkvmerge.
Es wurde nicht umsonst schon früher mal dazu geraten Intro und Outro einmalig zu kodieren und hinterher immer mit den identisch kodierten Videos zusammenzufügen. So spart man sich die immer gleiche wiederholende Kodierung von In-/Outro.

Zitat von Kayten

Die Videos müssen identisch kodiert worden sein, damit zu sie zusammenfügen kannst

Ja, das hast du bereits gesagt Ich wollte wissen warum sie identisch kodiert sein müssen, um die Technik dahinter zu verstehen.
Du meinst ja bestimmt nicht nur den gleichen Codec, sondern auch die identischen Einstellungen. Da kommt die Frage auf,
warum der Encoder nicht feststellen könnte, dass ab Frame X Video 2 beginnt, dessen Informationen ausliest und dann
1:1 wieder so herstellt.

Wenn das bei zwei identischen Videos geht, weil der Encoder mit den gleichen Einstellungen arbeiten kann,
scheitert es bei zwei unidentischen doch nur an einer Umstellung mittendrin?

Zitat von Chron

Ich wollte wissen warum sie identisch kodiert sein müssen, um die Technik dahinter zu verstehen.

@De-M-oN @Sagaras
Das könnt ihr deutlich besser erklären.

Weil im Header die Einstellungen stehen mit denen der Decoder arbeitet und dieses Einstellungen immer für die gesamte Datei gelten.

Zitat von GelberDrache92

Weil im Header die Einstellungen stehen mit denen der Decoder arbeitet und dieses Einstellungen immer für die gesamte Datei gelten.

Aber es wäre technisch machbar ein Programm zu schreiben, was in der Lage ist zwei verschiede Einstellungen für zwei verschiedene Videos in einem Encodingdurchlauf anzuwenden?

Nein da das eine Encoding ist und das andere was man mit mkvmerge und co macht muxen ist

Zitat von GelberDrache92

Nein da das eine Encoding ist und das andere was man mit mkvmerge und co macht muxen ist

Ich würde nur gern verstehen warum ein Encoder nicht während eines Encodingvorgangs in der Lage wäre, die Einstellungen nach denen er vorgeht zu verändern.

Weil bei einem Encoding die Sachen in einer Datei landen und diese müssen die gleichen Einstellungen haben.
Wenn ich zwei Videos mit verschiedenen Einstellungen haben möchte, dann müssen diese in zwei verschiedene Dateien.
Dementsprechend macht es keinen Sinn.