Перейти к содержанию

    

Алгоритмы для борьбы с "джиттером" в VoIP

Коллеги! А не подскажет кто простые алгроитмы борьбы с т.н. "джиттером" при пакетной передачи голоса. Везде пишут про буферы длиной аж в 1-2 сек. Но, если идёт двусторонняя связь и на стороне удалённого абонента не достаточно эффективно давится эхо, то с задержкой больше где-то 500мс говорить становится не возможно. Нужны алгоритмы, не требующие такой задержки, но не дающие, с одной стороны "щелчков" при запаздывании/пропадании очередного пакета, а, с другой стороны, не накапливающие задержку из-за разбегания кварцев.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Коллеги! А не подскажет кто простые алгроитмы борьбы с т.н. "джиттером" при пакетной передачи голоса. Везде пишут про буферы длиной аж в 1-2 сек. Но, если идёт двусторонняя связь и на стороне удалённого абонента не достаточно эффективно давится эхо, то с задержкой больше где-то 500мс говорить становится не возможно. Нужны алгоритмы, не требующие такой задержки, но не дающие, с одной стороны "щелчков" при запаздывании/пропадании очередного пакета, а, с другой стороны, не накапливающие задержку из-за разбегания кварцев.

 

На самом деле подавление эха где-то до 150 ms задержки нормально работает. Большие задержки нужны чтобы с тем, что пакеты на источник приходят не в том порядке, в каком были посланы бороться (reordering). А с джиттером адаптивными методами борются - адаптивно подстраивают глубину буфера под трафик, оценивая параметры распределения количества пакетов в буфере. Правда, сначала свой "кварц" подтягивают под среднюю скорость поступления отсчетов из сети (ну или еще как компенсируют расхождение тактовых частот приемника и передатчика - можно повторять-вырезать кусочки сигнала, можно ресамплинг с управляемым коэффициентом передискретизации), а уже потом минимизируют глубину jitter buffer. Эти технологии в TDMoverIP используются. Там и можно почитать. Если всё это в своей сети предполагается использовать, то jitter можно заранее наперед оценить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо за ответ! Но вопрос ещё такой, а как быть, если пакет либо вообще не пришёл, либо очень сильно запоздал. Либо, кстати, что делать, если вообще пакеты перестали поступать. Если ничего не делать, что в звуковом потоке слышны отчётливые и неприятные для слуха "щелчки". Вот как их грамотно "замаскировать"?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Спасибо за ответ! Но вопрос ещё такой, а как быть, если пакет либо вообще не пришёл, либо очень сильно запоздал.

 

У меня было фактически скользящее окно sequence numbers, которые мы принимаем в данный момент. Пакеты с номерами вне окна просто отбрасываются. Размер окна определяется допустимой задержкой.

 

Либо, кстати, что делать, если вообще пакеты перестали поступать. Если ничего не делать, что в звуковом потоке слышны отчётливые и неприятные для слуха "щелчки". Вот как их грамотно "замаскировать"?

 

Я просто предыдущий пакет повторял чтобы меньше хрюкало. У меня по 48 8 kHz отсчетов в пакете передавалось (пакеты по 48 байт 64 kbps аудио с логарифмической компрессией).

 

Если потеряно несколько пакетов - начинал подавать нули на выход. Полезно вести счетчики отброшенных по seq number пакетов - если их становится все больше, то это знак того, что надо увеличить буффер.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация