Subject: Re: [AVT] Requesting feedback on new CELT codec

From: "Gregory Maxwell" <[email-masked]>
Date: Sun, 27 Jul 2008 00:28:00 -0400

Steve Underwood <steveu at coppice.org> wrote:
> So far Polycom has managed to get each of its codecs into an ITU spec - G.722.1, G.722.1C and G.719. However, I've only ever seen
> these things supported by Polycom products. That is in spite of the patents on G.722.1C being offered royalty free. An ITU spec is no
> guarantee of anything happening in the real world.
[snip]

This may be because G.722.1C 'royalty free license' has a fairly
gnarly patent termination clause that might make it a 'costly'
proposition for commercial players, and the license also includes
advertising requirements and sub-licensing prohibitions which make it
incompatible with free software licensing.  ... it also may be just
because the performance is somewhat lack-luster: It offers fairly high
latency yet faired pretty poorly in our listening tests.
(http://www.celt-codec.org/comparison/) OTOH, G.722.1C is
computationally cheap...

Swinging this back on topic a bit more:   With typical frame sizes in
the range of 8ms any overhead is very harmful.  CELT does a fairly
good job of avoiding overhead internally, not wasting more than ~1 bit
or so per frame.

But this means that the codec's several tunables are not signaled in
the individual frames:  Sample rate, frame size, and stereo/mono must
be explicitly and correctly negotiated out of band or the codec will
fail to decode. (Bitrate need not be signaled: the codec can infer the
bitrate from the frame sizes).   So it's important for CELT today that
some higher level system takes care of working out these details.  Is
this a requirement which would harm some applications?
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Sun, 27 Jul 2008 09:07:14 -0400

"Gregory Maxwell" <[email-masked]> writes:
>bitrate from the frame sizes).

Not a problem so long as you restrict packetization time when using CELT to
less than the lowest common multiple of the bitrates - assuming you mean by
"infer the bitrate from the frame sizes" that it's infered from the byte
length of the buffer.  If it's inferred from some internal frame-end bit,
then no problem.

In the VoIP space, most packetization (not frame) times seem to be 20-30ms.

>So it's important for CELT today that

A couple of things to consider:

* Media arriving before the answer (usually 200 OK in SIP):
  Since the signaling often takes a different path, or is via UDP and the
  first transmission can be lost, you may need to decode packets without
  having seen the answer yet - or you have to refuse to decode until seeing
  the answer, which you can do, but it sub-optimal.  In iLBC, the answer
  can force the period to 20 or 30ms, and if the packetization time is 60
  or 120ms the offerer can't tell (see above).  Normally iLBC is used with
  20 or 30ms packetiztion, so the answerer can infer which is used.
* There may be some applications which store packets (instead of encoding
  on the fly) which wouldn't be able to easily use a codec with lots of
  negotiated options, or where the answerer (or offerer?) can't force which
  options are selected.  (For example, in iLBC the answerer can force 30ms
  by answering with mode=30.)
* Not unique to CELT, but on a re-negotiation (re-INVITE) during a call,
  you have to be careful about changing options when the stream is running
  if you can't infer when the change happens from the bit/packet-stream
  itself.  One solution (though not often used in practice) is to switch
  payload types in the re-negotiation.  May be worth mentioning as an
  advisory in the draft.

There may be others issues.  The first item is the most important.

I realize in the audio regime this may be anathema (or was), but another
option is a variable encoding size, so at addition items can be included
occasionally.  This does mess up frame-length inference from packetization
sizes.  Alternatively, you could use a more complex scheme that encodes the
extra tunable information a few bits at a time into the individual frames.
Perhaps too complex in practice, and packet loss could require waiting for
another cycle of packets to go by.  If the tunables are a low number of
bits or the encoding has a fair portion of a byte left over per frame, it
may be more viable.

Note also that there's nothing sacred about allowing multiple frames to be
concatenated in an RTP packet.  An RFC could disallow that, and instead 
implement it's own packetization scheme that includes additional
information (if needed) and avoids the aliasing issue.  This may cost you
in bandwidth, however, but could be useful with very small frame sizes.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)