[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Request for feedback on draft-valin-celt-rtp-profile-01.txt

Hello Jean-Marc,

thanks a lot for the quick response!

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" ? 

   An RTP packet MAY contain CELT frames of the same bit rate or of
   varying bit rates, since the bitrate for the frames is explicitly
   conveyed in band with the signal.  The encoding and decoding
   algorithm can change the bit rate at any frame boundary, with the bit
   rate change notification provided in-band.  No out-of-band
   notification is required for the decoder to process changes in the
   bit rate sent by the encoder.

+  More than one frame may be encoded in the same RTP packet, and for
+  the decoder it is not possible to determine the size of each encoded
+  frame. Thus the frame size information MUST be explicitly trans-
+  mitted. There is two modes how this information may be conveyed:
+  Either the frame 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 frame size
+  information must be present either way even if only single frames
+  are transmitted per RTP packet.

   It is RECOMMENDED that sampling rates 32000, 44100, or 48000 Hz be
   used for most applications, unless a specific reason exists -- such
   ...
Maybe this is too verbose, but I think you get the idea what would make the busy reader, who may be unfamiliar with the codec and its requirements, understand it more quickly.
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. 

Thank You very much
Stefan Sayer