Hi, Does anybody know how codebooks are generated in OggVorbis encoder? We are porting oggorbis encoder on embedded platform for which VQ codebook memory is hugeeee to imagine. How can we reduce that? Can we do VQ with less codebooks and if yes how? If any help available? Parul Embedded Engineer Einfochips Ltd
On Mon, Feb 20, 2006 at 07:42:53PM +0530, parul wrote:> Hi, > > Does anybody know how codebooks are generated in OggVorbis encoder?In our reference encoder, they are 'canned'; they are pregenerated by us for a given release. For any given mode setup, the codebooks used in a release are fixed. Monty
Hi! h?tf? 20 febru?r 2006 15.12-kor parul ezeket a bolcs gondolatokat fogalmazta meg:> Does anybody know how codebooks are generated in OggVorbis encoder? WeI don't know, but I suppose the codeword lengths are generated from some samples that model the distribution of real world music - I would like to find this out myself also.> are porting oggorbis encoder on embedded platform for which VQ codebook > memory is hugeeee to imagine. How can we reduce that? Can we do VQ with > less codebooks and if yes how? If any help available?The codebooks aren't very complicated. Vectors of different residue classes represent residue in the range -2^n <= x <= 2^n where x is integer and n = 0,1,3,4,5,6,12 (there maybe more at high quality). In stereo streams there are residue classes for mono residue data (ie. two channels are the same), stereo residue data (channels can be anything in the given range independently, these appear only in the +-2^0 and +-2^1 range ), and "limited difference" stereo where the channel (left or right) with the larger absolute value is in the range given above, but the difference between the two channels is limited by (total range/2). Mono streams are supposedly simpler. For better efficiency each vector has a codeword lengths corresponding to it's probability (so it's probably random), and this is what needs to be stored in memory, but for more memory friendly and less efficient (and slower) compression these could also be calculated from the values in the vector somehow. I am not sure what you were asking, but what I have written is only what is obvious after looking at the codebooks of a vorbis file ;).> Parul > Embedded Engineer > Einfochips Ltdbye Denes -- --- What kills me, doesn't make me stronger.
parul wrote:> Monty wrote: > >> >> On Mon, Feb 20, 2006 at 07:42:53PM +0530, parul wrote: >> >> >>> Hi, >>> >>> Does anybody know how codebooks are generated in OggVorbis encoder? >>> >> >> >> In our reference encoder, they are 'canned'; they are pregenerated by >> us for a given release. For any given mode setup, the codebooks used >> in a release are fixed. >> >> Monty >> >> >> >> > Thanks Monty for your response. But i still have doubt. Actually if i > could explain this is what we are doing and is the problem. We are > porting OggVorbis Encoder (i am talking about encoder only ) on DSP. > According to my understanding this is what we observerd that for > different sampling rates/nchannels we have different setups. We want > all sampling rates, mono/stereo and quality support so all setups > would have to be considered. And it is observed that total memory from > VQ codebooks is huge considering all sampling rates and qualities. The > lookups for lenghtlist are as big as 6561 elements . Similarly > valuelist takes huge memory (upto 300 KB) dynamically. As per my > understanding these codebooks take both large heap memory and static > lookup memory (For 44 KHz there are around 100 codebooks). OggVorbis > encoder takes huge data memory where VQ codebooks are taking most > memory. For DSP this memroy requirement is toooo high. So the > questions come up that... > 1.How do we reduce this memory? > 2.Cant we use single codebook? What is the logic behind lenghtlist > tables of varying lenngths like 6561, 625 etc? If we ignore 6561 what > will hapenn? > 3.Do you have any option for lesser codebooks that can be used in > embedded systems? > 4. Will we have to do algorithm level changes for VQ and create own > codebooks? > > In short Memory is a big concern and after going through the code as > per my understanding VQ codebooks consume most memory. Please if you > could help. > > Parul > Embedded Engineer > Einfochips Ltd > > > > > > > >