Signal Processing Stack Exchange is a question and answer site for practitioners of the art and science of signal, image and video processing. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let me start by clarifying the terminology that I will be using in the following.

A codec packet is the compressed data which an encoder returns when it is called once.

An RTP payload can consist of one codec packet or a sequence of codec packets.

My questions:

Does the RFC for SILK allow the RTP payload to consist of more than one codec packet?

If so, how do I split up the received RTP payload into the codec packets so each packet can be decoded later in time (one codec packet at a time) ?


An application encodes 20ms 16bit LPCM audio blocks using SILK. Each codec packet is sent down to the network stack for transmission via RTP. Let's say that the first 4 times the encoder is called, the encoder outputs:

1) A 20ms codec packet of size 39 bytes 2) A 20ms codec packet of size 35 bytes 3) A 20ms codec packet of size 41 bytes 4) A 20ms codec packet of size 32 bytes

The network stack in the application assembles an RTP payload consisting of the 4 codec packets. So in this case the RTP payload size is 39 + 35 + 41 + 32 = 147 bytes.

On the receiving end, the 147 byte RTP payload is received. How is the receiving application supposed to split up the RTP payload into the original 4 codec packets of 39, 35, 41 and 32 bytes, respectively????

I'm pretty sure that the RFC doesn't allow this kind of scenario, but I want to make sure. Can somebody confirm whether or not the RFC allows for more than one codec packet per RTP payload???

As far as I understand, the RFC only allows ONE codec packet per RTP payload. If it's desired to send 80ms per payload, the way it should be done is to configure the encoder to output 80ms codec packets (instead of 20ms). Is this correct???

share|improve this question

I believe you are correct.

The RFC for Silk allows up to 5, 20ms segments of data representing a single frame per RTP packet.

From the draft rfc...

4.2. Payload Structure

The SILK encoder can be set to output encoded frames representing 20, 40, 60, 80, or 100 ms of speech or audio data. Only one frame output from the encoder MUST be used as the payload. Figure 1 shows the structure combined with the RTP header.

+----------+--------------+ |RTP Header| SILK Payload | +----------+--------------+

See for more details. Also search for the most recent draft of RFC to be sure you are current.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.