Г.726
| Адаптивная дифференциально-импульсно-кодовая модуляция 40, 32, 24, 16 кбит/с (ADPCM) | |
 | |
| Статус | Действующий |
|---|---|
| Год начался | 1990 |
| Последняя версия | (05/06) май 2006 г. |
| Организация | МСЭ-Т |
| Базовые стандарты | G.721 |
| Домен | сжатие звука |
| Лицензия | Свободно доступен |
| Веб-сайт | https://www.itu.int/rec/T-REC-G.726 |
G.726 — это ITU-T ADPCM, стандарт речевого кодека обеспечивающий передачу голоса со скоростью 16, 24, 32 и 40 кбит /с. Он был введен для замены G.721, который охватывает ADPCM со скоростью 32 кбит/с, и G.723 , который описывает ADPCM для 24 и 40 кбит/с. G.726 также представил новую скорость 16 кбит/с. Четыре скорости передачи данных , связанные с G.726, часто обозначаются битовым размером выборки , который составляет 2, 3, 4 и 5 бит соответственно. Соответствующий широкополосный кодек, основанный на той же технологии, — G.722 .
Наиболее часто используемый режим — 32 кбит/с, который удваивает полезную пропускную способность сети за счет использования половины скорости G.711 . Он в основном используется на международных соединительных линиях в телефонной сети и является стандартным кодеком, используемым в DECT беспроводных телефонных системах . Основное применение каналов 24 и 16 кбит/с — это перегрузка каналов передачи голоса в оборудовании цифрового умножения каналов (DCME). Основное применение каналов 40 кбит/с — передача сигналов модема данных в DCME, особенно для модемов, работающих со скоростью более 4800 бит/с.
История [ править ]
G.721 был представлен в 1984 году, а G.723 - в 1988 году. В 1990 году они были объединены в G.726.
G.727 был представлен одновременно с G.726 и включает те же скорости передачи данных, но оптимизирован для среды оборудования пакетного мультиплексирования (PCME). Это достигается путем встраивания 2-битного квантователя в 3-битный квантователь, и то же самое для более высоких режимов. Это позволяет исключить младший бит из потока битов без негативного воздействия на речевой сигнал.
Особенности [ править ]
- Частота дискретизации 8 кГц
- Доступны скорости передачи данных 16 кбит/с, 24 кбит/с, 32 кбит/с, 40 кбит/с.
- Генерирует битовый поток , поэтому длина кадра определяется временем пакетирования (обычно 80 выборок для 10 мс ). размера кадра
- Типичная алгоритмическая задержка составляет 0,125 мс, без упреждающей задержки.
- G.726 — это кодер речи, использующий адаптивную дифференциально-импульсно-кодовую модуляцию ( ADPCM ).
- Тестирование PSQM в идеальных условиях дает средний балл 4,30 для G.726 (32 кбит/с) по сравнению с 4,45 для G.711 ( μ-law ). [ нужна ссылка ]
- Тестирование PSQM в условиях сетевой нагрузки дает средний балл 3,79 для G.726 (32 кбит/с) по сравнению с 4,13 для G.711 (μ-закон)
- G.726 со скоростью 40 кбит/с может передавать сигналы модема со скоростью 12000 бит/с и более медленные, тогда как G.726 со скоростью 32 кбит/с может хорошо передавать сигналы модема со скоростью 2400 бит/с и более медленные, а скорость 4800 бит/с с некоторым большим ухудшением, чем кодеки чистого канала. .
Порядок байтов и тип полезной нагрузки [ править ]
Поскольку порядок байтов для протоколов данных в контексте Интернета обычно определялся как обратный порядок байтов и назывался просто сетевым порядком байтов , как указано (среди прочего) в устаревшем RFC 1700, устаревший RFC 1890 явно не определял порядок байтов. предшественник G.726, G.721, либо в RTP. Вместо этого в устаревшем RFC 1890 для всех упомянутых кодеков снова было указано использование обратного порядка байтов в термине «сетевой порядок байтов»:
«Для многооктетных кодировок октеты передаются в сетевом порядке байтов (т. е. сначала наиболее значимый октет)».
— IETF, устаревший RFC 1890, раздел 4.2.
Тип полезной нагрузки для G.721 был определен устаревшим RFC 1890 как 2 , таким образом a=rtpmap:2 G721/8000. В черновиках новой версии этого RFC он повторно использовался для G.726, т.е. a=rtpmap:2 G726-32/8000.
В отличие от этого ITU явно определил порядок байтов в своих рекомендациях относительно G.726 или, соответственно, ADPCM, но двумя разными способами. В Рекомендации X.420 указано, что порядок байтов должен быть прямым, а в соответствии с рекомендацией I.366.2 Приложения E он должен иметь порядок байтов. Это привело к противоречивым решениям в различных реализациях, поскольку некоторые производители выбрали прямой порядок байтов, а другие — прямой порядок байтов. В результате эти реализации оказались несовместимы, поскольку декодирование с использованием неправильного порядка байтов приводит к сильному искажению аудиосигнала. Поэтому нечеткое определение было исправлено в RFC 3551, который заменяет RFC 1890. Раздел 4.5.4 в RFC 3551 определяет классические MIME-типы G726-16, 24, 32 и 40 как с прямым порядком байтов и вводит новые типы MIME для двухпорядкового байта, это AAL2-G726-16, 24, 32 и 40. Тип полезной нагрузки был изменен на динамический, чтобы избежать путаницы. Вместо типа полезной нагрузки 2 должна использоваться динамическая полезная нагрузка в диапазоне от 96 до 127:
«Обратите внимание, что указанное здесь направление с прямым порядком байтов, в котором выборки упаковываются в октеты в форматах полезной нагрузки G726-16, -24, -32 и -40, соответствует Рекомендации ITU-T X.420, но является противоположным того, что указано в Приложении E Рекомендации ITU-T I.366.2 для транспорта AAL2 ATM. Второй набор форматов полезной нагрузки RTP, соответствующий пакетизации Приложения E I.366.2 и идентифицируемый подтипами MIME AAL2-G726-16, -24, -. 32 и -40 будут указаны в отдельном документе».
— IETF, RFC 3551, раздел 4.5.4.
«Тип полезной нагрузки 2 был назначен G721 в RFC 1890 и его эквивалентному преемнику G726-32 в черновых версиях этой спецификации, но его использование теперь устарело, и этот статический тип полезной нагрузки помечен как зарезервированный из-за конфликтного использования форматов полезной нагрузки G726- 32 и AAL2-G726-32 (см. раздел 4.5.4)"
— IETF, RFC 3551, раздел 6.
| с прямым порядком байтов (X.420 и RFC 3551) | с прямым порядком байтов (I.366.2 Приложение E и RFC 3551) | устаревший RFC 1890 |
|---|---|---|
Г726-16 a=rtpmap:{from 96 to 127} G726-16/8000 | ААЛ2-G726-16 a=rtpmap:{from 96 to 127} AAL2-G726-16/8000 | a=rtpmap:2 G726-16/8000 |
Г726-24 a=rtpmap:{from 96 to 127} G726-24/8000 | ААЛ2-G726-24 a=rtpmap:{from 96 to 127} AAL2-G726-24/8000 | a=rtpmap:2 G726-24/8000 |
Г726-32 a=rtpmap:{from 96 to 127} G726-32/8000 | ААЛ2-G726-32 a=rtpmap:{from 96 to 127} AAL2-G726-32/8000 | a=rtpmap:2 G726-32/8000 |
Г726-40 a=rtpmap:{from 96 to 127} G726-40/8000 | ААЛ2-G726-40 a=rtpmap:{from 96 to 127} AAL2-G726-40/8000 | a=rtpmap:2 G726-40/8000 |
Новые реализации соответствуют RFC 3551 и четко различают G726-xx (с прямым порядком байтов) и AAL2-G726-xx (с прямым порядком байтов). Например, телефон Gigaset C610 IP DECT генерирует в своем SIP INVITE следующий код:
a=rtpmap:96 G726-32/8000 → тип динамической полезной нагрузки 96 и G.726 в соответствии с X.420, то есть с прямым порядком байтов, как определено в RFC 3551. a=rtpmap:97 AAL2-G726-32/8000 → тип динамической полезной нагрузки 97 и G.726 в соответствии с Приложением E I.366.2, то есть с прямым порядком байтов, как определено в RFC 3551. a=rtpmap:2 G726-32/8000 → статическая полезная нагрузка типа 2 и G.726 с непредсказуемым порядком байтов, например G.721 в соответствии с устаревшим RFC 1890.