[x264-devel] Re: CABAC performance

Loren Merritt lorenm at u.washington.edu
Fri Jun 1 08:07:42 CEST 2007


On Thu, 31 May 2007, Mathieu Monnier wrote:

>> Speed difference is less than 5%. (high quality encoding with rdo enabled 
>> for both cavlc and cabac, but settings aren't insane)
>
> AFAIK, x264 computes RD costs with CABAC, so using RD bias x264 toward CABAC.
>
> Plain SAD / SATD decision ( ie, no trellis, subme 5, no brdo ) would be 
> fairer.

x264 computes RD costs with the selected entropy coder. What would be the 
point of RDO if rate was wrong? It wouldn't even help speed or simplicity, 
because CAVLC RD is faster than CABAC RD, and both are just macros 
surrounding the normal bitstream writing code.
I did however disable RDO in this test because it's just easier to compare 
entropy coders if they're coding the same data.

Since as Manao said it's a function of QP, I won't try to condense it to 
one number. So here's the graphs:

http://akuvian.org/src/x264/entropy_mpegcif.png
http://akuvian.org/src/x264/entropy_mpegcif_avg.png

The sequence with the huge peak of 17% at qp<=20 was "highway", probably 
because it's very noisy but the noise gets quantized away at higher qp.

While CAVLC is context-based, it's not really adaptive. So if you try to 
encode content other than what CAVLC was presumably tuned for, CABAC gets 
a bigger lead:

http://akuvian.org/src/x264/entropy_anime.png

Likewise, CAVLC is hardcoded for DCT probabilities. In lossless (where DCT 
is disabled), CABAC adjusts better.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html



More information about the x264-devel mailing list