[winipuh 0]

Поясню вопрос на примере VoIP:

- источник — АЦП;

- приемник — ЦАП.

Из-за неидентичности тактовых генераторов, задающих частоту дискретизации АЦП и ЦАП, получаем проблему синхронизации — возникающий с течением времени переизбыток или недостаток данных на приемной стороне.

 

В "родных" технологиях передачи (E1/T1, ТВ радиовещание) это никакая и не проблема, все нативно :) Но вот интересно, как эта проблема решается в случае передачи медиаданных через IP-сети?

 

Есть предположение, что "кошерная" подстройка частоты местного генератора не используется (на программных IP-телефонах для PC, полагаю, это вообще невозможно), а проблема решается контролируемыми "слипами" (периодическим дублированием или удалением аудио отсчета или видеокадра) или каким-то более интеллектуальным алгоритмом - интерполяцией (или каким-нибудь другим умным словом).

 

Но это только домыслы. А хочется правды! :)

 

 

[=SSN= 0]

RTP

[winipuh 0]

RTP

И что? :)

Я так тоже могу - TDMoIP ;)

 

С RTP/RTCP немного знаком, rfc читал.

Вопрос был задан не про это. :)

 

[denyslb 0]

В каждом RTP пакете обычно есть временная метка. Плюс применяется буферизация, на случай джиттера в канале передачи данных.

[sigmaN 0]

В каждом RTP пакете обычно есть временная метка. Плюс применяется буферизация, на случай джиттера в канале передачи данных.

а метку эту по своим часикам передатчик выставляет ) А на приёмнике часики при этом быстрее бегут. Да и вообще, на сколько я понимаю, метка там в основном для того, чтобы понять стоит ли вообще воспроизводить этот пакет или он уже сильно опоздал, был пропущен и воспроизводится уже следующий фрейм.

 

А ведь и действительно же если часы на разных сторонах тикают с разной скоростью - никакой буфер не поможет. Рано или поздно он либо опустошится, либо будет переполнен. Вопрос лишь в длительности сеанса связи...

Например если Speex не получил очередной фрейм(20ms) он просто тупо проигрывает предыдущий ещё разок-другой, чтобы максимально замять эту ситуацию. Но это всё так... ерунда, работает в случае потери отдельных пакетовв. Если приёмник будет выгребать буфер быстрее, чем передатчик его заполняет - беды не миновать.

 

Так что я, можно сказать, присоединяюсь к вопросу ТС )

[petrov 6]

Если приёмник будет выгребать буфер быстрее, чем передатчик его заполняет - беды не миновать.

 

Можно использовать указатель буфера FIFO для управления по обратной связи частотой считывания из буфера и интерполяцией сигнала под местный клок.

 

[igorle 0]

Но это только домыслы. А хочется правды! :)

если часы в приемнике медленнее - по мере переполнения буфера пакет-другой выбрасывается.

Если часы в приемнике быстрее - то при опустошении буффера звук/картинка останавливается для буфферизации. Поскольку часы относительно точные - проблемы возникают не часто.

 

[DASM 0]

На хардовых МПЕГ декодерах используется подстройка PLL задающего 27 Мгц генератор по меткам PCR входящего потока. Что касается конференция, то с учетом лага и размера буферов, и принимая во внимание, допустим 50 ppm разбег - эта не та проблема, о которой вообще стоит думать

[igorle 0]

Можно использовать указатель буфера FIFO для управления по обратной связи частотой считывания из буфера и интерполяцией сигнала под местный клок.

для осуществления обратной связи используется протокол RTCP

[DASM 0]

для осуществления обратной связи используется протокол RTCP

Какое отношение эта связь имеет к тактовой подстройке ?

[Quasar 18]

Во-первых, в VoIP часто используется silence suppression и тишину генерит CNG, генерит он её уже локально, по своим клокам. А поскольку тишина в разговоре двух человек в обе стороны случается часто, то моменты тишины выравнивают заполненность буфера.

Во-вторых, конечно же часы достаточно точно сейчас ходят у всех. Даже если и случается пропадание звука из-за переполнения буфера или опустошения, то не часто.

[petrov 6]

Во-вторых, конечно же часы достаточно точно сейчас ходят у всех. Даже если и случается пропадание звука из-за переполнения буфера или опустошения, то не часто.

 

Есть там подстройка либо по меткам времени либо по указателю буфера, переполнение или опустошение ненормальная ситуация.

 

[Quasar 18]

Есть там подстройка либо по меткам времени либо по указателю буфера, переполнение или опустошение ненормальная ситуация.

 

Где там? Подстройка чего? PLL процессора, кварца ЦАП'а или АЦП? Я не видел в VoIP движках что бы по RTP timestamp'у подстраивали железо. Автор темы озвучил простую проблему, АЦП оцифровывает с частотой 8000 Гц, а ЦАП воспроизводит с частотой 7999 Гц (или 8001 Гц), то есть за два часа заполнится (опустошится) секундный буфер. И что вы тут собрались подстраивать?

 

[Fujitser 0]

Просто либо будут выброшены лишние пакеты при переполнении буфера приема, либо возникнет кратковременная пауза при опустошении буфера.

[petrov 6]

Где там? Подстройка чего? PLL процессора, кварца ЦАП'а или АЦП? Я не видел в VoIP движках что бы по RTP timestamp'у подстраивали железо. Автор темы озвучил простую проблему, АЦП оцифровывает с частотой 8000 Гц, а ЦАП воспроизводит с частотой 7999 Гц (или 8001 Гц), то есть за два часа заполнится (опустошится) секундный буфер. И что вы тут собрались подстраивать?

 

В таких задачах. Необязательно подстраивать железо, можно интерполировать сигнал. IPTV трансляция в прямом эфире, заполняем секундный буфер, пусть через час он опустошается, картинка замирает, звук отрубается, ждём секунду заполнения, кому нужен такой дерьмовый сервис? Когда можно подстраивать местный NCO по меткам времени и им управлять интерполятором, для видео пропускать/повторять кадр, для аудио честная интерполяция.