search for: bitpack

From googling around, it seems that the ogg bitpacker has defined endianness, but I can't find anywhere that says which order it's in. Any help? The endianness of the 24 bit field in the OggPCM header should be specified. I was going to edit the wiki to specify it as network byte order, then realized that you may have standardized on so...

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions...

...his was originally byte-based packing code that got upped to 32 bit. Either that or someone is a bit confused about a byte being 32 bits...) Whose responsibility is it to flip bytes before putting out a stream? Is native order big or little endian? I'm seriously considering tossing Ogg's bitpacker into the codec as it has defined endianness behavior and is already used throughout Ogg (the API is very similar). Also, this is probably my own confusion, but is it really the case that the encoder app has to guess about packet size and just hope the output buffer doesn't overflow? The Ogg...

While browsing the code I came across line 83 bitpack.c: *_ret=((ret&0xFFFFFFFFUL)>>(m>>1))>>(m+1>>1); Is there any reason why this is so convoluted? Maybe endianess or 64 bit issues? If I'm not mistaken it does exactly the the same as: *_ret = ret >> m; Cheers, Nils

...size in our target is 16 bits. When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had to patch is the getStoreSize() method in ValueTypes/MachineValueTypes where we assume that vectors are bitpacked when the element size is smaller than the byte size (“BitsPerByte”): /// Return the number of bytes overwritten by a store of the specified value /// type. unsigned getStoreSize() const { - return (getSizeInBits() + 7) / 8; + // We assume that vectors with elements small...

...storing an i40 we need to store it as three 16-bit bytes, i.e. 48 > bits. > > When storing a v4i40 vector it will be stored as 4x48 bits. > > One thing that we have had to patch is the getStoreSize() method in > ValueTypes/MachineValueTypes where we assume that vectors are > bitpacked when the element size is smaller than the byte size > (“BitsPerByte”): > >      /// Return the number of bytes overwritten by a store of the > specified value > >      /// type. > >      unsigned getStoreSize() const { > > -      return (getSizeInBits() + 7) / 8; &...

Hi, it seems Ogg keeps track of a packet's size at the byte level, rather than at the bit level (eg, if I encode a packet with just one bit, decode will think there are 8 bits available). Am I right ? Not that it's a particularly important issue, since remaining bits will probably be initialized, but I noticed this while adding some calls to oggpack_look1 at the end of my decode routines

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

...function call overhead, and using > libogg simplified the embedding. > > Now, we'd like to remove libogg entirely as a dependency to avoid > confusion when using other containers, but that's an api change... As far as libvorbis is concerned, wouldn't the step of copying the bitpacker into libvorbis, where the functions are only used internally, just allow a dependency change? There is of course the bit of the libvorbis API which talks in terms of ogg_packet structures, but maybe we could replicate the definition of that in a vorbis header file (inside of #ifndef _OGG_H). Re...

Ivo Emanuel Gon?alves wrote: > And IF that kind of performance can be gained in libvorbis too, the > question is, what are we waiting for? I doubt the performance gain would be that large. Theora had the fun little situation where it was thunking into the big endian version of some bitpacker functions which were one-line calls to the little endian version. Because gcc seemed to be concerned that some dynamic library could override one and not the other, it went through the routine of saving old registers and setting up the PIC register two times, and then restoring everything...

Hi, i have some code that gives me a "warning: Buffer too small to pack bits" mesage. looking at the libspeex source/bits.c i see the warning in a a function named speex_bits_pack. i'm not using this function. can someone tell me where this may be coming from since i've had a similiar problem before and had that fixed. i can't seem to pinpoint this one. thanks Greg

hi all I found that in the revision 10730 of the libogg2 library it is impossible to do bitpacking. this is due to the implementation of the (at least) two functions oggpack_writeinit() and oggpack_readinit(). they both take an (oggpack_buffer *) as an argument and immediately erase all it's contents: void oggpack_readinit(oggpack_buffer *b,ogg_reference *r){ memset(b,0,sizeof(*b));...

i don't think so. this is my current code: for(i=0; i<samples;i++){ /*only get max 320 bytes at a time so bits can handle*/ Client->raw_audio[i] = *input++; Client->temp_audio[i] = Client->raw_audio[i]; Client->session_File[ndx] = Client->temp_audio[i]; ndx+=1; } speex_bits_reset(&ebits);

...size in our target is 16 bits. When storing an i40 we need to store it as three 16-bit bytes, i.e. 48 bits. When storing a v4i40 vector it will be stored as 4x48 bits. One thing that we have had to patch is the getStoreSize() method in ValueTypes/MachineValueTypes where we assume that vectors are bitpacked when the element size is smaller than the byte size (“BitsPerByte”): /// Return the number of bytes overwritten by a store of the specified value /// type. unsigned getStoreSize() const { - return (getSizeInBits() + 7) / 8; + // We assume that vectors with elements small...

...the huffman decode tree we need the MSB of the codeword first. How is this issue overcome in the reference implementation? I was not able to understand what was going on from the reference implementation. 2. Currently, to keep track of unused entries and to reduce memory usage we have adopted the bitpacking scheme of vorbis. For example: ...00010110 implies that entry numbers 1,2 and 4 are being used whereas the others are not. entry 1: codeword 0 entry 2: codeword 1 entry 4: codeword 2 and so on .. This is done during setup. Later, during audio packet decode we are using this information during...

From: Nathaniel Gray <n8gray@gmail.com> Date: Sep 14, 2005 11:30 AM Subject: Newbie q: decoupling vorbis from ogg To: vorbis-dev@lists.xiph.org Hi, Sorry if this is a newbie question. I'm trying to write an OS X AudioCodec for Vorbis using libvorbis. I'm confused about the libvorbis dependency on libogg. I thought the vorbis spec didn't require ogg as the container, but the

It's very small, maybe it could be made a separate statically linked lib ? Or some of it inlined. That said, libogg is small too, and some of the routines in there are quite small as well.

...lo Monty, Sorry for the wrong subject title last time. A little more clarification needed. When reading bit-by-bit, there is no MSb/LSb, just 'first bit' and 'last bit'. The Huffman tree is traversed from 'first bit' to last bit'. This is a conceptual layer above the bitpacker; all you need to know is what order the bits come out, which happens to be LSb-first. For ex. say we have the following codewords in the codebook entry 0: codeword0 - 00 entry 2: codeword1 - 0111 entry 6: codeword2 - 111 entry 7: codeword3 - 10 Now in the bitstream if there is [codeword0] foll...

Hi, I have some questions: 1) in the sources of the encoder_example (and of course in oggenc.c, too) I see a lot of dependance on ogg. I want to get totally rid of ogg and use the vorbis bitstream alone. From this reason stems the second question: 2) is there a definition of the vorbis bitstream somewhere? I don't need to know every single detail, just the informations necessary to

...9;re talking about a file header here. Even if the header is a kilobyte in > size, it will be completely **dwarfed** by the audio data following. So why > are you counting single bits like this? Why waste? You only have to read the header once for a stream, and libogg2 provides a convient bitpacker which can easily grab any number of bits and give you an int containing their value. Just because you /CAN/ waste a few bytes, what's the reason to do so? > > I really don't like this idea, but I will entertain, formatting it as follows: > > > > ID Type Bits &gt...