Re: [AVT] Submission and request for feedback on draft-valin-celt-rtp-profile-00.txt

[Gregory Maxwell <[e-mail]>]

Jean-Marc Valin wrote:
> Randell Jesup wrote:
[snip]

> Yes, the bit-rate information is actually the compressed frame length
> itself.

To clarify: CELT is designed assuming a length-preserving transport.
If a CELT frame of N bytes is received, the receiver assumes the
encoder encoded that frame at a rate of sample_rate/frame_samples*N
bytes per second.

For naturally length preserving transports (such as raw UDP, RTP, or
most other transports) no signalling of bitrate is required at all,
internally to the codec or externally, beyond the length preservation.

However, since we needed to support multiple frames per packet for RTP
(for multichannel audio, and to allow flexible trade-off of latency vs
overhead), we needed to provide an in-channel length encoding that the
decoder can use differentiate the bitrates used by the component frames
of the packet.

This is accomplished by explicitly enumerating the lengths of the packed
frames at the start of the packet payload.  The transport still must be
length preserving since the total packet length must be known to determine
when to stop reading lengths.  This is perfectly robust against packet
loss, but should be protected against bit-error.  I suppose it might
be worthwhile to make a recommendation regarding CRC coverage (i.e.
for UDP light).

We also considered an alternative of encoding the number of frames
per packet in a byte, followed by N-1 lengths, but decided that simply
encoding N lengths would likely be slightly easier to implement and would
likely have somewhat better bit error robustness properties in practice.

(Of if someone has reason to believe that another scheme is more likely
to be correctly implemented…)

This length encoding process must be made sufficiently clear in the
draft. If it isn't currently then that needs to be resolved.

>>> CELT allows for bitrate adjustment in one byte per frame increments
>>> without any signaling requirement or overhead. Applications SHOULD
>>> utilize congestion control to regulate the transmitted bitrate.  In 
>>> some applications it may make sense to increase the packetization 
>>> interval rather than decreasing the codec bitrate.  Congestion 
>>> control implementations should consider the users differential 
>>> tolerance for high latency and low quality.
>> That would be (I assume) really 1 byte per channel per frame, not 1 byte 
>> per frame.  
> Well, technically you can increase the bit-rate by one byte for only one 
> channel...

Perhaps the clarity of the draft would be improved with some standalone
definitions:

* Packet  — A unit of network transmission, containing IP/UDP/RTP
headers and one or more CELT frames.

* Frame — A unit of codec operation, representing frame_samples samples
for one or two channels of audio.

* Channel — A stream of audio, transported in groups of one or two in a
single frame by CELT

The codec can adjust its instantaneous bitrate with one byte per frame
granularity. This means that for congestion control purposes one byte
per packet granularity is available regardless of the number of channels
encoded or frames per packet, so long as the encoder is willing to use
slightly unequal bitrates per frame.

The logic the sender uses in distributing the available capacity to frames
(and channels) isn't relevant for interoperability, so I don't see cause
to make a recommendation. However, if it would make the draft more clear
it would be possible to do so.

>> DTLS?

Quite reasonable.  Most of that section is from the boiler-plate RTP
profile security considerations in draft-ietf-avt-rtp-howto-06.txt. We
can add that to draft-valin-celt-rtp-profile-00.txt but the changes should
also be made to the rtp-howto unless there is a reason not to do so.

Our enhancements to that section consist of recommendations regarding
timing and length-information-leakage attacks, the latter of which is
somewhat CELT specific since CELT can fill any target byte-size.