Difference between revisions of "CELT/IETF"

From XiphWiki
Jump to navigation Jump to search
m (Add notice that CELT was merged into Opus)
Line 1: Line 1:
{{Obsolete|The CELT codec has been merged into the IETF [[Opus]] codec and is now obsolete}}
== Intro ==
== Intro ==
* CELT description and design goals
* CELT description and design goals

Latest revision as of 05:30, 23 June 2016


  • CELT description and design goals
  • CELT RTP profile
  • Open issues

About CELT

  • Two types of codecs
    • Speech codecs with low-medium quality and low delay
    • Music codecs with high quality and high delay
  • CELT aims for both high quality and very low delay
  • Perceptual transform (MDCT) codec
  • Developped within the Xiph.Org Foundation
  • Reference implementation is open source (BSD-licensed)
  • No royalties, avoids known patents in the field

Why low delay?

  • Low delay is critical to live interactions
    • Prevents collisions during conversations (higher sense of presence)
    • Reduces or remove the need for acoustic echo cancellation
    • Allows synchronization for live music performance
  • Increased range
    • 1ms reduction = 200 km more in fiber

CELT features

  • Sampling rates from 32 kHz to 48 kHz
  • Total algorithmic delay from 2ms to 20 ms (8 ms typical)
  • Configurable frame size from 64 samples to 512 samples
  • Bit-stream not frozen yet

Comparison with existing codecs

  • Summary of quality figures, along with delay and bit-rate

draft -- Important Facts

  • The bit-rate is implicitly encoded in the size of the compressed data
  • The decoder must know:
    • The frame size (decompressed samples) being transmitted
    • The size of each compressed packet


  • Lacing values and all?


  • SDP parameters
    • ptime
    • b=AS: ?
  • CELT-specific parameters
    • frame-size=
    • mapping=
    • low-overhead=


Open issues

  • Need to negotiate the frame size
  • CELT would be more flexible with configuration data (~100 bytes)
    • Configuration packet transmitted at regular interval
    • Incrmentally tramsmitted (one byte at a time)
    • base64-encoded in SDP parameters

Future work

  • Freeze the bit-stream
  • Complete RTP profile
  • Possible standardization (IETF or other)