Today I finally managed to do some proper testing using the Big Buck Bunny PNG image sequence from xiph.org, and found out that for reasonable settings (b-frames 8, b-heuristic 4) we have an overall 4% speed gain and for more extreme settings (b-frames 16, b-heuristic 4) we gain 17% overall.

The base command line used in this test is –b-adapt 2 –b-pyramid -r 4 –crf 26 -A all –direct auto -w -m 9 –psy-rd –mixed-refs -8 -t 2 –threads 3 –thread-input.

In the following pretty graph™ I plotted the frames-per-second for various settings (b-frames/b-heuristic):

The following are the raw results taken from the x264 logs:

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:

+    /* 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.