search for: bitpackers

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

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

(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our

On 9/25/2017 9:14 AM, Björn Pettersson A wrote: > > (Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to

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

...vorbis, 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). Removing the bitpackers from libogg would of course be an API change to libogg, but we could defer that. K.

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);

So what is the correct behavior of the store <2 x i2>. Storing two bytes with a zext:ed i2 in each, or a bit packed vector? I can't remember any documentation mentioning that vectors are bit packed. But if LLVM is supposed to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors? Maybe bit packing should be

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