[asterisk-dev] OPUS horrible quality with packet loss

Mon Apr 3 13:28:18 CDT 2017

after fixing attr->fec in open source edition of OPUS and applying Alexanders patch: ASTERISK-25629 (Native Packet-Loss Concealment)
I have following results:

I setup 2 hosts with asterisk 13.14.0 and made dozen calls in OPUS between them.
On 2nd host I've simulated packet delay and loss:
tc qdisc add dev eth0 root netem loss 20% delay 100ms 20ms distribution normal

On 1st host (call origination side) all media been recorded using App_Monitor.
On 2nd host it was simple Playback extension with demo-instruct.sln16

Config for digium codec_opus on both was:
[opus]
type=opus
packet_loss=40
max_playback_rate=48000
bitrate=24000
cbr=0
fec=1

Config for open source edition of OPUS was same, but replaced values in include/asterisk/opus.h
(and as well I've added to codecs/codec_opus_open_source.c  status = opus_encoder_ctl(opvt->opus, OPUS_SET_PACKET_LOSS_PERC(packet_loss));)

All recorded degraded media files were compared to original (recorded with AppMonitor as well, but without any delays, losses) accordingly to ITU-T P.862 (Perceptual evaluation of speech quality (PESQ)): 

Reading degraded file 	 opus_opensource-maxbitrate_24000-cbr_0-fec_1-ID1.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.840	 2.589	 8000	nb
Reading degraded file 	 opus_opensource-maxbitrate_24000-cbr_0-fec_1-ID2.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.507	 2.143	 8000	nb
Reading degraded file 	 opus_opensource-maxbitrate_24000-cbr_0-fec_1-ID3.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.379	 1.994	 8000	nb
Reading degraded file 	 opus_opensource-maxbitrate_24000-cbr_0-fec_1-ID4.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.472	 2.102	 8000	nb
Reading degraded file 	 opus_opensource-maxbitrate_24000-cbr_0-fec_1-ID5.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.413	 2.032	 8000	nb

Reading degraded file 	 opus_digium-maxbitrate_24000-cbr_0-fec_1-ID1.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 1.332	 1.258	 8000	nb
Reading degraded file 	 opus_digium-maxbitrate_24000-cbr_0-fec_1-ID2.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 0.738	 1.110	 8000	nb
Reading degraded file 	 opus_digium-maxbitrate_24000-cbr_0-fec_1-ID3.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.426	 2.047	 8000	nb
Reading degraded file 	 opus_digium-maxbitrate_24000-cbr_0-fec_1-ID4.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 0.920	 1.143	 8000	nb
Reading degraded file 	 opus_digium-maxbitrate_24000-cbr_0-fec_1-ID5.wav	 P.862 Prediction (Raw MOS, MOS-LQO):  = 2.680	 2.366	 8000	nb

MOS on calls using open source opus higher almost twice.
Subjective opinion regarding audio quality: using open source codec quality almost same as in example on http://opus-codec.org/examples/ <http://opus-codec.org/examples/> with 30% loss and FEC, acceptable for ears, but
using digium opus quality is not acceptable, a lot of spikes, interruptions.

I also double checked the fact before applying ASTERISK-25629 patch asterisk don't drop lately arrived RTP.
I've recorded UDP dump and replayed it using "bittwist" utility, without patch all RTP packets been played again, with patch all of them been ignored.

Thx, Alexander :)

> On 3 Apr 2017, at 18:26, Kevin Harwell <kharwell at digium.com <mailto:kharwell at digium.com>> wrote:
> 
> On Fri, Mar 31, 2017 at 6:54 PM, Yury Tsaregorodtsev <aero.1080 at icloud.com <mailto:aero.1080 at icloud.com>> wrote:
> Examples of OPUS with 30% of LOSS with FEC on http://opus-codec.org/examples/ <http://opus-codec.org/examples/>
> Sounds too perfect. Why I can't achieve even similar quality on asterisk with built codec by digium?
> To simulate 30% packet loss I use:
> # tc qdisc add dev eth0 root netem delay 100ms loss 30%
> But even with 15-20% of loss it's almost impossible to talk.
> Tried different bitrates, result is always same. 
> If I do PESQ predicted MOS of degraded audio (recorded with packet loss) in compare to original: 1.025
> Horrible results, horrible sound.
> 
> Anyone get better experience using opus with huge packet losses ?
> 
> 
> Have you enabled FEC and made sure both sides negotiated it? If not you can enable it within "codecs.conf" by setting "fec=yes".
> 
> When a packet has been lost and the decoder receives a frame with FEC data (and fec is enabled) it will attempt to rebuild the lost packet (current packet minus one) from the given FEC information.
>  
> Kevin Harwell
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com <http://digium.com/> & http://asterisk.org <http://asterisk.org/>-- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com <http://www.api-digital.com/> --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev <http://lists.digium.com/mailman/listinfo/asterisk-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170403/16174c53/attachment.html>