Hi, We're testing CELT (version 0.7.1) error resilience capability. We've used already celtdec packet-loss options. Hence we know what to expect in case of whole packet loss. How does Celt respond to a broken encoded packet? Is it always better to discard it and decode the missing frame through decode_lost? We have the hardware capability of protecting the frame with multiple CRCs. Hence we might have a rough estimation of how many bits are wrong in the frame (no error correction though), in case of few corrupted bits, is it better to use the current frame for decoding? Thanks Best 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 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/20110317/aa1fa9c8/attachment-0002.htm
Hi,
CELT always puts the most important bits first, so the best is to only
look for errors in the first N bits. If there is an error in these
bits, consider the packet lost. If not, continue decoding as usual.
For mono, N should be in the order of 64 bits, but you may want to
test by yourself. Note that CELT has some ability to detect errors,
but it is *very* limited (e.g. at some rates, you may detect only
1/1000 of corrupted frames).
Jean-Marc
Riccardo Micci <riccardo.micci at cambridgeconsultants.com> a ?crit?:
> Hi,
> We're testing CELT (version 0.7.1) error resilience capability.
We've used
> already celtdec packet-loss options. Hence we know what to expect in case
> of whole packet loss.
> How does Celt respond to a broken encoded packet? Is it always better to
> discard it and decode the missing frame through decode_lost?
> We have the hardware capability of protecting the frame with multiple
> CRCs. Hence we might have a rough estimation of how many bits are wrong in
> the frame (no error correction though), in case of few corrupted bits, is
> it better to use the current frame for decoding?
>
> Thanks
>
> Best 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
>
>
>
>
>
>
> 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.
>
>
>
On Thu, Mar 17, 2011 at 2:05 PM, Riccardo Micci <riccardo.micci at cambridgeconsultants.com> wrote:> > Hi, > We're testing CELT (version 0.7.1) error resilience capability. We've used already celtdec packet-loss options. Hence we know what to expect in case of whole packet loss. > How does Celt respond to a broken encoded packet? Is it always better to discard it and decode the missing frame through decode_lost? > We have the hardware capability of protecting the frame with multiple CRCs. Hence we might have a rough estimation of how many bits are wrong in the frame (no error correction though), in case of few corrupted bits, is it better to use the current frame for decoding?The CELT bitstream is designed to be bit error robust ? or at least as robust as we could make it without compromising the compression significantly. Part of that effort was that we concentrated the corruption sensitive parts at the front of the frame so that unequal protection should be used. In general it's better to decode the frame rather than throw it out unless the very front part of the frame (first 64 bits or so) is significantly corrupted. This graph shows quality (higher is better) in the form of PEAQ ODG as a function of error position: https://people.xiph.org/~greg/celt/error.sweep3.png It also shows lines for the ODGs given by 1:100, 1:1000 packet loss. ODG isn't a great metric for errored signals so your result may vary, but this should give you an idea.