Stefan Sayer wrote:
o Jean-Marc Valin [07/08/09 15:44]:Hi Stefan, Thanks very much for taking the time to review this draft. Stefan Sayer wrote:My suggestion is to remove the first diagram (anyway it is clear that the payload follows the RTP header), or add the length bytes to it to make clear that this is the usual mode of packetization.I have followed your suggestion and removed the diagram.If I have understood correctly, this is essentially two different modes of packetization, the default one (where frame size bytes are alway present, also if only one frame per packet), and the L-O mode (without frame size). May I additionally suggest a clarifying paragraph about this in "3.2. CELT payload" ?
Thanks for the suggestion. I've slightly rephrased it (and changed frame size to compressed size to avoid confusion with the frame size that's in samples):
More than one frame may be encoded in the same RTP packet, and for the decoder it is not possible to determine the compressed size (bit- rate) of each encoded frame. Thus the compressed size information MUST be explicitly transmitted. There are two modes for conveying this information: either the compressed size(s) are encoded for each frame at the beginning of the RTP payload Section 3.3, or it is conveyed in the signaling and then fixed for the duration of the session (Low-Overhead Mode, Section 5.2). Note that the compressed frame size information must be present either way even if only single frames are transmitted per RTP packet.
I also have one further question about the Low-Overhead mode: Do you expect this to be the standard use case, or (possibly also due to the limitation of fixed bitrate) only the corner case where bandwidth saving wins over flexibility? I think it might make sense to give a recommendation about which mode to use, i.e. where the tradeoff really points in which direction.
At this point, I do not know which of the two modes would be the most useful. I'm interested in opinions on this.
Cheers, Jean-Marc