# Issue

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?

# Solution

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.

Answered By - Mosen Answer Checked By - Dawn Plyler (PHPFixing Volunteer)

## 0 Comments:

## Post a Comment

Note: Only a member of this blog may post a comment.