[asterisk-dev] OPUS horrible quality with packet loss

[Kevin Harwell]

On Mon, Apr 3, 2017 at 1:28 PM, Yury Tsaregorodtsev <aero.1080 at icloud.com>
wrote:

> 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/ 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.
>
>
Hi Yury,

We for sure want to look more into this. If you would open an issue on the
Asterisk issue tracker [1] it would be much appreciated. Be sure to include
all your findings.

When possible list the exact version numbers you are using for the various
tools and libraries being used (Asterisk - output of running "asterisk -V",
PESQ, Opus library for when you used the Asterisk open source codec, etc).

Also if possible include information about your Asterisk setup. Dialplan
used (extensions.conf), endpoint configuration (pjsip.conf or sip.conf),
etc...

Also include the exact commands you used when running tests. All of this
will greatly help in duplicating results.

[1] https://issues.asterisk.org

Thanks!

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170405/4a837a78/attachment-0001.html>