Constrained-Energy Lapped Transform

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von CELT)
Constrained-Energy Lapped Transform
Dateiendung: keine
MIME-Type: audio/celt
Entwickelt von: Xiph.Org Foundation, IETF-Codec-Arbeitsgruppe
Erstveröffentlichung: Dezember 2007
Aktuelle Version: 0.11.1 (Stand: 15. Februar 2011)
Art: Audio
Enthalten in: Ogg
Erweitert zu: Opus
Standard(s): aktueller IETF-Internet-Entwurf
Website: celt-codec.org

Constrained-Energy Lapped Transform (CELT; deutsch etwa: überlappende Transformation mit vorgegebener Energie) ist ein (patent-)freies Datenformat/Verfahren zur verlustbehafteten Audiodatenkompression mit besonders niedriger Codec-Latenz, um bei Echtzeit-Anwendungen in der Verarbeitung des typischerweise unmittelbar vor der komprimierten Übertragung erzeugten Signales möglichst wenig Verzögerung (Latenzzeit) zu verursachen. Das Verfahren ist offen dokumentiert und frei von Softwarepatentrestriktionen nutzbar. Es wurde von der Xiph.Org Foundation (als Teil der Ogg-Codec-Familie) und der Codec-Arbeitsgruppe der Internet Engineering Task Force (IETF) entwickelt, ist mittlerweile jedoch in der Weiterentwicklung Opus aufgegangen. Damit ist CELT als eigenständiges Format aufgegeben worden und wird nur noch in seiner mit SILK integrierten, hybridisierten Form als eine Schicht von Opus weiterentwickelt. Dieser Artikel behandelt das historische, eigenständige Format, für die integrierte Form und die seit der Integration in Opus erfolgten Weiterentwicklungen siehe den Artikel zu Opus.

Eigenschaften

Die Zielsetzung ist ein Verfahren für Echtzeit-Anwendungen. Zentrales angestrebtes Merkmal dafür ist niedrige Codec-Latenz. CELT ermöglicht Latenzen von typischerweise 3 bis 9 ms, jedoch konfigurierbar bis hinunter zu unter 2 ms, wobei niedrigere Latenzen mit höheren Bitraten für gleiche Qualität erkauft werden.[1] CELT unterbietet damit deutlich die mit anderen Standard-Codecs möglichen Latenzen.

Dabei ist es wie das Schwesterprojekt Vorbis ein breitbandiges (den gesamten menschlichen Hörbereich abdeckendes) Allzweck-Verfahren, also ohne Spezialisierung auf bestimmte Arten von Signalen, was es von seinem anderen Schwesterprojekt Speex abhebt. Es verarbeitet Audio-Signale mit Abtastraten zwischen 32 und 96 kHz und bis zu zwei Kanälen (Stereophonie). Damit ermöglicht das Format prinzipiell transparente Ergebnisse, jedoch auch Bitraten von bis hinunter zu 24 kBit/s.[1] Die Kompressionsfähigkeiten sollen insgesamt MP3 deutlich überlegen sein. Als weitere für einige Echtzeit-Anwendungen wie Telefonie nützliche Eigenschaft weist CELT eine sehr gute Leistung bei niedrigen Bitraten auf. Hier soll die Klangqualität mit Hilfe der Frequenzbandfaltung auch Vorbis deutlich überlegen und sogar ähnlich der von HE-AACv1 sein.[2][3] Auch erwies es sich in vergleichenden Doppelblind-Hörtests bei ~64 kBit/s deutlich als HE-AACv1 überlegen.[4]

Es hat eine vergleichsweise geringe Komplexität; der Berechnungsaufwand ähnelt dem der verzögerungsarmen Variante von AAC (AAC-LD) und hält sich deutlich unter dem von Vorbis.[5]

Es ermöglicht konstante und variable Bitraten. Verschwindet in Sprechpausen und ähnlichen Fällen auf Encoder-Seite das Signal im Rauschteppich, so kann die Übertragung darauf beschränkt werden, dem Dekodierer die Überbrückung mit erzeugtem Komfortrauschen zu signalisieren. Die meisten Einstellungen des streamingfähigen Formates können im laufenden Datenstrom gewechselt werden.

Das Format reagiert robust auf Übertragungsfehler. Sowohl der Verlust ganzer Pakete als auch Bitfehler können mit einer gleichmäßigen Zunahme an Störungen maskiert werden (Packet Loss Concealment, PLC).

Technik

Blockdiagramm des Codecs

CELT ist ein Transformations-Codec auf Basis der modifizierten diskreten Kosinustransformation (MDCT) und Ansätzen von CELP (Codebuch zur Anregung, jedoch in der Frequenzdomäne).

Das ursprüngliche PCM-codierte Signal wird für die MDCT (Fensterfunktion) in vergleichsweise kleine, überlappende Blöcke zerlegt und in Frequenzkoeffizienten transformiert. Durch die Wahl einer besonders geringen Blocklänge wird einerseits geringe Latenz ermöglicht, ergibt sich andererseits aber auch eine schlechte Frequenzauflösung, die ausgeglichen werden muss. Zur weiteren Reduzierung der Codec-Latenz auf Kosten geringfügiger Qualitätsverluste wird die ihrer Natur nach jeweils 50-prozentige Überlappung der MDCT-Zeitfenster praktisch halbiert, indem Anfang und Ende des Fensters für jeweils ein Achtel der Zeit das Signal auf Null gesetzt wird.[1] Unter anderem zur besseren Ausnutzung von blockübergreifenden Korrelationen trotz der sehr kurzen Blocklängen ist das Verfahren zustandsbehaftet und stützt die Kodierung eines CELT-Blockes auf Daten vergangener Blöcke.

Die Koeffizienten werden gruppiert zu Frequenzgruppen, die weitgehend denen der menschlichen Wahrnehmung entsprechen. Der gesamte Energiegehalt jeder Gruppe wird ausgewertet und diese Energiewerte werden quantisiert (=Datenreduktion) und mit einer Vorhersage komprimiert, indem nur noch Korrekturwerte zu den Vorhersagewerten übertragen werden müssen (Delta-Kodierung).

Aus den DCT-Koeffizienten werden jeweils die (unquantisierten) Energiewerte herausgerechnet (Normierung). Die Koeffizienten des somit erhaltenen Restsignales (englisch „band shape“) werden mit Pyramid Vector Quantisation (PVQ, einer sphärischen Vektorquantisierung)[6] kodiert. Diese Kodierung führt zu Codeworten von fester (vorhersehbarer) Länge, was Toleranz gegenüber Bitfehlern ermöglicht, und macht weiterhin eine Entropiekodierung überflüssig.[3] Zum Abschluss werden dennoch alle Ausgangsdaten des Encoders noch mit einer Bereichskodierung zu einem einzigen Bitstrom zusammengepackt.[7] In Verbindung mit der PVQ nutzt CELT eine als Frequenzbandfaltung bezeichnete Technik, die durch die Wiederverwendung von Koeffizienten tieferer für höhere Frequenzbänder ähnliches wie die Spektralbandreplikation (SBR) leisten soll und dabei wesentlich niedrigere Implikationen für die Codec-Latenz und die Komplexität (Berechnungsaufwand) hat. Die dadurch erhöhte Reichhaltigkeit in den entsprechenden Frequenzbereichen verhindert die sonst üblicherweise auftretenden störenden Zwitscher-Artefakte (englisch „birdie artifacts“, „musical noise artifacts“).

Der Dekodierer entpackt den Bitstrom wieder in seine Bestandteile, multipliziert die errechneten separaten Energiewerte wieder mit den DCT-Koeffizienten des Restsignals zusammen und überführt sie mit der inversen MDCT wieder in PCM-Daten. Die einzelnen Blöcke werden mittels gewichteter segmentierter Faltung (englisch „weighted overlap add“, WOLA) wieder zusammengefügt. Viele Parameter werden nicht explizit übertragen, sondern stattdessen im Dekodierer mittels derselben Funktion gewonnen, wie im Encoder.

Für die Kanalkopplung stehen bei CELT M/S-Stereo und Pegeldifferenzstereophonie zur Verfügung. Blöcke können auch unabhängig beschrieben werden (Intra-kodierter Schlüsselblock), um zum Beispiel dem Dekodierer einen Einstieg in einen laufenden Datenstrom zu ermöglichen. Da bei Transformations-Codecs scharfe, energiereiche Klangereignisse (Transienten) hörbare Quantisierungsfehler im gesamten DCT-Block erzeugen können, welche vom Transienten in rückwärtiger zeitlicher Richtung weit weniger maskiert werden als danach, können als vorauseilende Echos wahrnehmbare Artefakte (englisch „pre-echo artifacts“) auftreten. Bei CELT können die Blöcke jeweils nochmal unterteilt werden, um solchen Artefakten entgegenzuwirken.

Geschichte

2005 arbeitete man bei Xiph im Rahmen des Ghost-Projekts erstmals an Plänen und Entwürfen für einen Vorbis-Nachfolger (anfangs im Gespräch als Vorbis II). Daraus entsprang neben den Codec-Plänen von Vorbis-Schöpfer Christopher Montgomery, die zugunsten der Weiterentwicklung von Theora gestoppt wurden, auch Jean-Marc Valins Konzept für ein besonders latenzarmes Verfahren. Seit 2007 entwickelt Valin an CELT und übertrug am 29. November ersten Code ins Repositorium des Projektes.[3] Im Dezember 2007 wurde die erste Entwicklungsversion 0.0.1 veröffentlicht, zunächst benannt als Code-Excited Lapped Transform.[8] CELT liegt seit Juli 2009 bei der IETF als Vorschlag für einen freien Codec-Standard für Telekommunikation über das Internet vor[9][10], womit nun auch die Codec-Arbeitsgruppe der IETF an der Entwicklung beteiligt ist.

Ab Version 0.9 ist die bisher eingesetzte Tonhöhen-Vorhersage in der Frequenz-Domäne durch eine weniger komplexe Lösung mit einem Vor- und einem Nachfilter in der Zeitdomäne ersetzt,[11] welche von Raymond Chen von Broadcom beigesteuert wurde.[3]

Mit CELT 0.11 vom 4. Februar 2011 wurde das Bitstromformat vorläufig festgelegt – unter Vorbehalt eventueller, wider Erwarten nötiger letzter Änderungen.

Obwohl das Format noch nicht endgültig festgelegt ist, wird das Verfahren seit Januar 2009 in den IP-Telefonie-Anwendungen Ekiga und FreeSWITCH sowie mittlerweile auch Mumble, TeamSpeak und weiterer[12] Software verwendet. Kurz nach dem Erscheinen des Hybrid-Codecs Opus (früher bekannt als „Harmony“) ist CELT als Grundlage von Opus in diesem aufgegangen und wird ausschließlich im Rahmen dieses Nachfolgeprojektes weiterentwickelt.[13] Opus stellt eine Obermenge zu CELT und dem Verfahren SILK dar, in dem die CELT-Algorithmen für einen oberen Frequenzanteil, die von SILK für den unteren zuständig sind. Der entsprechende Entwurf liegt bei der IETF seit September 2010 vor.

Im April 2011 wurde Unterstützung für CELT in FFmpeg aufgenommen.[14][15]

Software

Referenzimplementierung ist eine in der Programmiersprache C geschriebene Programmbibliothek namens libcelt, die als freie Software unter Xiphs eigener dreiklausliger BSD-artiger Lizenz veröffentlicht wird.

Weblinks

Quellen

  1. ↑ a b c Präsentation des Verfahrens von Timothy B. Terriberry (65 Minuten Video in ~100 MiB OggTheora+Vorbis, siehe auch Präsentationsfolien in PDF, ~2,3 MiB)
  2. ↑ Jason Garrett-Glaser: Important: upcoming CELT bitstream freeze! (Nicht mehr online verfügbar.) In: ffmpeg-devel.mplayerhq.hu - FFmpeg development discussions and patches mailing list. mplayerhq.hu, 18. November 2010, ehemals im Original; abgerufen am 25. Januar 2011 (englisch).@1@2Vorlage:Toter Link/lists.mplayerhq.hu (Seite nicht mehr abrufbar, Suche in Webarchiven)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis.
  3. ↑ a b c d Christopher Montgomery: next generation audio: CELT update 20101223. In: Monty's demo pages. Xiph.Org, 23. Dezember 2010, abgerufen am 26. Januar 2011 (englisch).
  4. ↑ Dirk Bösel: CELT beeindruckt beim 64 kb/s Multiformat Hörtest (2011). In: MPeX.net. MPeX.net GmbH, 18. April 2011, abgerufen am 25. April 2011.
  5. ↑ Jean-Marc Valin, Timothy B. Terriberry, Christopher Montgomery, Gregory Maxwell: A High-Quality Speech and Audio Codec With Less Than 10 ms Delay. In: IEEE Signal Processing Society (Hrsg.): IEEE Transactions on Audio, Speech and Language Processing. Band 18, Nr. 1, 17. April 2009 (englisch, xiph.org [PDF; abgerufen am 16. Februar 2011]).
  6. ↑ Thomas R. Fischer: A pyramid vector quantizer. In: IEEE (Hrsg.): IEEE Transactions on Information Theory. Band 32, Nr. 4, Juli 1986 (englisch).
  7. ↑ zweiter bei der IETF eingereichter Entwurf der Spezifikation
  8. ↑ Jean-Marc Valin: Experimental release of Ghost/CELT 0.0.1. In: Hydrogenaudio Forums. 9. Dezember 2007, abgerufen am 26. Januar 2011 (englisch).
  9. ↑ Monika Ermert: IETF kümmert sich um lizenzfreien Audiocodec. In: heise online. 13. November 2009, abgerufen am 12. Februar 2011.
  10. ↑ erster bei der IETF eingereichter Entwurf der Spezifikation
  11. ↑ Jean-Marc Valin: CELT decoder complexity. (Nicht mehr online verfügbar.) In: CELT-dev-Mailingliste. Xiph.Org, 15. Februar 2011, archiviert vom Original am 2. April 2012; abgerufen am 16. Februar 2011 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/lists.xiph.org
  12. ↑ Software that uses or supports CELT. In: CELT-Website. Xiph.Org, abgerufen am 25. Januar 2011 (englisch).
  13. ↑ Jean-Marc Valin, Koen Vos: Definition of the Opus Audio Codec. In: IETF Internet-Drafts. IETF Network Working Group, Oktober 2010, abgerufen am 25. Januar 2011 (englisch).
  14. ↑ ffmpeg.org
  15. ↑ git.videolan.org
Abgerufen von „https://de.wikiup.org/index.php?title=Constrained-Energy_Lapped_Transform&oldid=223178141“