[x264-devel] Re: CABAC performance

[Son Minh Tran]

Dear All,
Thank you very much for your reaction on the topic I launched up, 
especially for the documentation from Peter List.
I would like to go further a little bit on modifying the state of the 
CABAC encoder. So in the the code of  x264, I  change the static table 
x264_cabac_range_lps and x264_cabac_transition with the dynamic ones 
(calculated in correspondance with the state number and quantized Range 
given as options of x264). Then I made some proper changes concerning 
the new dynamic tables like
-in x264_cabac_context_init: I use the init state ~ 0,5 probablitity for 
all contexts
-in x264_cabac_encode_decision,  I deployed the new tables for 
transition and range calculation
My question is do I miss some steps in changing the state number and 
quantized Range for CABAC. That is because with greater number of state 
and finer quantization of Range (so the CABAC model is much closer to 
the theory arithmetic coder) I don,t have a solid increase in 
compression efficiency
Thank you for your hints
Best Regards
Son

List, Peter a écrit :
>   
>>>> 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
>
>
>   

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