The purpose of H.265/HEVC byte stuffing process

[maxlovic]

Hello everyone!
Could someone please explain the purpose of byte stuffing process in H.265/HEVC. (sec. 7.4.3.10 and 9.3.5.7 of the specification). The number of bins in a coded picture shall be less than or equal to ((32/3)*number_of_bytes + (1/32) * rawBitSize).
http://i70.fastpic.ru/big/2015/0624/1b/f3f5288b3a94ec729b5cd88b9246671b.jpeg
To meet this condition a NAL unit can be padded with a number of cabac_zero_words.
What is the purpose of this procedure? It seems to never happen in a regular compression. Does it happen in lossless compression or scalable coding? Is it for the decoder to see if its CABAC throughput is enough to decode the picture or is it somehow used for error detection?

[Sulik]

It's primarily to limit the load on the CABAC decode engine, since you can't really decode more than 1 bin per cycle (ignoring bypass bins). The most likely way this would happen is for example all symbols always end up being the most probable symbol, in which case each bit would result in up to 64 bins (64:1 compression), making it difficult or impossible for a fixed-function engine to decode the stream in realtime (or resulting in an unpractical maxframebytes*8*64 minimum clock requirement for the CABAC engine). In practice the overall bits:bins ratio rarely exceeds 2:1, so it's never really a problem (I doubt any encoder implementation actually bother to enforce this restriction).

[maxlovic]

Sulik, thank you for your reply!
This rule seems a bit outdated as if some legacy concerns. Is there some existing hardware that can really experience such issues when there is no byte stuffing but needed to be? Is this due to a lack of prebuffering?

[Sulik]

The zero byte stuffing itself is no different than the zero byte stuffing used for CBR encoding - it's never actually required, and most encoders don't actually stuff these zero bytes in the elementary stream (it's better to let the downstream multiplexer handle this if transmitted over a CBR channel).
The only requirement for the stream to be compliant is that you take this 'virtual byte stuffing' in the hrd fullness computations (that's if things like pic_timing SEIs are present in the stream). If you don't do this, BD authoring software could detect the stream as non-compliant stream and reject or re-encode the stream (used to be more of an issue with MPEG-2+DVD, since who actually burns BD these days ? All the byte stuffing process is irrelevant/unnecessary for VBR containers like mp4).