internet low bit rate codec
| Internet Low Bit Rate Codec (iLBC) | |
|---|---|
| File extension : |
.lbc
|
| MIME type : | audio / iLBC |
| Magic number : | '#! iLBC30 \ n' or '#! iLBC20 \ n' |
| Developed by: | Global IP Solutions |
| Current version: | December 2004 |
| Type: | Voice codec |
| Standard (s) : | RFC 3951 |
| Website : |
( Page no longer available , search in web archives: webrtc.org ) historical: http://ilbcfreeware.org/ |
The internet Low Bitrate Codec ( iLBC ) is an openly documented, royalty-free speech codec that was developed by Global IP Solutions (GIPS). It stands out from older codecs in particular in that it was specially designed for packet-switched data networks such as the Internet and therefore copes very well with packet loss and jitter . iLBC is therefore particularly suitable for VoIP .
properties
The iLBC codec specified in RFC 3951 is a narrowband codec, i.e. it records frequencies up to 4000 Hz. The standard defines a variant with a block length of 30 ms and one with a block length of 20 ms at a sampling rate of 8 kHz and a sampling depth of 16 bits.
Block-independent linear predictive coding
The innovation behind iLBC is the block-independent linear predictive coding algorithm with a controlled response to packet loss . Block independence means that each block is coded completely independently of the previous ones and therefore no information from the previous blocks is required in order to decode the following blocks correctly. This was not the case with the previously published compressed speech codecs, which leads to errors as a result of packet loss in packet-based data networks, e.g. B. the Internet, continue over the following blocks. With the G.729 codec this leads to B. to dull, explosive noises on the receiving end. The cause of this technical deficiency is that these codecs were intended for the traditional digital telephone network, which is based on virtual connections , in which there was no provision at all for blocks to be lost. This is why these codecs have only been designed to be robust against bit errors. However, packet-switched data networks also react completely differently to bit errors than virtual connections in circuit-switched networks, since the individual packets receive checksums and are simply discarded and, if necessary, retransmitted if a bit error is detected. With the advent of VoIP, there was therefore a need to create a codec that would meet these new technical requirements.
In addition, iLBC offers a packet loss concealment , such as the ITU -T G.711 standard , which is based on pulse code modulation (PCM) and works with a fixed bit rate of 64 kbit / s. A substitute signal is generated for the missing part of the audio signal, which is calculated from the surrounding blocks.
Due to these properties, the iLBC codec enables relatively good voice quality, even if data blocks are missing due to lost or delayed IP packets.
Modes
iLBC 30
With iLBC 30, each block comprises an audio signal of 30 ms or 240 samples, which are encoded in 399 data bits plus 1 empty bit. This corresponds to 50 octets or bytes per block.
| net | Gross RTP with IPv4 | Gross RTP with IPv6 | |
|---|---|---|---|
| Data rate in kbit / s | 13.33 | 24 | 29.33 |
It is the older of the two variants of iLBC.
iLBC 20
With iLBC 20, each block comprises an audio signal of 20 ms or 160 samples, which are encoded in 303 data bits plus 1 blank bit. This corresponds to 38 octets or bytes per block.
| net | Gross RTP with IPv4 | Gross RTP with IPv6 | |
|---|---|---|---|
| Data rate in kbit / s | 15.2 | 31.2 | 39.2 |
The developers of iLBC characterize the iLBC 20, which is younger than the iLBC 30, as follows:
"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."
"Compared to the 30 ms block length mode, this 15.2 kb / s mode has the following properties: higher basic quality, greater robustness against packet loss, lower complexity and less algorithmic delay."
RTP signaling of the modes
The typical protocol for the transmission of data streams in the Internet is RTP . Among other things, it is used for VoIP with SIP. In order to negotiate over the entire transmission path which data formats are available or permitted by the call participants and on the servers, the individual points report this in the SIP header data area as an SDP offer . If iLBC 20 is preferred, this SDP offer looks like this :
a=rtpmap:109 iLBC/8000 a=fmtp:109 mode=20
If iLBC 30 is preferred, mode = 30 applies :
a=rtpmap:109 iLBC/8000 a=fmtp:109 mode=30
If both session participants cannot agree on a certain variant, the one that requires the least bandwidth is used. So this would be mode = 30 .
Since the implementation of both variants in a VoIP client or also in a VoIP server often proves to be difficult, only mode = 30 is often implemented and mode = 20 is omitted.
How the iLBC blocks are to be transmitted with RTP is specifically described in RFC 3952 ( Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech ).
License
Originally, the process was only available in the floating point version free of license fees . For the version in fixed point arithmetic required on microcontrollers and fixed point DSPs, license costs had to be paid to Global IP Solutions. As a result of the acquisition of GIPS by Google Inc. , the process is available to everyone free of license fees for unlimited use. The reference implementation is distributed as free software under the terms of a BSD-like license .
Compared to G.729A
- Basic quality higher than G.729A , higher robustness against packet loss
- Computational complexity comparable to G.729A
- In contrast to G.729a free license, use free of charge
See also
Web links
- historical website (English)
Individual evidence
- ↑ ( Page no longer available , search in web archives: license and product information on iLBC )
- ↑ ( page no longer available , search in web archives: webrtc.org )