[CELT-dev] Possible Bug
Riccardo Micci
riccardo.micci at cambridgeconsultants.com
Thu Sep 2 06:00:38 PDT 2010
Decoding the second frame the function unquant_fine_energy is executed.
Within it ec_dec_bits subfunction is executed (q2 = ec_dec_bits(dec,
fine_quant[i]);). Ec_dec_bits calls ec_decode_raw
(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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20100902/8df354e1/attachment-0002.htm
More information about the celt-dev
mailing list