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

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

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

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


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

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

 

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

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


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

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

 

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


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

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

 

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

 

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

 

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

 

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

 

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


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

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...