[opus] Regarding error handling in Opus Decoder

[Rhishikesh Agashe]

Hi Ralph,

We tried to test the Opus decoder using the attached vectors and got the below mentioned  errors.
If the errors are to be detected at the network layer, then, I believe that the conditions in these vectors won't occur till the control reaches the opus decoder.

Do let me know if I have understood it correctly.

Thanks and Regards,
Rhishi


-----Original Message-----
From: Ralph Giles [mailto:giles at thaumas.net] 
Sent: Sunday, October 06, 2013 11:51
To: Rhishikesh Agashe; opus at xiph.org
Cc: Rasmi Mishra
Subject: Re: [opus] Regarding error handling in Opus Decoder

On 2013-10-04 1:34 PM, Rhishikesh Agashe wrote:

> I believe that it should reject the erroneous payload and start 
> decoding the next payload for it to work properly in a streaming environment.

Because the decoder's predictor state converges over multiple packets of data, you cannot just skip to the next payload without introducing decoding errors.

We have also tried to make the reference implementation strict to help dectect data corruption bugs during deployment.

Thus, stopping the decoder on corrupt data is the expected behaviour.

How are you encountering these conditions?

'Invalid Payload Length' and especially 'Range coder state mismatch'
indicate either corrupt data for a decoder bug. Corrupt packets should be detected and discarded by the network layer, in which case you can use the packet loss concealment and/or forward error correction support to minimize the damage.

 -r
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testvector12_corrupt.bit
Type: application/octet-stream
Size: 56702 bytes
Desc: testvector12_corrupt.bit
Url : http://lists.xiph.org/pipermail/opus/attachments/20131008/3436d64e/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testvector08_corrupt.bit
Type: application/octet-stream
Size: 140061 bytes
Desc: testvector08_corrupt.bit
Url : http://lists.xiph.org/pipermail/opus/attachments/20131008/3436d64e/attachment-0003.obj