Ein Video unter das Upload-Limit bringen, ohne zu raten

Größe ist Bitrate mal Dauer, und fast nichts sonst

Eine Videodatei ist ein Bitstrom, der mit einer bestimmten Rate abgespielt wird. Multipliziere diese Rate mit der Spieldauer, und du hast die Datei — abzüglich der Buchführung des Containers selbst, die bei einem normalen MP4 im Bereich von Bruchteilen eines Prozents liegt. Deshalb ist die Dateigröße keine Eigenschaft, die man einstellt. Sie ist ein Ergebnis. Wirklich steuerbar sind nur zwei Dinge: wie viele Bits pro Sekunde vorbeiziehen und wie viele Sekunden es sind — und alles, was ein Kompressor tut, ist eine Art, am ersten zu drehen.

Die Umrechnung lohnt das Auswendiglernen, denn sie ist die ganze Methode. Ein Megabyte sind acht Millionen Bit, also 8 000 Kilobit. Multipliziere das Limit in Megabyte mit 8 000, teile durch die Anzahl Sekunden, und heraus kommt die Gesamtbitrate in Kilobit pro Sekunde, die hineinpasst. Ein 25-MB-Limit erlaubt bei einem 60-Sekunden-Clip 3 333 kbit/s. Dasselbe Limit erlaubt bei zehn Minuten 333 kbit/s. Gleiches Limit, zwanzigmal weniger Platz, und der Unterschied ist restlos die Dauer.

Eine Falle in dieser Rechnung ist das Megabyte selbst. Manche Systeme meinen damit 1 000 000 Byte, andere 1 048 576 — ein Unterschied von 4,9 %, und ein Dienst sagt selten, welches er meint. Mit dem dezimalen Wert zu rechnen — 8 000 Kilobit je Megabyte — ist die richtige Richtung, sich zu irren: meinte der Dienst tatsächlich das größere Megabyte, bleibt deine Datei einfach mit Reserve unter dem Limit.

CRF verlangt eine Qualität, keine Größe

Der Qualitätsregler dieses Werkzeugs stellt einen konstanten Qualitätsfaktor ein. Im Kodierer reicht die Skala von 0 bis 51; der Regler zeigt 18 bis 34, also den Teil, den vernünftige Leute benutzen, und startet bei 28. Eine kleinere Zahl bedeutet bessere Qualität und mehr Bits. FFmpegs Leitfaden nennt 17 oder 18 optisch verlustfrei oder beinahe, und beschreibt 17 bis 28 als den subjektiv vernünftigen Bereich. Entscheidend ist, was die Zahl bedeutet: sie ist eine Anweisung, wie viel Verfälschung pro Bild geduldet wird, nicht wie viele Bits entstehen sollen.

Deshalb liefert derselbe CRF bei verschiedenen Clips völlig verschiedene Größen. Zwei Minuten eines statischen Interviews bei CRF 23 landen vielleicht bei ein paar Megabyte; zwei Minuten Regen auf Wasser, Konfetti oder ein wackliger Gang durch einen Markt bei demselben CRF können das Zehnfache wiegen, weil dieselbe Bildqualität über all diese Bewegung hinweg schlicht mehr Bits kostet. Der Kodierer tut, worum du gebeten hast. Du hast ein Aussehen bestellt, kein Gewicht. FFmpegs Dokumentation sagt es unmissverständlich: in diesem Modus lässt sich weder eine bestimmte Dateigröße noch eine Bitratenobergrenze vorgeben.

Es gibt eine Regelmäßigkeit, auf die du dich stützen kannst, und sie ist der Grund, warum zwei Versuche so schnell konvergieren. Die CRF-Skala ist exponentiell: sechs Punkte hinauf halbiert die Bitrate ungefähr, sechs Punkte hinunter verdoppelt sie ungefähr. Diese eine Regel macht aus einem blinden Regler ein Zielgerät. Über den Bereich, den dieses Werkzeug zeigt — 18 bis 34 —, ergibt das einen Faktor von rund 6,3 zwischen der größten und der kleinsten Datei, die derselbe Clip liefern kann.

Vom Limit rückwärts rechnen, mit einem echten Beispiel

Nimm einen dreiminütigen Clip, den du per E-Mail schicken willst. Gmail nennt für private Konten ein Anhangslimit von 25 MB, also: 25 × 8 000 = 200 000 Kilobit, geteilt durch 180 Sekunden, macht 1 111 kbit/s insgesamt. Zieh die 128 kbit/s ab, die dieses Werkzeug dem Ton gibt, und 983 kbit/s bleiben fürs Bild. YouTubes veröffentlichte Empfehlung für 1080p bei normaler Bildrate lautet 8 000 kbit/s. Du sollst es mit einem Achtel schaffen. Der Clip wird kodieren, und er wird aussehen wie durch ein verregnetes Fenster gefilmt.

Also ändere die Frage. Bei 720p empfiehlt YouTube 5 000 kbit/s, du hast 983 — immer noch ein Fünftel. Bei 480p sind es 2 500, du hast 983, also 39 %: ruppig, sichtbar weicher, aber ansehbar für einen sprechenden Kopf oder eine Bildschirmaufnahme. Dieser Vergleich ist die eigentliche Entscheidung, und eine Division hat gereicht. Muss der Clip 1080p bleiben, ist der einzige verbleibende Hebel die Dauer: kürze ihn auf 45 Sekunden, und dieselben 25 MB ergeben 4 444 kbit/s insgesamt und 4 316 fürs Bild — nahe an der 720p-Empfehlung und etwas über der Hälfte der 1080p-Empfehlung, also dort, wo ein höherer CRF aufhört, Grausamkeit zu sein.

Wenn die Rechnung nein sagt

Rechne die Division für eine dreißigminütige Aufnahme gegen ein 25-MB-Limit, und du bekommst 111 kbit/s insgesamt — weniger, als der Ton allein braucht. Das Bildbudget ist negativ. Keine Kompressionseinstellung löst das, und keine Geduld hilft, denn die Forderung ist arithmetisch unmöglich, bevor der Kodierer überhaupt beteiligt ist. Das ist das nützlichste Ergebnis der Methode, und man sollte dort ankommen, bevor man zwanzig Minuten mit Kodieren verbringt.

Die ehrlichen Antworten drehen sich an diesem Punkt um die Dauer oder um das Ziel. Kürze die Aufnahme auf den Teil, der zählt — das Schnittwerkzeug erledigt das in Sekunden, ohne irgendetwas neu zu kodieren, um den Preis, auf einem Keyframe zu landen statt exakt dort, wo du wolltest. Teile sie in Stücke. Oder wechsle den Kanal: WhatsApps eigene Hilfeseiten nennen ein Standard-Videolimit von 100 MB und 720p bei schneller Verbindung und 64 MB und 480p bei langsamer, während Dokumente über dieselbe App bis 2 GB gehen — ein Video als Dokument zu senden umgeht also Größenlimit und app-eigene Neukomprimierung zugleich.

Die Option, die den Index nach vorn holt

Jedes MP4, das dieses Werkzeug erzeugt, wird mit +faststart geschrieben, und das verdient einen Absatz, denn es ist der Unterschied zwischen einer Datei, die abspielt, und einer, die kaputt wirkt. Ein MP4 legt seine Mediendaten in einer Box ab und seinen Index — die Tabelle, die sagt, wo jedes Bild liegt, das moov-Atom — in einer anderen. Standardmäßig schreibt der Kodierer den Index zuletzt, weil er die endgültige Anordnung erst nach dem letzten Bild kennt. Ein Player, der eine solche Datei von einem Webserver liest, muss das Ende des Downloads erreichen, bevor er starten kann.

Die Option faststart lässt den Kodierer einen zweiten Durchgang über die fertige Datei machen und diesen Index nach vorn schieben. FFmpegs eigene Dokumentation beschreibt es genau so und merkt an, dass es nicht standardmäßig aktiv ist, weil der zusätzliche Durchgang Zeit kostet. YouTube verlangt in seinen Upload-Empfehlungen dasselbe: das moov-Atom am Dateianfang, dort Fast Start genannt. Praktisch heißt das, dein Video beginnt zu laufen, während es noch ankommt, statt bis zum letzten Byte ein schwarzes Rechteck zu zeigen — genau das tun eine Upload-Vorschau, ein Messenger oder eine Webseite mit einer Datei ohne diese Option.

Was das Werkzeug tatsächlich ausführt, und wo

In der Kette steckt kein Geheimnis, hier ist sie also vollständig. Der Kompressor kodiert das Bild mit libx264 im Preset veryfast und dem von dir gewählten CRF, den Ton mit AAC bei 128 kbit/s, und schreibt das Ergebnis als MP4 mit der Option faststart. Das ist der ganze Befehl. Das Preset ist ein Regler für Geschwindigkeit gegen Effizienz, nicht für Qualität: ein langsameres Preset ergäbe bei gleichem CRF eine etwas kleinere Datei, und veryfast ist der Kompromiss, der eine Kodierung im Browser nicht den ganzen Nachmittag dauern lässt.

Dieser Kodierer ist FFmpeg, nach WebAssembly übersetzt, und er läuft in der Seite, auf deinem Rechner. Die Engine wiegt rund 32 MB und wird von der Adresse dieser Seite ausgeliefert, nicht von einem fremden Netz — das Einzige, was reist, ist die Engine auf dem Weg zu dir; das Video geht nirgendwohin. Der Build ist einfädig, deshalb ist er langsamer als ein Desktop-Kodierer, der die Arbeit über all deine Kerne verteilt, und deshalb ist ein langer Clip wirklich eine lange Wartezeit. Halte den Tab im Vordergrund, während er arbeitet: der Auftrag lebt in der Seite, und kein Server hält dir den Platz frei.

Häufige Fragen

Warum kann ich nicht einfach die gewünschte Dateigröße eintippen?

Weil eine exakte Größe verlangt, dass der Kodierer den ganzen Clip sieht, bevor er entscheidet, wie er seine Bits ausgibt — er muss ihn also zweimal kodieren. Genau das tut der Zwei-Pass-Modus: der erste Durchgang misst, wo die schwierigen Stellen liegen, der zweite verteilt das Budget entsprechend. Das ist die richtige Antwort, wenn eine Größe harte Vorgabe ist, und es kostet rund doppelt so viel Zeit. Dieses Werkzeug macht einen Durchgang bei konstanter Qualität, was für einen Kodierer im Browser der richtige Handel ist, wo der zweite Durchgang eine ohnehin lange Wartezeit verdoppeln würde. Die Rechnung in diesem Artikel bringt den Ein-Pass-CRF dorthin, wo Zwei-Pass landen würde.

Meine komprimierte Datei ist größer als das Original. Wie das?

Weil der von dir verlangte CRF großzügiger war als die Qualität, die die Datei bereits hatte. Kompression ist keine Ratsche — der Kodierer weiß nicht und kümmert sich nicht darum, was die Eingabe wog, er erzeugt einfach, was eine bestimmte Qualitätsstufe kostet. Ein bereits stark gequetschter Clip, ein Download aus einem Messenger oder eine Bildschirmaufnahme mit überwiegend statischem Inhalt kann bei CRF 23 mehr Bits verlangen, als er derzeit belegt. Erhöhe den CRF. Die andere häufige Ursache ist eine Tonspur, die ursprünglich unter 128 kbit/s lag, denn dieses Werkzeug kodiert sie immer mit dieser Rate neu.

Auflösung senken oder CRF erhöhen?

Vergleiche dein Budget mit dem, was die Auflösung verlangt, und lass die Lücke entscheiden. Liegt das Budget im Faktor zwei zur Empfehlung, erhöhe den CRF — das Bild wird weicher, behält aber saubere Kanten. Ist es ein Fünftel oder weniger, senke stattdessen die Auflösung: ein so ausgehungerter Kodierer erzeugt Blöcke und Schlieren, die weit hässlicher sind als dasselbe Material ehrlich in kleinerer Größe. Als Faustregel wirkt ein Bild mit zu wenig Pixeln klein, ein Bild mit zu wenig Bits kaputt — und das Erste verzeiht das Publikum viel eher.

Spielt die Toneinstellung überhaupt eine Rolle?

Sie zählt genau dann, wenn der Clip lang und das Limit klein ist. Bei 128 kbit/s kostet der Ton rund 0,96 MB pro Minute: ein Zweiminüter gibt unter 2 MB für Ton aus und es kümmert niemanden, eine Zwanzigminutenaufnahme dagegen über 19 MB allein für Ton — weshalb die Dreißig-Minuten-Zeile der Tabelle bei 25 MB unmöglich ist. Dieses Werkzeug zeigt keine Tonregelung, also lautet die Antwort, wenn der Ton das Problem ist: die Aufnahme kürzen, oder einsehen, dass ein langer Redebeitrag ein ganz anderes Format verlangt, und die Tonspur allein herauslösen.

Der Upload scheiterte, obwohl meine Datei unter dem genannten Limit liegt.

Drei Dinge tun das regelmäßig. Das genannte Limit kann für die ganze Nachricht statt für jeden Anhang gelten, dann zählen deine anderen Dateien mit. Der Dienst misst womöglich den kodierten Upload statt die Datei auf der Platte, was bei einem E-Mail-Anhang rund ein Drittel draufschlägt. Und veröffentlichte Zahlen veralten: Discords eigene Hilfeseite zu Dateianhängen, gelesen am 13. August 2026, nennt als kostenlose Grenze inzwischen 20 MB, angehoben von 10 MB im August 2026, mit 50 MB bei Nitro Basic und bis zu 500 MB bei Nitro — während ein älterer Absatz derselben Seite weiterhin 10 MB nennt. Wenn eine Seite sich selbst widerspricht, ziele unter die kleinere Zahl.