Loading AI tools
Aus Wikipedia, der freien Enzyklopädie
Der internet Low Bitrate Codec (iLBC) ist ein offen dokumentierter, lizenzgebührenfreier Sprachcodec, der von Global IP Solutions (GIPS) entwickelt worden ist. Er hebt sich von älteren Codecs insbesondere dadurch ab, dass er speziell für paketvermittelte Datennetze wie etwa das Internet konzipiert worden ist und daher sehr gut mit Paketverlust und Jitter zurechtkommt. iLBC ist folglich insbesondere für IP-Telefonie (VoIP) geeignet.
Internet Low Bit Rate Codec (iLBC) | |
---|---|
Dateiendung: | .lbc |
MIME-Type: | audio/iLBC |
Magische Zahl: | '#!iLBC30\n' bzw. '#!iLBC20\n' |
Entwickelt von: | Global IP Solutions |
Aktuelle Version | Dezember 2004 |
Art: | Sprachcodec |
Standard(s): | RFC 3951[1] |
webrtc.org (Seite nicht mehr abrufbar. Suche in Webarchiven) historisch: http://ilbcfreeware.org/ | |
Der in RFC 3951[1] spezifizierte Codec iLBC ist ein Schmalbandcodec, erfasst also Frequenzen bis 4000 Hz. Der Standard definiert eine Variante mit einer Blocklänge von 30 ms sowie eine mit einer Blocklänge von 20 ms bei einer Abtastrate von 8 kHz und einer Abtasttiefe von 16 Bit.
Die Innovation hinter iLBC ist der blockunabhängige Linear-Predictive-Coding-Algorithmus mit kontrollierter Reaktion auf Paketverlust. Blockunabhängigkeit bedeutet, dass jeder Block völlig unabhängig von den vorangegangenen kodiert wird und somit keine Informationen aus den vorigen Blöcken benötigt werden, um die folgenden Blöcke richtig zu dekodieren. Bei den zuvor veröffentlichten komprimierten Sprachcodecs war das nicht so, wodurch sich Fehler in der Folge von Paketverlust in paketbasierten Datennetzen, wie z. B. dem Internet, über die nachfolgenden Blöcke hinweg fortschreiben. Beim Codec G.729 führt das z. B. zu dumpfen, explosionsartigen Geräuschen auf Empfängerseite. Die Ursache für diesen technischen Mangel liegt darin, dass diese Codecs für das traditionelle digitale Telefonnetz gedacht waren, das auf virtuellen Verbindungen basiert, bei denen überhaupt nicht vorgesehen war, dass Blöcke verloren gehen können. Deshalb hat man diese Codecs nur gegenüber Bitfehlern robust gestaltet. Paketvermittelte Datennetze reagieren allerdings auch auf Bitfehler völlig anders als virtuelle Verbindungen in leitungsvermittelten Netzwerken, da die einzelnen Pakete Prüfsummen erhalten und einfach verworfen sowie gegebenenfalls neu übertragen werden, wenn ein Bitfehler festgestellt wurde. Mit dem Aufkommen von VoIP bestand daher die Notwendigkeit einen Codec zu schaffen, der diesen neuen technischen Gegebenheiten gerecht wird.
Zusätzlich bietet iLBC ein Packet Loss Concealment, wie zum Beispiel der Standard ITU-T G.711, der auf Puls-Code-Modulation (PCM) basiert und mit einer festen Bitrate von 64 kbit/s arbeitet. Dabei wird für den fehlenden Teil des Audiosignals ein Ersatzsignal generiert, das aus den umliegenden Blöcken errechnet wird.
Aufgrund dieser Eigenschaften ermöglicht der iLBC-Codec eine verhältnismäßig gute Sprachqualität, selbst wenn Datenblöcke aufgrund verlorener oder verzögerter IP-Pakete fehlen.
Bei iLBC 30 umfasst jeder Block ein Audiosignal von 30 ms bzw. 240 Samples, die in 399 Datenbits plus 1 Leerbit codiert sind. Dies entspricht 50 Oktetts bzw. Bytes pro Block.
Netto | Brutto RTP mit IPv4 | Brutto RTP mit IPv6 | |
---|---|---|---|
Datenrate in kbit/s | 13,33 | 24 | 29,33 |
Es handelt sich um die ältere der beiden Varianten von iLBC.
Bei iLBC 20 umfasst jeder Block ein Audiosignal von 20 ms bzw. 160 Samples, die in 303 Datenbits plus 1 Leerbit codiert sind. Dies entspricht 38 Oktetts bzw. Bytes pro Block.
Netto | Brutto RTP mit IPv4 | Brutto RTP mit IPv6 | |
---|---|---|---|
Datenrate in kbit/s | 15,2 | 31,2 | 39,2 |
Die Entwickler von iLBC charakterisieren den gegenüber iLBC 30 jüngeren iLBC 20 folgendermaßen:
“When […] compared to 30 ms frame size mode, this 15.2 kbps mode is characterized with: higher basic quality, higher packet loss robustness, lower complexity and algorithmic delay.”
„Verglichen mit dem 30 ms-Blocklängenmodus hat dieser 15,2-kb/s-Modus folgende Eigenschaften: Höhere Grundqualität, größere Robustheit gegenüber Paketverlust, geringere Komplexität und weniger algorithmische Verzögerung.“
Das typische Protokoll zur Übertragung von Datenströmen im Internet ist RTP. Es kommt unter anderem bei VoIP mit SIP zur Anwendung. Um über den gesamten Übertragungsweg hinweg auszuhandeln, welche Datenformate bei den Gesprächsteilnehmern und an den Servern vorhanden bzw. zulässig sind, teilen die einzelnen Punkte dies im SIP-Kopfdatenbereich als SDP Offer mit. Wird iLBC 20 bevorzugt, sieht diese SDP Offer folgendermaßen aus:
a=rtpmap:109 iLBC/8000 a=fmtp:109 mode=20
Wird iLBC 30 bevorzugt, gilt mode=30:
a=rtpmap:109 iLBC/8000 a=fmtp:109 mode=30
Sollten beide Session-Teilnehmer sich nicht auf eine bestimmte Variante einigen können, wird die verwendet, welche am wenigsten Bandbreite benötigt. Dies wäre also mode=30.
Da die Implementation beider Varianten in einem VoIP-Client oder auch in einem VoIP-Server sich oft als schwierig erweist, wird auch oft nur mode=30 implementiert, und mode=20 wird ausgelassen.
Wie die iLBC-Blöcke mit RTP zu übertragen sind, ist eigens in RFC 3952[2] (Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech) beschrieben.
Ursprünglich war das Verfahren nur in der Gleitkommaversion lizenzgebührenfrei verfügbar. Für die auf Mikrocontrollern und Festkomma-DSPs notwendige Version in Festkommaarithmetik mussten an Global IP Solutions Lizenzkosten bezahlt werden.[3] Infolge der Akquise von GIPS durch Google Inc. steht das Verfahren lizenzkostenfrei zur unbegrenzten Nutzung für jedermann zur Verfügung. Die Referenzimplementierung wird als Freie Software unter den Bedingungen einer BSD-artigen Lizenz verbreitet.[4]
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.