[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