[x264-devel] VBV Rate Control Challenge

[Jason Garrett-Glaser]

On Tue, Dec 29, 2009 at 5:07 PM, Mike Kazmier <DaKaZ at zenbe.com> wrote:
> All,
>
> I have an interesting test clip which consistently breaks VBV rate control.  In particular, the breakage is worse when using --rc-lookahead.  I find this interesting because I thought lookahead would help with this situation.  The scene is not necessarily one you would find in the wild (in other words, we were setup for failure) but none the less, I would expect x264 to handle it somewhat gracefully.  I am not sure of a strategy to do so beyond improving the heuristics of the lookahead to identify the amazing complex scene (static) that is coming and empty the VBV to the most extent possible while also cranking the QP all the way up.  Any thoughts are appreciated.  You can recreate the vbv underflow with this command:
>
> ffmpeg -i ./doremi-2.ts -f rawvideo -s 1920x1080 -| x264 -o ./doremi-2.h264 --threads 9 --trellis 1 --nr 1000 --bitrate 6500 --vbv-maxrate 6500 --vbv-bufsize 6000 --fps 30000/1001 --keyint 60 --min-keyint 15 --rc-lookahead 0 --interlaced --bframes 3 --b-adapt 1  - 1920x1080
>
> The sample clip is available here:
> http://www.mediafire.com/?hljzzzdm2ny
>
> Thanks,
>
> --DaKaZ

This clip is impossible.

Nothing to do with emptying VBV or lookahead or threads: it is simply
impossible to fit frames 259 and 260, via _any method_, even at QP51,
into the VBV buffer you have specified.  The only way to fix this
would be a VBV emergency mode of some sort, in which we force
skips/empty intra blocks or otherwise reduce coefficients even further
beyond max quantizer.

If you throw a stream analyzer at the TS, you'll notice it caused
serious VBV problems for the original MPEG-2 encoder as well: the only
reason it survived was because its buffer was much larger.

Jason