[x264-devel] Re: CABAC performance

[List, Peter]

> >> Encoding CABAC takes the same amount of time as decoding CABAC. But
the
> >> encoder does lots of other computations, most of which are analysis

> >> only and not duplicated in the decoder. So CABAC is a large
fraction of 
> >> the decode time, and a small fraction of the encode time.
> >> Where did you hear "16% bitrate and 25-30% speed"?
> >
> > I take these data from the article "Video coding with h.264/AVC:
tools,
> > performance and complexity" written by Jorn Ostermann, Jan Bormans,
> > Peter List, Detlev MArpe, Matthias Narroschke, Fernando  Pereira,
Thomas
> > Stockhammer and Thomas Wedi
> > (http://iphome.hhi.de/marpe/download/h264_casm04.pdf) See on page
23.

Dear Son

These "up to 16% improvement" are one of the typical PR-statements
common in this business. Simply, don't believe them.
As far as I can remember, the statement was somehow true during the
development of H.264. Even at that state CABAC was mainly successful for
very high and very low rates, because the VLC codes were optimized for
medium rates. As a reaction on this gain achieved with CABC, Nokia and
Real came up with CAVLC algorithms; mainly because CABAC is very bad for
hardware implementations and too complex in any case. Also the IPR
situation for CABAC seemed unfortunate the time. 
If CABAC is compared with CAVLC the gains are MUCH less. As far as I
know only a few percent (something like 4%?). The gains achieved by
CABAC are mainly due to CA (Context Adaptivity) and only to a small
degree due to BAC (Binary Arithmetic Coding). With context adaptivity
VLC's are almost as good.
But CABAC had been proposed by one of the chairpersons of the JVT-group,
and it was "somehow difficult" to remove it from the standard again...
As time went by, people seemed to have forgotten that the huge gains
were measured against NON Adaptive VLC coding. 

I have attached a document with some temporal results comparing two
schemes of CAVLC (Nokia and Real) with a draft from CABAC. I believe
both CAVLC AND CABAC are more efficient in the final standard, but the
relation should still be comparable to the one in the document...

Regards
                  Peter List



-------------- next part --------------
A non-text attachment was scrubbed...
Name: JVT-C028.xls
Type: application/vnd.ms-excel
Size: 137728 bytes
Desc: JVT-C028.xls
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20070530/0c9e5408/attachment.xls