[asterisk-bugs] [JIRA] (ASTERISK-26924) Codec OPUS bad quality

[Kevin Harwell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236461#comment-236461 ] 

Kevin Harwell commented on ASTERISK-26924:
------------------------------------------

An update that could be the difference:

In my testing I dialed extension 997 at host1 from a phone using ulaw. I was then listening to the audio coming out of the phone. For a number of the cases it did not sound good. However, if I listened to the associated recorded .wav file the audio sounded much better for some of the cases. Because of this I updated my original chart in the comment above to reflect that.

For each case where the jitter buffer was in use the audio sounded "OK". Meaning it was not the best audio, but it was intelligible. There was a difference too with the open source opus codec with the PLC patch. Again, the audio was noticeably degraded, but was still intelligible.

It seems to me that the problem is the packet delay. Which makes sense since the Asterisk translate core does not handle delayed packets. The jitter buffer improved the audio of course since it is meant to handle that scenario. Likewise the open source plc patch improved the audio since it too attempts to handle that scenario as well.

> Codec OPUS bad quality
> ----------------------
>
>                 Key: ASTERISK-26924
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26924
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Codecs/codec_opus
>         Environment: Ubuntu 16.04 i386/x86_64
>            Reporter: TSAREGORODTSEV Yury
>            Assignee: Kevin Harwell
>         Attachments: kharwell-audio.tar.gz
>
>
> Codec OPUS developed by Digium doesn't provide same good quality as open source version in case of packet losses, delays.
> After comparing recorded degraded media with original sample using PESQ results shows average predicted MOS of Digium Opus almost twice less then open source.
> How to reproduce issue:
> 1. Environment: ubuntu 16.04
> 2. Libopus latest stable release 1.1.4 (compiled from sources).
> 3. Asterisk 13.14.0
> 4. Channel driver: chan_sip
> 5. Configure 2 asterisk hosts, where 1st host origination side, 2nd host termination side.
> 6. Configure dialplan: on 1st host Dialplan with AppMonitor
> {noformat}
> [opus-test]
> exten => _X.,1,Monitor(wav,/records/degraded-ID-${RAND(1,1000)},bi)
> exten => _X.,n,Dial(SIP/asterisk_host2/${EXTEN})
> {noformat}
> 7. Configure dialplan: on 2nd host Playback any wave file (8000, 16bit):
> {noformat}
> [opus-test]
> exten => _X.,1,Answer()
> exten => _X.,n,Playback(demo-instruct)
> {noformat}
> 8. Opus config on both:
> {noformat}
> [opus]
> type=opus
> packet_loss=40
> max_playback_rate=48000
> bitrate=24000
> cbr=0
> fec=1
> {noformat}
> 9. Compile ITU-T PESQ utility from
> https://github.com/dennisguse/ITU-T_pesq
> 10. Simulate packet loss/delays on 2nd host with
>     tc qdisc add dev eth0 root netem loss 20% delay 100ms 20ms distribution normal
> 11. Compare recorded degraded media (only incoming channel of course) with original:
> ./itu-t-pesq2005 +8000 original.wav recorded.wav
> P.S. Please keep in mind without applying patch ASTERISK-25629 asterisk doesn't ignore lately arrived RTP no matter of enabled, forced jitterbuffer. Which is make quality worst.



--
This message was sent by Atlassian JIRA
(v6.2#6252)