I just put together a patch (it's more of an ugly hack but whatever) that makes --b-adapt 2 somewhat faster.
Basically what it does is to adapt the number of b-frames to look for based upon the length of the previous consecutive b-frames span. It is way easier just to read the patch to find out how it works; this is the relevant part:
Code:
+ /* adaptive max b-frames */
+ if( h->sh.i_type == SLICE_TYPE_P )
+ {
+ int i_gop_bframes = h->fdec->i_frame - h->fref0[0]->i_frame - 1;
+ const int i_bframes_overhead = 4;
+ if ( i_gop_bframes + i_bframes_overhead > h->frames.i_adapt_bframes )
+ h->frames.i_adapt_bframes = i_gop_bframes + i_bframes_overhead;
+ else
+ h->frames.i_adapt_bframes--;
+ h->frames.i_adapt_bframes = x264_clip3( h->frames.i_adapt_bframes, 0, h->param.i_bframe );
+ }
i_gop_bframes is the length of the previous span of consecutive b-frames and i_bframes_overhead is an arbitrary constant (possibly to be parametrized).
h->frames.i_adapt_bframes is initialized (and reset at every scencut) to h->param.i_bframe (i.e. the number of b-frames specified on the command line)
The same adaptive method can be easily added also to --b-adapt 0 and 1, but I guess that it wouldn't give the same speedup.
Right now I'm running a few tests and I will post further results briefly, but the first tests showed a speedup ranging from 5 to 30% (being heavily dependent of the content of the video) for -b 16 (I know that this is the best-case scenario as well as I know the tendancy of doom9ers to max out their settings
).
Just a few more warnings: I tested it only on a Ubuntu32 VM and I have not paid much attention to concurrency issues (there should be none, and I experienced no crashes or other misbehaviour - but I'll wait for a review from the x264 devs about this). I tried to be as clear as possible in the patch, but I guess that at least a few variable names and comments will have to be edited... I couldn't come out with better ones, though.
That's all. Feel free to comment and give (possibly) constructive advice.