winipuh 0 17 июня, 2013 Опубликовано 17 июня, 2013 · Жалоба Поясню вопрос на примере VoIP: - источник — АЦП; - приемник — ЦАП. Из-за неидентичности тактовых генераторов, задающих частоту дискретизации АЦП и ЦАП, получаем проблему синхронизации — возникающий с течением времени переизбыток или недостаток данных на приемной стороне. В "родных" технологиях передачи (E1/T1, ТВ радиовещание) это никакая и не проблема, все нативно :) Но вот интересно, как эта проблема решается в случае передачи медиаданных через IP-сети? Есть предположение, что "кошерная" подстройка частоты местного генератора не используется (на программных IP-телефонах для PC, полагаю, это вообще невозможно), а проблема решается контролируемыми "слипами" (периодическим дублированием или удалением аудио отсчета или видеокадра) или каким-то более интеллектуальным алгоритмом - интерполяцией (или каким-нибудь другим умным словом). Но это только домыслы. А хочется правды! :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=SSN= 0 17 июня, 2013 Опубликовано 17 июня, 2013 · Жалоба RTP Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
winipuh 0 17 июня, 2013 Опубликовано 17 июня, 2013 · Жалоба RTP И что? :) Я так тоже могу - TDMoIP ;) С RTP/RTCP немного знаком, rfc читал. Вопрос был задан не про это. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
denyslb 0 15 июля, 2013 Опубликовано 15 июля, 2013 · Жалоба В каждом RTP пакете обычно есть временная метка. Плюс применяется буферизация, на случай джиттера в канале передачи данных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 25 июля, 2013 Опубликовано 25 июля, 2013 · Жалоба В каждом RTP пакете обычно есть временная метка. Плюс применяется буферизация, на случай джиттера в канале передачи данных. а метку эту по своим часикам передатчик выставляет ) А на приёмнике часики при этом быстрее бегут. Да и вообще, на сколько я понимаю, метка там в основном для того, чтобы понять стоит ли вообще воспроизводить этот пакет или он уже сильно опоздал, был пропущен и воспроизводится уже следующий фрейм. А ведь и действительно же если часы на разных сторонах тикают с разной скоростью - никакой буфер не поможет. Рано или поздно он либо опустошится, либо будет переполнен. Вопрос лишь в длительности сеанса связи... Например если Speex не получил очередной фрейм(20ms) он просто тупо проигрывает предыдущий ещё разок-другой, чтобы максимально замять эту ситуацию. Но это всё так... ерунда, работает в случае потери отдельных пакетовв. Если приёмник будет выгребать буфер быстрее, чем передатчик его заполняет - беды не миновать. Так что я, можно сказать, присоединяюсь к вопросу ТС ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 6 26 июля, 2013 Опубликовано 26 июля, 2013 · Жалоба Если приёмник будет выгребать буфер быстрее, чем передатчик его заполняет - беды не миновать. Можно использовать указатель буфера FIFO для управления по обратной связи частотой считывания из буфера и интерполяцией сигнала под местный клок. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
igorle 0 26 июля, 2013 Опубликовано 26 июля, 2013 · Жалоба Но это только домыслы. А хочется правды! :) если часы в приемнике медленнее - по мере переполнения буфера пакет-другой выбрасывается. Если часы в приемнике быстрее - то при опустошении буффера звук/картинка останавливается для буфферизации. Поскольку часы относительно точные - проблемы возникают не часто. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 26 июля, 2013 Опубликовано 26 июля, 2013 · Жалоба На хардовых МПЕГ декодерах используется подстройка PLL задающего 27 Мгц генератор по меткам PCR входящего потока. Что касается конференция, то с учетом лага и размера буферов, и принимая во внимание, допустим 50 ppm разбег - эта не та проблема, о которой вообще стоит думать Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
igorle 0 26 июля, 2013 Опубликовано 26 июля, 2013 · Жалоба Можно использовать указатель буфера FIFO для управления по обратной связи частотой считывания из буфера и интерполяцией сигнала под местный клок. для осуществления обратной связи используется протокол RTCP Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 26 июля, 2013 Опубликовано 26 июля, 2013 · Жалоба для осуществления обратной связи используется протокол RTCP Какое отношение эта связь имеет к тактовой подстройке ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Quasar 18 31 июля, 2013 Опубликовано 31 июля, 2013 · Жалоба Во-первых, в VoIP часто используется silence suppression и тишину генерит CNG, генерит он её уже локально, по своим клокам. А поскольку тишина в разговоре двух человек в обе стороны случается часто, то моменты тишины выравнивают заполненность буфера. Во-вторых, конечно же часы достаточно точно сейчас ходят у всех. Даже если и случается пропадание звука из-за переполнения буфера или опустошения, то не часто. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 6 31 июля, 2013 Опубликовано 31 июля, 2013 · Жалоба Во-вторых, конечно же часы достаточно точно сейчас ходят у всех. Даже если и случается пропадание звука из-за переполнения буфера или опустошения, то не часто. Есть там подстройка либо по меткам времени либо по указателю буфера, переполнение или опустошение ненормальная ситуация. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Quasar 18 31 июля, 2013 Опубликовано 31 июля, 2013 · Жалоба Есть там подстройка либо по меткам времени либо по указателю буфера, переполнение или опустошение ненормальная ситуация. Где там? Подстройка чего? PLL процессора, кварца ЦАП'а или АЦП? Я не видел в VoIP движках что бы по RTP timestamp'у подстраивали железо. Автор темы озвучил простую проблему, АЦП оцифровывает с частотой 8000 Гц, а ЦАП воспроизводит с частотой 7999 Гц (или 8001 Гц), то есть за два часа заполнится (опустошится) секундный буфер. И что вы тут собрались подстраивать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Fujitser 0 31 июля, 2013 Опубликовано 31 июля, 2013 · Жалоба Просто либо будут выброшены лишние пакеты при переполнении буфера приема, либо возникнет кратковременная пауза при опустошении буфера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
petrov 6 31 июля, 2013 Опубликовано 31 июля, 2013 · Жалоба Где там? Подстройка чего? PLL процессора, кварца ЦАП'а или АЦП? Я не видел в VoIP движках что бы по RTP timestamp'у подстраивали железо. Автор темы озвучил простую проблему, АЦП оцифровывает с частотой 8000 Гц, а ЦАП воспроизводит с частотой 7999 Гц (или 8001 Гц), то есть за два часа заполнится (опустошится) секундный буфер. И что вы тут собрались подстраивать? В таких задачах. Необязательно подстраивать железо, можно интерполировать сигнал. IPTV трансляция в прямом эфире, заполняем секундный буфер, пусть через час он опустошается, картинка замирает, звук отрубается, ждём секунду заполнения, кому нужен такой дерьмовый сервис? Когда можно подстраивать местный NCO по меткам времени и им управлять интерполятором, для видео пропускать/повторять кадр, для аудио честная интерполяция. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться