G.726 - G.726

G.726
40, 32, 24, 16 kbit / s Adaptivní diferenciální pulzní kódová modulace (ADPCM)
Pcm.svg
Postavení V platnosti
Rok začal 1990
Nejnovější verze (05/06)
Květen 2006
Organizace ITU-T
Základní standardy G.721
Doména audio komprese
Licence Volně dostupné
webová stránka https://www.itu.int/rec/T-REC-G.726

G.726 je standard ITU-T ADPCM řečového kodeku pokrývající přenos hlasu rychlostí 16, 24, 32 a 40  kbit / s. Bylo představeno, aby nahradilo G.721, který pokrýval ADPCM při 32 kbit / s, a G.723 , který popisoval ADPCM pro 24 a 40 kbit / s. G.726 také představil novou rychlost 16 kbit / s. Čtyři bitové rychlosti spojené s G.726 jsou často označovány bitovou velikostí vzorku , což jsou 2, 3, 4 a 5 bitů. Odpovídající širokopásmový kodek založený na stejné technologii je G.722 .

Nejčastěji používaný režim je 32 kbit / s, což zdvojnásobuje využitelnou kapacitu sítě pomocí poloviční rychlosti G.711 . Používá se především na mezinárodní kmenech v telefonní síti , což představuje standardní kodek použitý v DECT bezdrátových telefonních systémů. Hlavní aplikace kanálů 24 a 16 kbit / s je pro kanály přetížení přenášející hlas v digitálním obvodovém multiplikačním zařízení (DCME). Hlavní aplikací kanálů 40 kbit / s je přenášet signály datových modemů v DCME, zejména u modemů pracujících rychlostí vyšší než 4800 bit / s.

Dějiny

G.721 byl představen v roce 1984, zatímco G.723 byl představen v roce 1988. V roce 1990 byly složeny do G.726.

G.727 byl představen současně s G.726 a obsahuje stejné přenosové rychlosti, ale je optimalizován pro prostředí PCME ( packet circuit multiplex equipment ). Toho je dosaženo vložením 2bitového kvantizátoru do 3bitového kvantizátoru a to samého pro vyšší režimy. To umožňuje vypuštění nejméně významného bitu z bitového proudu bez nepříznivých účinků na řečový signál.

Funkce

  • Vzorkovací frekvence 8 kHz
  • K dispozici jsou přenosové rychlosti 16 kbit / s, 24 kbit / s, 32 kbit / s, 40 kbit / s
  • Generuje bitový tok , proto je délka rámce určena dobou paketizace (obvykle 80 vzorků pro velikost rámce 10  ms )
  • Typické algoritmické zpoždění je 0,125 ms bez zpoždění do budoucna
  • G.726 je kodér řeči vln, který využívá adaptivní diferenciální pulzní kódovou modulaci ( ADPCM )
  • Testování PSQM za ideálních podmínek přináší průměrné skóre mínění 4,30 pro G.726 (32 kbit / s), ve srovnání s 4,45 pro G.711 ( μ-zákon )
  • Testování PSQM pod stresem v síti přináší průměrné skóre názorů 3,79 pro G.726 (32 kbit / s), ve srovnání s 4,13 pro G.711 (μ-zákon)
  • 40 kbit / s G.726 může přenášet 12000 bit / s a ​​pomalejší signály modemu, zatímco 32 kbit / s G.726 může přenášet dobře 2400 bit / s a ​​pomalejší signály modemu a 4800 bit / s s větší degradací než kodeky s čistým kanálem .

Endianness a typ užitečného zatížení

Vzhledem k tomu, že pořadí bajtů pro datové protokoly v kontextu internetu bylo obecně definováno jako big endian a nazývá se jednoduše pořadí bajtů v síti , jak uvádí (mimo jiné) zastaralý RFC 1700, zastaralý RFC 1890 výslovně nedefinoval endiannost předchůdce G.726, G.721, buď v RTP. Namísto toho bylo v zastaralém RFC 1890 pro všechny zmíněné kodeky opět obecně uvedeno použití big endian výrazem network byte order order:

"U kódování s více oktety se oktety přenášejí v pořadí bajtů v síti (tj. Nejdříve nejvýznamnější oktet)."
- IETF, zastaralý RFC 1890, oddíl 4.2

Typ užitečného zatížení pro G.721 byl definován zastaralým RFC 1890 jako 2 , tedy a=rtpmap:2 G721/8000. V konceptech pro novější verzi tohoto RFC byl znovu použit pro G.726, tzn a=rtpmap:2 G726-32/8000.

Oproti tomu ITU výslovně definovala pořadí bajtů ve svých doporučeních týkajících se G.726, respektive ADPCM, ale dvěma různými způsoby. Doporučení X.420 stanoví, že by měl být malý endian, při respektování doporučení I.366.2, příloha E , by měl být velký endian. To vedlo k rozporuplným rozhodnutím v různých implementacích, protože někteří výrobci se rozhodli pro malý endian a jiní pro velký endian. Důsledkem bylo, že tyto implementace byly nekompatibilní, protože dekódování pomocí nesprávného pořadí bytů má za následek silně zkreslený zvukový signál. Proto byla nejasná definice stanovena v RFC 3551, který nahrazuje RFC 1890. Část 4.5.4 v RFC 3551 definuje klasické MIME typy G726-16, 24, 32 a 40 jako malý endian a zavádí nové MIME typy pro bis endian, což jsou AAL2-G726-16, 24, 32 a 40. Typ užitečného zatížení byl změněn na dynamický, aby nedošlo k záměně. Místo užitečného zatížení typu 2 se použije dynamické užitečné zatížení v rozsahu od 96 do 127:

„Všimněte si, že směr„ malého endianu “, ve kterém jsou vzorky baleny do oktetů ve zde specifikovaných formátech užitečného zatížení G726-16, -24, -32 a -40, je v souladu s doporučením ITU-T X.420, ale je opačný toho, co je uvedeno v doporučení ITU-T I.366.2 Příloha E pro transport ATM AAL2. Druhá sada formátů RTP užitečných dat odpovídajících paketizaci I.366.2 Příloha E a identifikovaná MIME podtypy AAL2-G726-16, -24, - 32 a -40 budou specifikovány v samostatném dokumentu. “
- IETF, RFC 3551, oddíl 4.5.4

„Payload type 2 was assigned to G721 in RFC 1890 and to its ekvivalent nástupce G726-32 in draft versions of this specification, but its use is now deprecated and that static payload type is checked dedicated due to conflict conflict use for the payload Format G726- 32 a AAL2-G726-32 (viz oddíl 4.5.4) "
- IETF, RFC 3551, oddíl 6

malý endian
(X.420 a RFC 3551)		 big endian
(I.366.2 příloha E a RFC 3551)		 zastaralé RFC 1890
G726-16 a=rtpmap:{from 96 to 127} G726-16/8000 AAL2-G726-16 a=rtpmap:{from 96 to 127} AAL2-G726-16/8000 a=rtpmap:2 G726-16/8000
G726-24 a=rtpmap:{from 96 to 127} G726-24/8000 AAL2-G726-24 a=rtpmap:{from 96 to 127} AAL2-G726-24/8000 a=rtpmap:2 G726-24/8000
G726-32 a=rtpmap:{from 96 to 127} G726-32/8000 AAL2-G726-32 a=rtpmap:{from 96 to 127} AAL2-G726-32/8000 a=rtpmap:2 G726-32/8000
G726-40 a=rtpmap:{from 96 to 127} G726-40/8000 AAL2-G726-40 a=rtpmap:{from 96 to 127} AAL2-G726-40/8000 a=rtpmap:2 G726-40/8000

Novější implementace respektují RFC 3551 a jasně se liší mezi G726-xx (malý endian) a AAL2-G726-xx (velký endian). Telefon Gigaset C610 IP DECT například generuje ve svém SIP INVITE následující kód:

a=rtpmap:96 G726-32/8000→ dynamické užitečné zatížení typu 96 a G.726 podle X.420, tedy malý endian, jak je definováno v RFC 3551
a=rtpmap:97 AAL2-G726-32/8000→ dynamické užitečné zatížení typu 97 a G.726 podle I.366.2 přílohy E, tedy velký endian, jak je definováno v RFC 3551
a=rtpmap:2 G726-32/8000 → statické užitečné zatížení typu 2 a G.726 s nepředvídatelnou endianitou, jako G.721 podle zastaralého RFC 1890

Viz také

externí odkazy