Erkennen kann man es nicht im Vorfeld. Abschätzen aber schon.
Faktoren für Kompressionen sind immer die gleichen:
- Gibt es große einheitliche Flächenfarben? Größere Flächen einer Farbe lassen sch extrem gut komprimieren.
Detaillierte Texturen sind alles andere als einheitliche Flächenfarben und somit wird sowas auch größere Dateien erzeugen.
Dazu zählt z.B. Bump Mapping, etc. pp. - Mit wie viel Farben wird gehandhabt? 12Bit, 16Bit oder volle 24Bit - Also Aufnahme und Verarbeitung des Videos. Und mit wie viel Farben läuft das Spiel?
Dos Spiele und vereinzelte Win95 Spiele meist mit 256 Farben
Dann gibt es noch Spiele mit 16Bit Farben (Star Wars Racer z.B.)
Und die üblichen regulären 32Bit Farben die jeder kennt.Classic GameBoy Spiele haben sogar nur 4 Farben
- Wie stark sind Bewegungen ausgeprägt im Spiel. Sprich wenn sich jeder Grashalm bewegt und jedes Blatt eines Baumes, Schatten etc. so haben Bewegugsvektoren enorm viel zu tun und brauchen dann halt auch für jeden Frame neue Informationen die man dann nicht weiter großartig komprimieren kann
Ein Minecraft Spieler der nur Rumhopsen tut und sich wie ein Irrer nur hektische Rundumbewegungen macht, braucht sich daher über die Dateigröße nicht Beschweren
Die Liste kann man gewiss noch weiter führen. Das hat aber alles Einfluss auf die Bitrate die verwendet wird beim CRF oder generell Quantizer und Qualitäts Verfahren.
Daher kann man die Dateigröße vorher nicht ermitteln, solange man weder Dateigröße oder eine Bitrate angibt.
Wenn man eine feste Dateigröße angibt oder eine Bitrate, so kann man das jeweils andere berechnen lassen.
Es gibt aber eine Fausregel, die einem aber denk ich auch nicht viel weiter bringt:
Breite * Höhe * bpp * FPS * Zeit in sek = Gesamtdateigröße ohne Kompression
Wenn man die bpp (bit pro pixel) nimmt und die Gleichung nach diesem umstellt, so könnte man die Qualität aus der Gesamtdateigröße ermitteln.
Die höhste Qualität bei einem YV12 Video wäre somit 12bpp. Und die könnteste anhand der Dateigröße oder halt der Bitrate beeinflussen. Die wird immer unter dem hösten Wert sein, also in diesem Fall hier unter 12bpp.
Und die Restlichen Kompressionsmechanismen sind ohnehin nicht vorhersehbar.
Sprich kannst du mir sagen wie viel ich aus einer Textdatei mit 1024 Bytes komprimieren kann?
Sind es gleiche Zeichen, so kann man das radial auf 3 oder 4 Byte reduzieren.
Sind es alle verschiedene Zeichen , so ist eine Kompression Sinnlos. Würde eher noch mehr werden von der Dateigröße. (Merkt man wenn man z.B. wenn man ein h264 Video mit WinRar oder 7Zip komprimieren will ;D)
Ein gesunder Ausgleich an Text kann eine gute Kompression darstellen. Dann macht man halt eine 32% Kompression z.B. Je nach Textinhalt.
Genau das gleiche gilt für Videos.
Ohne irgendeinen Anhaltspunkt wie halt bei CRF bei x264, kann man es halt nur abschätzen.
PS:
Ich sag es mal so, viele machen sich viel zu viele Gedanken darüber und wollen alles im Vorfeld eingrenzen können.
Wenn man es eingrenzen will, nimmt man eine Bitrate oder Dateigrößenangabe und encodiert via 2pass in VBR.
Und wer auf Qualiät halt wert legt, der nimmt halt einen Qualitätsfaktor oder Quantizer und encodiert ohne einen festen Zielpunkt.
Die beiden Varianten stehen dir ja zur Verfügung. Qualität bei Bitraten oder Dateigrößenangaben gut zu treffen, muss man schon ein Genie sein. Also ich könnte es nicht ![]()
2pass Verfahren wo ich Bitrate oder Dateigrößen brauche nutze ich wenn ich DVDs oder BluRays erstelle oder SVCDs. Oder wenn ich spezifische Videos mache die für bestimmte Geräte laufen sollen. z.B. an der PSP oder PS3/4 oder dem Nintendo DS, oder Handys. oder oder oder.
Für Youtube als auch für Filmrips verwende ich eigentlich nur noch CRF.
Filme wie Herr der Ringe in 1080p24 sind Aufgrund des Bildablaufes und der Szenen und auch das es natürliches Motion Blur enthält durch eine normale Kamera extrem gut komprimierbar. Herr der Ringe hat ja glaub ich so ca. 3h Videoinhalt. Und die Dateigröße liegt nach dem Rip zwischen 5 und 9GB. Während es auf der Bluray (2 Blurays = 1 Film bei der Extended Edition) über 80GB bald hat.