[Tremor] bitwise.c question

[Hans Petter Selasky]

On Tuesday 21 February 2006 17:52, Monty wrote:
> On Tue, Feb 21, 2006 at 05:11:06PM +0100, Hans Petter Selasky wrote:
> > I see it is a pitfall that oggpack_read() can return -1. Consider this:
>
> Quite right, no need to explain.  There was an overload here that was
> ill-considered but preserved for interests of ABI compatability.
> libogg2 alters the call/return semantics to something less convenient
> but more sensible.
>
> > Does anyone have any comments on this change. Also I have a new bitwise.c
> > that is some percent faster. Up to 50% for "bits > 20":
>
> It's not hard to make it faster, the faster is simply more complex is
> all.
>
> Monty

There was a small bug in my code. The "temp &=" part should be:

    if (bits >= 2) {

        if ((bits >= 4) && shift) {

          temp &= ((htole32(((u_int32_p_t *)ptr)->data) >> shift)|
                   (ptr[4] << (32-shift)));
        } else {

          temp &= (htole32(((u_int32_p_t *)ptr)->data) >> shift);
        }

    } else {

      temp &= (htole16(((u_int16_p_t *)ptr)->data) >> shift);
    }

Else it returns errornous in some cases, sorry.

Do you have any suggestion where I should check if the read is still valid, so 
to abort the decoding process or is this neccesary at all? Hence I see that 
it was very clever of the Ogg Vorbis designers, to insert some bits that 
should always be 1 on valid packets, hence if the packet is not there, the 
oggpack_get_multi_m() will return 0, and the decoding process will stop 
naturally.

I have attached some statistics. If you don't get the attachment, it just 
shows a gap between the old bit-de-packer and mine, with regard to the time 
it takes to process "n" bits.

--HPS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bp_test00.eps
Type: image/x-eps
Size: 14266 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/tremor/attachments/20060221/3d122fbc/bp_test00.bin