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

[Kostya]

On Sat, Nov 08, 2008 at 03:07:47PM +0100, Michael Niedermayer wrote:
> On Sat, Nov 08, 2008 at 07:57:43AM +0200, Kostya wrote:
> > 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:
[...]
> > > > 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.
> 
> ignoring the minor problem of a authorative source for a difinition of what
> a golomb code is. After all golomb wrote more papers AFAIK
> 
> The real issue is thats exp golomb codes do not neccesarily have to be
> golomb codes, but are a modifiation or extension that no longer is conforming
> to the original definition.
> I dont understand from where you come up with the claim that every code
> containingt the word golomb would neccessarily have to be a valid golomb
> code.
> In the same sense a windowed DCT is not a DCT
> 
> 
> > All integer VLC codes may be represented as mantis and exponent part.
> 
> iam pretty sure this is not true
 
In that context mantis = code bits, exponent = number of bits to code.
They may be interleaved (like in UTF-8) and recursively coded as well
(like in case of Elias Delta and Omega codes, Even-Rodeh codes, etc).

> > In Elias Gamma codes length of mantis part = length of exponent part,
> 
> well exp golomb codes (and svq3, h264, rv) have mantis len + 1 = exp len
> that clearly makes them different.

Look into Fenwick's report, section 1.1. I have described it a bit wrong
but you can look there and compare it for yourself.
http://www.cs.auckland.ac.nz/~peter-f/FTPfiles/TechRep137.ps
 
> > 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?
> 
> because "any 8x8 transform" is not neccessarily a DCT
> 
> exp golomb codes are described in
> J. Teuhola, "A Compression Method for Clustered Bit-Vectors",
>    Information Processing Letters, Vol. 7, pp. 308-311, Oct. 1978.
> 
> from what i could find out.

Do you have that paper?

Since I have long standing interest in general data compression
(well, since 1999 is quite long for me) and I've never seen "exponential-Golomb"
codes mentioned in any book or paper on data compression covering
more exotic codes, and the only mentions of exp-Golomb are related
to H.264 (and it's missing in older H.264 draft). All this makes
me feel this name was invented by them.
 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB