Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th June 2015, 07:41   #1  |  Link
maxlovic
Registered User
 
Join Date: Jan 2012
Posts: 4
The purpose of H.265/HEVC byte stuffing process

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).

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?
maxlovic is offline   Reply With Quote
Old 24th June 2015, 08:09   #2  |  Link
Sulik
Registered User
 
Join Date: Jan 2002
Location: San Jose, CA
Posts: 215
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).
Sulik is offline   Reply With Quote
Old 25th June 2015, 06:18   #3  |  Link
maxlovic
Registered User
 
Join Date: Jan 2012
Posts: 4
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?
maxlovic is offline   Reply With Quote
Old 25th June 2015, 10:03   #4  |  Link
Sulik
Registered User
 
Join Date: Jan 2002
Location: San Jose, CA
Posts: 215
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).
Sulik is offline   Reply With Quote
Reply

Tags
byte stuffing, cabac_zero_word, h.256, hevc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 11:09.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.