[FFmpeg-devel] [PATCH] Function to parse Dirac sequence header

[Kostya]

On Fri, Nov 07, 2008 at 11:35:59PM +0100, Michael Niedermayer wrote:
> On Thu, Nov 06, 2008 at 02:42:13PM +0200, Kostya wrote:
[...]
> 
> While i appreciate your effort to credit some of the authors in the
> function names.
> Why do you provide examples that as you say are not elias gamma codes anyway?
> And the examples you provide are not what svq3_* uses either ...

I just wanted to show how different bits are coded. Those should be
legal codes, not optimal though.
 
> > 
> > In original paper Golomb (which is funny to read), he describes
> > more sophisticated codes where prefix length may differ from
> > payload length (that's just a rule for recognizing them).
> > 
> 
> > Why those committees call every variable-length code for integers
> > Golomb codes is a great mystery.
> 
> probably because they have some common sense ...
> One should ALWAYS use descriptive names, NEVER names technically unrelated
> to the actual thing one names. Unless the names are universally used and
> understood. like fourier in FFT
> as examples heap and radix sort are descriptive names, for bad ones refer
> to wikipedia (string searching algos for example)
> 
> In that respect exp golomb codes are golomb codes with exponential behaviour
> Interleaved exp golomb codes are the same but with prefix and postfix bits
> interleaved.
> First is what h264 uses, later is what svq3 uses. both are elias gamma codes
> which is why using just the name elias gamma is ambigous here.

The problem is that Gamma or Gamma' codes are not Golomb code at all.
All integer VLC codes may be represented as mantis and exponent part.
In Elias Gamma codes length of mantis part = length of exponent part,
in Elias Delta codes exponent is coded with Elias Gamma itself, but
in Golomb codes mantis bits have fixed length - N or N-1.

So, while unary codes and Rice codes are a specific case of Golomb codes
(with code parameter 0 or 2^n correspondingly), Elias Gamma code cannot
be obtained from them.
Why not call _any_ 8x8 transform DCT then?
 
> Also in case of the question of why its in RV and SVQ3, they are both
> strongly based on h264 drafts, and previous drafts used interleaved
> exp golomb codes IIRC.

Hmm, in A003r1 draft it's simply UVLC. Looks like they had more sence then.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB