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

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 08 Jul 2009 09:44:36 -0400

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.

> In 5.2. Low-Overhead Mode, the text says:
>    "One the a=fmtp: parameter low-
>    overhead: is defined and contains a single frame size, followed by a
>    '/', followed by a comma-separated list of the number of bytes per
>    frame for each stream defined in the channel mapping."
> but the example gives:
>  a=fmtp:97 low-overhead=256/1/86,86,43,30;mapping=2,2,1,1/
>       L,R,LR,RR,C,MLFE/ITU-RBS.775-1
> What is the extra /1 supposed to mean in 256/1/86,86,43,30 ?

Sorry. The /1 was a left-over from a previous revision and is no longer 
necessary. I've removed it now.

> Also, a simpler example (e.g. for mono and stereo streams) could be 
> illustrative.

Thanks for the suggestion. I added a plain mono example. The next now reads:

    For example a low-overhead 64 kbit/s mono stream could be signaled
    as:
       m=audio 8008 RTP/AVP 97
       a=ptime: 5
       a=rtpmap:97 CELT/48000/1
       a=fmtp:97 low-overhead=256/43

    and a low-overhead 360 kbit/s 5.1 surround configuration could be
    signaled as:
       m=audio 8008 RTP/AVP 97
       a=ptime: 5
       a=rtpmap:97 CELT/48000/6
       a=fmtp:97 low-overhead=256/86,86,43,25;mapping=2,2,1,1/
       L,R,LR,RR,C,MLFE/ITU-RBS.775-1

Cheers,

	Jean-Marc

---

From: Stefan Sayer <[email-masked]>
Date: Wed, 08 Jul 2009 17:02:00 +0200

Hello Jean-Marc,

thanks a lot for the quick response!

> 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

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 08 Jul 2009 11:20:22 -0400

> 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.

> 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