Jump to content

    
Sign in to follow this  
Kluwer

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

Recommended Posts

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

Share this post


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

 

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
Спасибо за ответ! Но вопрос ещё такой, а как быть, если пакет либо вообще не пришёл, либо очень сильно запоздал.

 

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

 

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

 

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

 

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this