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 году. Они были свернуты в G.726 в 1990 году.

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 ( μ-закон ) ^{[ необходима ссылка ]}
• Тестирование PSQM при нагрузке на сеть дает средние оценки мнения 3,79 для G.726 (32 кбит / с) по сравнению с 4,13 для G.711 (μ-закон)
• 40 кбит / с G.726 может передавать 12000 бит / с и более медленные сигналы модема, в то время как 32 кбит / с G.726 может передавать 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 как little endian и вводит новые типы MIME для bis endian, которыми являются AAL2-G726-16, 24, 32 и 40. Тип полезной нагрузки был изменен на динамический, в во избежание путаницы. Вместо полезной нагрузки типа 2 следует использовать динамическую полезную нагрузку в диапазоне от 96 до 127:

«Обратите внимание, что направление« little-endian », в котором выборки упаковываются в октеты в указанных здесь форматах полезной нагрузки G726-16, -24, -32 и -40, согласуется с Рекомендацией ITU-T X.420, но является противоположным. того, что указано в Приложении E Рекомендации МСЭ-Т I.366.2 для транспортировки ATM AAL2. Второй набор форматов полезной нагрузки 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

Новые реализации соответствуют 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 в соответствии с I.366.2 Приложение E, таким образом, с прямым порядком байтов, как определено в RFC 3551
a=rtpmap:2 G726-32/8000 → статический тип полезной нагрузки 2 и G.726 с непредсказуемым порядком байтов, например G.721 в соответствии с устаревшим RFC 1890

См. Также [ править ]

• Список кодеков
• Сравнение форматов кодирования аудио

Внешние ссылки [ править ]

• Страница ITU-T G.726
• Программные средства ITU-T G.191 для кодирования речи и звука, включая код G.726 C
• RFC 3551 - профиль RTP для аудио- и видеоконференций с минимальным контролем, G726-40, G726-32, G726-24 и G726-16