[CELT-dev] Possible Bug

[Riccardo Micci]

It is indeed a 16 bits char architecture and this explains the problem 
since end_bits_left is 0. Anyway a correct initialization should be 
preferable in this case.

Unrelated question: i see that CELT has been already ported to TI 
platform. I'd need some performance estimation on those DSPs. I see that 
you wrote fixed_c5x.h header file, would you mind giving me some number if 
you have them?

Regards
Riccardo


Riccardo Micci
Senior DSP Engineer, Wireless Group 
Cambridge Consultants
Science Park, Milton Road 
Cambridge, CB4 0DW, England
Switchboard: +44 (0)1223 420024
Direct dial: +44 (0)1223 392402
Mobile: +44 (0)
Fax: +44 (0)1223 423373
riccardo.micci at cambridgeconsultants.com
www.CambridgeConsultants.com
 




Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca> 
02/09/2010 14:14

To
Riccardo Micci <riccardo.micci at cambridgeconsultants.com>
cc
celt-dev at xiph.org
Subject
Re: [CELT-dev] Possible Bug






Riccardo Micci <riccardo.micci at cambridgeconsultants.com> a écrit :
> (s=ec_decode_raw(_this,_ftb);).
> In ec_decode_raw within the while loop the following line is executed:
> value |= _this->end_byte>>(8-_this->end_bits_left)<<count;
> As you can see end_byte is read and used before nothing else has written
> in it before.
> This produce different results on different platforms.

When executing
value |= _this->end_byte>>(8-_this->end_bits_left)<<count;
the first time, the value of _this->end_bits_left should be equal to 
0, which means that we are shifting _this->end_byte (an unsigned char) 
by 8, so the result should be zero regardless of the content of 
_this->end_byte. Can you check whether _this->end_bits_left is really 
zero when you see the problem happening? It could be either the 
symptoms of an unrelated issue or something wrong with your build 
setup. On what platform do you see the problem occurring (any chance 
it's one with 16-bit chars)?

Cheers,

    Jean-Marc

> Regards
> Riccardo
>
> Riccardo Micci
> Senior DSP Engineer, Wireless Group
> Cambridge Consultants
> Science Park, Milton Road
> Cambridge, CB4 0DW, England
> Switchboard: +44 (0)1223 420024
> Direct dial: +44 (0)1223 392402
> Mobile: +44 (0)
> Fax: +44 (0)1223 423373
> riccardo.micci at cambridgeconsultants.com
> www.CambridgeConsultants.com
>
>
>
>
>
> Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
> 02/09/2010 13:41
>
> To
> celt-dev at xiph.org
> cc
> riccardo.micci at cambridgeconsultants.com
> Subject
> Re: [CELT-dev] Possible Bug
>
>
>
>
>
>
>> The problem comes decoding the next frame. Since now "shortBlocks" is
> false,
>> "end_byte" is not initialized anymore and next functions read it before
>> update.
>>
>> Can someone confirm this behaviour? In my case i modified ec_dec_init
>> function to initialize it as well. What is the correct value?
>
> Can you give a bit more information on what's happening? The end_byte
> field does not need to be initialized because it should get read when
> end_bits_left is zero. In what function is the uninitialized read
> happening and what happens then?
>
>     Jean-Marc
>
>
>
>
>
>
>
> This email is from Cambridge Consultants Limited, Science Park, Milton
> Road, Cambridge CB4 0DW with registered number 1036298 England. It may
> contain confidential information. It is intended for the addressee only
> and may not be copied or disclosed to any third party without our
> permission. If you are not the intended recipient please contact the
> sender as soon as possible and delete the material from any computer. If
> this email has been sent as a personal message to the addressee, the
> sender is not acting in his/her capacity as an employee or officer of
> Cambridge Consultants Limited and no liability is accepted for the 
content
> of any such email. Outgoing email may be monitored for the purpose of
> ensuring compliance with our email policy and relevant laws.
>
>
>









This email is from Cambridge Consultants Limited, Science Park, Milton 
Road, Cambridge CB4 0DW with registered number 1036298 England. It may 
contain confidential information. It is intended for the addressee only 
and may not be copied or disclosed to any third party without our 
permission. If you are not the intended recipient please contact the 
sender as soon as possible and delete the material from any computer. If 
this email has been sent as a personal message to the addressee, the 
sender is not acting in his/her capacity as an employee or officer of 
Cambridge Consultants Limited and no liability is accepted for the content 
of any such email. Outgoing email may be monitored for the purpose of 
ensuring compliance with our email policy and relevant laws.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20100902/aacc19a3/attachment-0002.htm