cabac decoding possibilities for slice level parallelism?

[codimahi]

Does anybody have an idea about possibility cabac-decoding on two slices concurrently?


Macro-block level parallelism is not possible in cabac. But as the cabac decoding engine initializes the probabilities for every slice, I think slice level parallism is possible.

I mean here slice level parallelism means the slices can belong to any picture.

Normally slice level parallelism is possible, if slices belong to the same picture.

I have been through cabac decoding. I am not able to find any previous slice dependencies in cabac decoding.


I am not sure about this conclusion.

[kwtc]

Cabac is indeed slice independent. In fact all slice decoding is independent except for the deblocking which may or may not be independent.

[codimahi]

Cabac is indeed slice independent. In fact all slice decoding is independent except for the deblocking which may or may not be independent.


I can not accept all slice decoding is independent except deblocking. one can not decode B picture slices before decoding I picture slice ("I picture" means the reference picture).

But I accept all silices within the picture can be decoded independently.


I think I want to be little bit explicit in my question.


Can I cabac-decode slice which belongs to B, before cabac-decoding slice which belongs to I.

[akupenguin]

Can I cabac-decode slice which belongs to B, before cabac-decoding slice which belongs to I.
Yes, but why would you want to? It takes more memory to store the intermediate data between cabac and reconstruction than it does to store a whole decompressed frame. You will run into huge speed penalties for reading all the data back from main memory instead of cache.

[codimahi]

Yes, but why would you want to? It takes more memory to store the intermediate data between cabac and reconstruction than it does to store a whole decompressed frame. You will run into huge speed penalties for reading all the data back from main memory instead of cache.

I accept that one has to store the intermediate values in the buffer.

But if we have let’s say 4 core SMP, then for CABAC decoding we can dedicate two cores.

I do not how much penalty we have to pay, when we use extra memory. But I think it will be better than “single-core” cabac decoding (as cabac decoding is more complex).

I think if one comes up with multi core processors, h.264 decoding will be possible for even H.D. resolution. ( with out any need for special hardware acceleration for cabac)

[akupenguin]

So run 2 threads in parallel, one decoding cabac and one for reconstruction, of the same slice offset by a few macroblocks. Then you don't have to buffer so much intermediate data. I haven't tested it, but I'd bet the thread synchronization is cheaper than the cache misses.

[sysKin]

Or you could try cabac -> cavlc recompression in one thread, and cavlc decoding in another. MUCH more work but *possibly* better than wasting one core completely.

[codimahi]

So run 2 threads in parallel, one decoding cabac and one for reconstruction, of the same slice offset by a few macroblocks. Then you don't have to buffer so much intermediate data. I haven't tested it, but I'd bet the thread synchronization is cheaper than the cache misses.

Do you mean that, even if there are 4 cores, using one core for cabac and other cores for rest of the decoding will be faster than using 2 core for cabac (I mean two ||el slice decoding), and others for rest of the decoding will be efficient.

I am just asking in theoretical point of view.

May be one possibility is cabac decoding in one thread and “header decoding and formatting the intermediate values in other thread” and “rest of the decoding” in other threads.

But even then the core where “header decoding and formatting the intermediate values” is done will not be used completely (May be 10% ). To utilize this core completely we may start other slice decoding parallel.

Thanks for ur insight in this problem.

[akupenguin]

Do you mean that, even if there are 4 cores, using one core for cabac and other cores for rest of the decoding will be faster than using 2 core for cabac (I mean two ||el slice decoding), and others for rest of the decoding will be efficient.
The only division possible within the "reconstruction" part is to split deblocking from the rest. So you can't use 4 cores on one slice, no matter what inefficiencies you accept.
Of course decoding independent slices (whether multi-sliced frames or non-referenced B-slices) is more efficient than trying to put the same number of cores on one slice and having to synchronize. But you don't need to read ahead in cabac to do that. Put 2 cores on each slice, still doing cabac+reconstruction offset by a few mbs.
If you don't have independent slices, then reading ahead in cabac doesn't help unless cabac is slower than the rest of the decoding process combined. Which it might be for sufficiently high bitrates at sufficiently low resolution, but not in the files I normally work with.
Which leads to the next point: the optimal distribution of tasks among cores and the optimal synchronization strategy depend on the relative speed of the pieces of the decoding process (which depends on bitrate, resolution, and to a lesser extent other settings), as well as the structure of the bitstream (multisliced or not, P vs B vs B-pyramid).

May be one possibility is cabac decoding in one thread and “header decoding and formatting the intermediate values in other thread” and “rest of the decoding” in other threads. Cabac decoding requires headers and formatting the intermediate values. That's what the "Context-Adaptive" part of cabac means.