opus - May 2016 - RFC for Opus Packet in RTP Payload

Hello All

When sending the Opus Packet in RTP Payload, the compressed frame is the
output of the encoder?

Also the config value as given in the RFC6716,

16...19               | CELT-only | NB        | 2.5, 5, 10, 20 ms

16 corresponds to 2.5 ms
17 corresponds to 5 ms
18 corresponds to 10 ms
19 corresponds to 20 ms

Is this correct representation of the data?

Also in the RFC3551 the payload values are specified but does not give any
information on whether OPUS encoder has been used?

Regards
Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/opus/attachments/20160509/24b6856d/attachment.html>

On Mon, May 9, 2016 at 7:11 PM, Amit Ashara <ashara.amit at gmail.com>
wrote:
> Hello All
>
> When sending the Opus Packet in RTP Payload, the compressed frame is the
> output of the encoder?
Yes.
>
> Also the config value as given in the RFC6716,
>
> 16...19               | CELT-only | NB        | 2.5, 5, 10, 20 ms
>
> 16 corresponds to 2.5 ms
> 17 corresponds to 5 ms
> 18 corresponds to 10 ms
> 19 corresponds to 20 ms
>
> Is this correct representation of the data?
Yes.  These values are decimal and are the first 5 bits of the packet
produced by the encoder.
>
> Also in the RFC3551 the payload values are specified but does not give any
> information on whether OPUS encoder has been used?
RTP Payload Types are assigned dynamically.  For example, the line
"a=rtpmap:101 opus/48000/2" in the SDP (RFC 4566) session description
indicates that RTP Payload Type 101 is encoded as Opus (see RFC 7587).
There are some very old statically defined Payload Types listed in RFC
3551, but no new static assignments may be registered (see RFC 3551
section 3).
>
> Regards
> Amit