[x264-devel] Re: CABAC performance

[Sergey A. Sablin]

Hi Peter,

I just run quick test with well-known CIF sequences: akiyo, coastguard, 
foreman, mobile and tempete and made two pass encoding with:
CAVLC 500 kbps
CABAC 440 kbps

Quick PSNR results - highest differences are:
+0.21 dB (CABAC winner, akiyo)
-0.15 dB (CABAC loss, tempete)
Speed difference is less than 5%. (high quality encoding with rdo 
enabled for both cavlc and cabac, but settings aren't insane)

So with all respect I wouldn't say +16% is a PR. And I think anyone 
could make a bunch of such tests with x264 (without RDO and trellis of 
course)

Regards,
Sergey.



List, Peter wrote:
>   
>>>> 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