[asterisk-dev] Opus and VP8
James Mortensen
james.mortensen at voicecurve.com
Wed May 29 10:37:19 CDT 2013
On Wed, May 29, 2013 at 7:18 AM, Lorenzo Miniero <lminiero at gmail.com> wrote:
> Hi James,
>
> I've added some comments inline.
>
>
> 2013/5/28 James Mortensen <james.mortensen at voicecurve.com>
>
>> Hi Lorenzo,
>>
>> Not trying to hijack the thread, but Andrea appears to be away for the
>> next few days, and I'm experiencing the same exact problem with the audio
>> issues and want to help move us both forward. So I can answer the
>> questions below to get you more data. Please see below:
>>
>>
>> [May 28 11:17:40] DEBUG[16613][C-00000000] channel.c: Scheduling timer at
>>> (50 requested / 50 actual) timer tic
>>>
>>>
>>>> That said, I'm not sure what the cause of the issue could be. What
>>>> ptime are the two peers using?
>>>> What is the transcoding path
>>>> as displayed on the Asterisk console? Does the same happen in other
>>>> scenarios as well, e.g., the browser interacting with another
>>>> browser, or a softphone using a different codec (e.g., speex) at
>>>> different rates (e.g., 16kHz vs 8kHz)?
>>>>
>>>
>>> now I'm out of office I will be able to provide this info
>>> only on Thursaday.
>>>
>>>
>> I assume the ptime is this maxptime value we see in the SDP from the
>> Chrome to Asterisk call leg:
>>
>> a=rtpmap:111 opus/48000/2
>> a=maxptime:60
>> a=fmtp:111 maxplaybackrate=16000; stereo=0; sprop-stereo=0; useinbandfec=0
>>
>> If that's not the ptime, please let me know where I might find that and
>> I'll get it for you.
>>
>>
> By ptime I mean how many milliseconds of audio are contained in a single
> RTP packet. Usually this is 20ms for most codecs but that's not always the
> case: Opus, for instance, supports a wide range of different ones, which is
> why in the SDP we report that the maximum ptime that is supported in the
> implementation is 60ms.
>
> The Asterisk codec encoding/decoding infrastructure should already
> transparently take care of this, considering that when encoding and
> decoding you always know how many samples are involved, but I didn't test
> this intensively, and so a difference in how the two "legs" do this (e.g.,
> 20 ms for the Opus leg, 10 ms for the G.729 leg) may in some cases cause
> hiccups.
>
>
>> And here you can see the call leg from the Chrome to Asterisk portion
>> of the call is opus, with the other leg using ulaw. I've tried with g729
>> on the Bandwidth to Asterisk leg and still hear the same underwater-like
>> call audio that Andrea describes.
>>
>> ip-10-188-135-200*CLI> sip show channels
>> Peer User/ANR Call ID Format Hold
>> Last Message Expiry Peer
>> 54.X.X.X 1000 55srb9arjvh7rnv (opus) No
>> Rx: ACK ws-Opensip
>> 67.231.X.X +15036XXXXXX 48c000dd54ba525 (ulaw) No
>> Tx: ACK BANDWIDTH
>> 2 active SIP dialogs
>> ip-10-188-135-200*CLI>
>>
>>
>> Also, here is the output from opus set debug huge:
>>
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 18 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 20 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 77 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 19 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 67 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 17 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 71 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 21 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 21 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 23 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 69 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 19 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 72 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 21 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 74 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 23 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 74 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 21 bytes
>> [Opus] [Decoder #12 (8000)] 960 samples, 75 bytes
>> [Opus] [Decoder #12 (8000)] >> Got 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] 160 samples, 320 bytes
>> [Opus] [Encoder #9 (8000)] >> Got 960 samples, 25 bytes
>>
>>
> The "huge" debug doesn't seem to report anything wrong: the encoder gets
> 160 samples in 320 bytes (8kHz slin) and encodes them correctly, and at the
> same time the decoder gets 960 samples (as in Opus the reference rate is
> always 48kHz) and decodes them to 160 samples/320 bytes (8kHz slin). So
> apparently no encoding/decoding error is reported from the library.
>
> What about the transcoding path in Asterisk, though? e.g.
>
> core show translation paths opus
>
> should tell you how Asterisk is going to take care of the transcoding
> between Opus and different codecs.
>
>
>> Unlike Andrea, who applied the patch to 11.3.0, I successfully applied
>> the patch to Asterisk 11.4.0, but the issues we're both experiencing appear
>> to be the same. If that's not the case, I can start a new thread. Hope
>> this helps! :)
>>
>>
> I'm not sure how much those two versions of Asterisk differ from each
> other, so I'm afraid I cannot answer you with respect to that: anyhow, I
> guess that there's no need to open a new thread. But just out of curiosity,
> did you try to replicate the same scenarios with Asterisk 11.1.2 as well?
> Just to understand whether or not I can focus on the latest changes to
> investigate what's wrong in the current Opus implementation.
>
> Lorenzo
>
> --
>> James Mortensen
>> Project Manager, VoiceCurve, Inc.
>> 866-707-4590
>> james.mortensen at voicecurve.com
>>
>
>
Hi Lorenzo,
Here is the result of the core show translation paths opus:
ip-10-188-135-200*CLI> core show translation opus path
Usage: 'core show translation' can be used in two ways.
1. 'core show translation [recalc [<recalc seconds>]]
Displays known codec translators and the cost associated
with each conversion. If the argument 'recalc' is supplied along
with optional number of seconds to test a new test will be
performed
as the chart is being displayed.
2. 'core show translation paths [codec]'
This will display all the translation paths associated with a
codec
ip-10-188-135-200*CLI> core show translation paths opus
--- Translation paths SRC Codec "opus" sample rate 8000 ---
opus To g723 : No Translation Path
opus To gsm : (opus)->(slin)->(gsm)
opus To ulaw : (opus)->(slin)->(ulaw)
opus To alaw : (opus)->(slin)->(alaw)
opus To g726 : (opus)->(slin)->(g726)
opus To adpcm : (opus)->(slin)->(adpcm)
opus To slin : (opus)->(slin)
opus To lpc10 : (opus)->(slin)->(lpc10)
opus To g729 : (opus)->(slin)->(g729)
opus To speex : No Translation Path
opus To speex16 : No Translation Path
opus To ilbc : (opus)->(slin)->(ilbc)
opus To g726aal2 : (opus)->(slin)->(g726aal2)
opus To g722 : (opus)->(slin16)->(g722)
opus To slin16 : (opus)->(slin16)
opus To siren7 : No Translation Path
opus To siren14 : No Translation Path
opus To testlaw : (opus)->(slin)->(testlaw)
opus To g719 : No Translation Path
opus To speex32 : No Translation Path
opus To slin12 : (opus)->(slin12)
opus To slin24 : (opus)->(slin24)
opus To slin32 : (opus)->(slin)->(slin32)
opus To slin44 : (opus)->(slin)->(slin44)
opus To slin48 : (opus)->(slin48)
opus To slin96 : (opus)->(slin)->(slin96)
opus To slin192 : (opus)->(slin)->(slin192)
opus To silk8 : No Translation Path
opus To silk12 : No Translation Path
opus To silk16 : No Translation Path
opus To silk24 : No Translation Path
ip-10-188-135-200*CLI>
There appears to be paths for both ulaw as well as g729.
I did try the patch on Asterisk 11.1.2, but shifted gears when I realized
the crypto headers are buggy as per
https://issues.asterisk.org/jira/browse/ASTERISK-20849. However, I'll
apply the patch to fix that issue and then try a call on Asterisk 11.1.2.
I'll follow up with additional details when I know more. Again, thank you
for your time and your work on this. We're really stoked about getting opus
working in Asterisk! :)
--
James Mortensen
Project Manager, VoiceCurve, Inc.
866-707-4590
james.mortensen at voicecurve.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130529/2b4f4487/attachment-0001.htm>
More information about the asterisk-dev
mailing list