I'm parsing HEVC [H.265] header and I noticed that many values are in Golomb code notation. One of them, for example, is the width. Let's suppose a width value of 1600, in Golomb code is written as:
g=000000000001001000001
call "leadingZero" (lz) the first part of the string (from left to right). LeadingZero is composed by 11 zeros. Let's call b the rest of the string of Golomb code.
to decode the Golomb code, where b=1001000001 (or decimal 577), you do:
a=2^(lz-1)-1;
n=a+to_decimal(b)
where to_decimal converts from binary to decimal value.
So you have 1023 + 577 = 1600.
Question:
With Golomb you're using 21 bits to represent 1600.
But 1600 in binary takes 11 bits (110 0100 0000).
Also the Golomb method does not allow for a custom number of bits to represent values.
So... Why Golomb code is used in compression algorithms like H.265?
Well, usually compression of High Level Syntax (HLS) is not a critical priority in video compression. If you do the math for a typical resolution (e.g. 1080p) in a typical bandwidth (e.g. 7 Mbps), you will see that saving a few bits to signal frame-level and sequence-level information is really negligible.
However, since ex Colomb code is also used in signalling large DCT coefficients, one might ask the same question in that context. And it would be a valid compression concern, as efficiency residual coding is everything! To answer that question, there are a lot of well stablished literature, dating back to AVC time.