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) ?
Example:
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???
