search for: bitpacked

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 something else in theora/vorbis already.

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 use big endian order? Is it safe to mix calls to

I haven't actually had many questions up to now. Despite the all-encompassing CP_INSTANCE monolith, things have been relatively easy going. Now we get into real grit: First off, CBitman looks like it has endianness issues; it's packing into host-order 32 bit arrays (the comments and symbol names seem to indicate that this was originally byte-based packing code that got upped to 32 bit.

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 smaller...

...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; &gt...

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

On 09/02/2008, Ralph Giles <giles@xiph.org> wrote: > Yes, all that is reasonable. The original argument was that we need a > library anyway, no one noticed the 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...

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

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 smaller...

Hi, I am trying to implement ogg vorbis real time decoder on SHARC ADSP 21364 processor. I am writing my own version of the decoder using the documentation vorbis_I_spec.pdf from xiph.org. However I am facing certain hurdles in floor curve decoding during audio packet decode. In the spec it says that [cval] = read from packet using codebook number [so and so] in *scalar context*.(page no 43).

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.

Hello 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.

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

On Fri, Nov 11, 2005 at 07:17:53PM +1100, Erik de Castro Lopo wrote: > We'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