[asterisk-dev] Opus and VP8

[Lorenzo Miniero]

2013/6/5 Andrea Suisani <sickpig at opinioni.net>

> Hi Lorenzo and all,
>
>
> On 06/04/2013 05:31 PM, Lorenzo Miniero wrote:
>
>> Dear James and all,
>>
> >
> >
>
>> I managed to find out the cause of the issue. I simply forgot (mea
>> culpa!) to add a couple of lines to the patch (which is why I couldn't
>> replicate it in my setup, where the lines exist) which tells Asterisk which
>> rate to use for the format. As you know, Opus always uses 48kHz, while the
>> default in
>> Asterisk is 8000: this caused wrong timestamp increase calculations on
>> the non-Opus RTP leg, and hence the corrupt audio.
>>
>> I updated the patch on the repository. If you don't want to apply the
>> patch again, just add these lines in the ast_format_rate method of format.c:
>>
>> /* Opus */
>> case AST_FORMAT_OPUS:
>> return 48000;
>>
>> and make/make install again. The easiest thing to do is put this as the
>> last case before the default.
>>
>> Let me know if this fixes the issue,
>>
>
> as I already said this fix solve the issue we had.
>
> the tests we made are related to this configuration:
>
>         (sip+opus)             (iax/sip+g729)
> WebRTC ----------->  Asterisk -----------------> pstn/mobile
>           (A)                      (B)
>
> I know that there is no ad-hoc Opus configuration yet,
> but I'm trying to measure the bandwidth of the call opus leg (A).
>
> I've used iftop to get a rough measure, catching only udp
> packets. the iftop instance was executed on the same host
> where asterisk is running catching packets only on the net
> interface to which asterisk is bind to.
>
> While using opus the A leg bandwidth is something like 50/55 kb/s,
> from the webrtc client to the asterisk, while something along
> 100kb/s from asterisk to client. is it normal?
>
>
Opus is conceived to be able to transparently switch rate during a call. In
the code I made sure that the encoding would take note of the peer sampling
rate, in order to cap it in Opus as well. This means that, if you're
talking to a GSM/ulaw/g729 peer, Opus itself should be "capped" at 8kHz as
there would be no need for a higher sampling rate to transport the audio.

What does the debug say in your case? When the encoder and decoder are
created, do you get a opus->8000 and 8000->opus output, or is something
else appearing? You can also check how big each encoded frame is, and how
big each Opus incoming frame is on the other end, enabling a huge debug.
I'll try to also add some more debug to check the rate of each individual
packet, in case the capping I put in place is not working as expected. In
2.1 of http://www.ietf.org/id/draft-ietf-payload-rtp-opus-00.txt there are
indications about the typical bitrates at the supported sampling rates.

That said, I guess that other codec optimizations may be available that my
integration does not make use of, so I guess I'll have to look into this as
well.


> with ulaw I've got 85kb/s both from and to the asterisk server.
>
> another strange thing: when switching codec I need to restart asterisk
> to get a functioning calls otherwise callee (pstn end point) does not hear
> anything.
>
>
Restart Asterisk or restart the call? This sounds a bit extreme!
Switching codecs shouldn't be an issue, though.

Lorenzo


> this could be related to my setup/dialplan and having nothing to
> do with the patch in itself by the way, still it seems fishy though.
>
> Andrea
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130605/2b146194/attachment-0001.htm>