[x264-devel] VBV Rate Control Challenge

Jason Garrett-Glaser darkshikari at gmail.com
Tue Dec 29 23:51:10 CET 2009


On Tue, Dec 29, 2009 at 5:33 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> 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
>

Slight correction: those two frames _can_ fit in the VBV, just barely:
it's just that the entire sequence that follows, when combined with
those two, even maxed out at QP51, still can't fit.

In other words, this clip need VBV emergency mode, no chance otherwise.

Jason


More information about the x264-devel mailing list