HEVC CABAC Dependency

[rudyb]

Hi

Can someone please validate if my understanding of the following statement is correct?

Based on reading about CABAC and its close dependency from one bin to another bin, and based on analyzing how CABAC is done in HM model, it seems that within one CTU, I can only process one bin per clock cycle. And everything is indeed serial inside one CTU, and parallelizing is not really trivial inside one CTU. For example, if I am parsing a TU block of 32x32, this will literally takes 32x32=1024 clock cycle to process the bins. And even so, I can not start processing the second TU block of 32x32 within the same CTU, unless I am done with parsing the first TU block completely.

In other words, parallelization within one CTU cannot happen. And, the only way I can use some parallelism is by using Tiles or WPP. And for the case of WPP, this implies that I should finish processing two CTUs of the first row, until I can start processing the first CTU of the second row.

So, parallelism cannot happen inside one CTU (or at least that is how HM achieves this by serial processing of bins inside each TU). And even when I use WPP or Tiles, still TU parsing is a serial process inside each CTU.

Please verify if my above understanding is correct?

Thanks,
--Rudy

[LoRd_MuldeR]

To my understanding, CABAC is inherently serial, because the de/encoding of each "bin" will update the context model and thus effect the de/encoding of subsequent "bins".

Furthermore I think that WPP was especially invented to overcome this limitation: Since each block will be coded based on the context from its top-right block (rather than the context from its direct predecessor block), multiple lines of blocks can be processed in parallel. All that you need to be able to en/decode the next block in line N is that line N-1 is two blocks "ahead" of line N. But within each block, CABAC is probably as serial as it used to be without WPP.

Anyway, some attempt to parallelize the CABAC decoding process can be found here:
http://www.rle.mit.edu/eems/wp-conte..._jssc_2012.pdf

[rudyb]

Thank. That is how I was thinking about it too.
--Rudy