CC BY
35
УДК 654.02
А.Б.МАХОВИКОВ, канд. техн. наук, доцент, telum@inbox. ru Санкт-Петербургский государственный горный университет, К.В.СТОЛЯРОВ, канд. техн. наук, [email protected], А.В.СТРЕЛЬНИКОВА, astrelnikova@bradontechnologies. com, М.А.ЧЕРНОВ, mchernov@bradontechnologies. com Брэйдан Технолоджис Лтд., Канада
A.B.MAKHOVIKOV, PhD in eng. sc., associate professor, telum@inbox. ru Saint Petersburg State Mining University,
K.V.STOLYAROV, PhD in eng. sc., kstolyarov@bradontechnologies. com, A.V.STRELNIKOVA, astrelnikova@bradontechnologies. com, M.A.CHERNOV, mchernov@bradontechnologies. com Bradon Technologies Ltd., Canada
МЕТОДЫ РЕШЕНИЯ НЕКОТОРЫХ ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ РАЗРАБОТКЕ СИСТЕМ ИНТЕРНЕТ-КОНФЕРЕНЦИЙ
Рассмотрены некоторые проблемы, возникающие при создании систем интернет-конференций. Описаны методы решения этих проблем, разработанные для системы SAVii.
Ключевые слова: интернет-конференции, синхронизация потоков данных, кодирование аудиоданных, проблема firewall, проблема плохого канала связи.
METHODS OF SOLUTION OF SOME PROBLEMS ARISING DURING DEVELOPMENT OF INTERNET-CONFERENCING SYSTEMS
Some problems which arise during development of Internet-conferencing systems are considered. Methods of their solution which has been developed for SAVii system are described.
Key words. Internet-conferencing, data streams synchronization, audio coding, firewall problem, bad channel problem.
В работе [1] была описана общая структура и принципы работы разработанной нами в 2004-2009 годах системы для организации интернет-конференций, получившей название SAVii (Synchronized Audio Video Interactivity through Internet). В данной работе хотелось бы остановиться на описании некоторых проблем, возникших при создании системы, и разработанных нами методов их решения.
Проблема 1. Синхронизация разнородных данных. При разработке систем интернет-конференций возникает задача синхронного
воспроизведения разнородных данных: речи ведущего конференции, его видео-изображения, изображения с его рабочего стола и т.п. Для решения данной задачи было предложено множество различных способов. Во-первых, многие стараются передать все данные в одном потоке, создавая жесткую синхронизацию между разнородными данными. Однако в случае плохого канала связи при таком способе передачи возникают серьезные проблемы, связанные с прерываниями потока данных. Эти прерывания тем сильнее, чем больший объем данных передается в единицу времени.
Следовательно, наличие объемных данных, не требующих строгой непрерывности (например, изображения с рабочего стола), оказывает негативное влияние на передачу данных, которые ее требуют и занимают малый объем в потоке (например, речи). Другой, более правильный способ состоит в передаче разнородных данных в различных потоках. В этом случае организуется синхронизация между потоками данных, которая реализуется, как правило, с помощью временных меток. Классическим примером данного способа синхронизации является использование протокола RTP (Real-time Transport Protocol). Однако на транспортном уровне, к которому относится данный протокол, отсутствует информация о физическом смысле передаваемых данных, следовательно, данные, требующие непрерывности (речь), могут быть приторможены до прихода данных, ее не требующих (изображение с рабочего стола).
Проанализировав известные способы синхронизации, мы пришли к идее «естественной» синхронизации данных. В соответствии с этой идеей, каждый поток данных мы стараемся передавать и воспроизводить в реальном масштабе времени. Опоздавшие данные выбрасываются. Запрос на передачу потерянных и искаженных данных не производится. Соответственно, все полученные данные воспроизводятся синхронно. Многолетняя успешная эксплуатация системы SAVii подтвердила правильность нашей идеи.
Проблема 2. Сжатие аудиоданных для передачи по каналу с потерями. В 1999-2002 годах в рамках проекта «Mediapage Technology» [2] нами были разработаны единственные на тот момент низкоскоростные «окнонезависимые» аудиокодеки на 2400, 4800, 9600 и 19200 bps. Свойство «ок-нонезависимости» позволяло использовать их в каналах связи с потерями без принятия дополнительных мер по защите данных, например FEC (Forward Error Correction). Именно эти кодеки и нашли применение в системе SAVii.
Рассмотрим кратко алгоритмы работы наших кодеков.
Кодек на 2400 bps. Записанный речевой сигнал (8 кГц, 16 бит), разделенный на окна
по 180 мс, пропускается через фильтры Бат-терворта 3-го порядка верхних и нижних частот с частотами среза 100 и 3900 Гц соответственно. Отфильтрованное окно разделяется на 8 подокон по 22,5 мс. Каждое подокно с помощью низкочастотных, полосовых и высокочастотных фильтров Баттерворта 6-го порядка разделяется на пять частотных диапазонов {0-500, 500-1000, 1000-2000, 2000-3000, 3000-4000}. Для первых четырех диапазонов вычисляется признак тон/шум. Если первые два диапазона признаны тоновыми, то по ним вычисляется частота основного тона. Также для каждого диапазона вычисляется коэффициент усиления. Дополнительно для всего подокна вычисляется коэффициент дрожания и коэффициенты линейного предсказания, которые конвертируются в линейные спектральные пары. Указанные параметры упаковываются в битовый буфер и передаются на удаленную сторону. На удаленной стороне на основе частоты основного тона, коэффициента дрожания, коэффициентов усиления и признаков тон/шум создается сигнал возбуждения. После интерполяции этот сигнал подается на синтезирующий фильтр на основе коэффициентов линейного предсказания, полученных из линейных спектральных пар. На выходе этого фильтра получается восстановленный речевой сигнал.
Кодек на 4800 bps. Обработанный так же, как и в кодеке на 2400 bps, сигнал разделяется на 6 подокон по 30 мс. Для каждого подокна вычисляются коэффициенты линейного предсказания, которые преобразуются в линейные спектральные пары, пригодные для передачи на удаленную сторону. Затем исходный сигнал пропускается через обратный фильтр, построенный на базе коэффициентов линейного предсказания. Полученный на выходе этого фильтра сигнал разделяется на две части. По первой части (180 отсчетов) вычисляются параметры инициализации адаптивной кодовой книги. По второй части (1260 отсчетов) вычисляются параметры для генерации адаптивной и алгебраической кодовых книг. Указанные параметры упаковываются в битовый буфер и передаются на удаленную сторону. На удаленной стороне с помощью параметров
для адаптивной и алгебраической кодовых книг синтезируется сигнал возбуждения. Этот сигнал пропускается через фильтр, построенный на базе коэффициентов линейного предсказания. На выходе этого фильтра получается синтезированный речевой сигнал.
Кодек на 9600 bps. Этот кодек в целом подобен кодеку на 4800 bps, но в нем не используется алгебраическая кодовая книга. Вместо нее вычисляются амплитуды и положения импульсов, подстановка которых в сигнал возбуждения приводит к минимизации отклонения синтезированного сигнала от исходного. Алгоритм вычисления этой последовательности импульсов является нашим «ноу-хау». Использование этой последовательности импульсов позволяет существенно увеличить качество синтезированной речи.
Кодек на 19200 bps. Алгоритм работы этого кодека полностью идентичен алгоритму работы кодека на 9600 bps. Большая скорость кодека позволяет увеличить количество оптимальных импульсов, а следовательно, еще и повысить качество синтезированной речи.
Вычислительные затраты линейки наших кодеков в MIPS (Million Instructions Per Second) представлены в таблице. Из таблицы видно, что вычислительные затраты незначительны, особенно в декодере. Это означает, что наши кодеки целесообразно использовать в системах интернет-конференций, где предполагается параллельное декодирование множества конкурентных потоков.
Вычислительные затраты кодеков
Кодек Энкодер, MIPS Декодер, MIPS
2400 bps 8 3
4800 bps 6 < 1
9600 bps 8 < 1
19200 bps 10 < 1
В настоящее время кроме линейки наших «окнонезависимых» кодеков существует другой низкоскоростной «окнонезависи-мый» кодек, получивший название iLBC (internet Low Bitrate Codec). Этот кодек имеет две скорости: 13330 bps при окне 30 мс и 15200 bps при окне 20 мс. В сравнении с на-
шими кодеками на 9600 и 19200 bps, iLBC обеспечивает сходное качество декодированной речи, но характеризуется существенно большими вычислительными затратами на кодирование и декодирование речевого сигнала. Дополнительным преимуществом наших кодеков является значительно большее, чем в iLBC окно (180 мс против 30 или 20 мс), что позволяет существенно сократить накладные расходы на передачу данных по Интернет. Так, например, если использовать для передачи данных протокол UDP (User Datagram Protocol), то для iLBC на 15200 bps результирующий поток будет 26300 bps, т.е. служебная информация в потоке данных составляет 42,2 %. А для нашего кодека на 19200 bps имеем 20300 bps, т.е. всего 5,4 %.
О высоком качестве разработанного нами кодека свидетельствует тот факт, что в 2009 году он стал победителем в номинации «Инновационная технология, способствующая развитию унифицированных коммуникаций» по версии TMC Labs [3].
В последнее время, в связи с улучшением каналов связи, наметился интерес к так называемым широкополосным речевым кодекам, в которых производится кодирование сигнала, записанного не на 8, а на 16 кГц. Увеличение частоты дискретизации приводит к существенному увеличению разборчивости и натуральности речи. Уходит так называемое «телефонное» качество. Классическим представителем этой группы кодеков является SILK, который используется в системе SKYPE. В 2010 году нами был разработан собственный широкополосный кодек, который при потоке 50 kbps обеспечивает отличное качество восстановленной речи при экстремально-малых вычислительных затратах (энкодер -0,5 MIPS, декодер - 0,2 MIPS). Мы планируем включить данный кодек в следующую версию системы SAVii.
Проблема 3. Работа в корпоративных сетях. Применение систем для организации интернет-конференций в корпоративном секторе обычно сталкивается с практически неразрешимой проблемой, связанной с изменением настроек корпоративного шлюза с целью разрешения не-
популярного у сетевых администраторов протокола UDP. Именно на этом протоколе базируются как стандартные (например, RTP), так и специальные (как в системе SAVii) протоколы передачи данных в реальном времени. В корпоративных же сетях, как правило, разрешены только протокол TCP (Transmission Control Protocol) и базирующийся на нем прикладной протокол HTTP (HyperText Transfer Protocol), причем передача данных осуществляется только через кэширующий HTTP-прокси. В этой связи перед нами встала проблема: как организовать передачу данных в реальном времени с помощью протокола, который для этого не предназначен? Мы предложили следующее решение.
Для передачи каждого типа данных устанавливается свое TCP-соединение и с помощью методов POST и GET протокола HTTP организуется передача данных. В случае плохого канала связи при использовании протокола TCP происходит быстрый рост задержки доставки данных за счет их накопления и повторной пересылки и, соответственно, потеря реального времени. С целью ликвидации данного эффекта с некоторой периодичностью (в системе SAVii - 10 с) происходит создание нового TCP-соединения, по которому и продолжается передача данных. Данные, которые не были переданы по старому соединению, выбрасываются.
Данный метод может быть использован и при наличии корпоративного HTTP-прокси. В этом случае необходимо в заголовках запросов и ответов указывать на запрещение кэширования информации. Кроме протокола HTTP можно использовать также HTTPS.
Опыт эксплуатации системы SAVii показал работоспособность предложенного метода. Реальное качество связи, конечно, резко падает с ухудшением качества канала связи (резче, чем при использовании протоколов, базирующихся на UDP), но внешние каналы связи в корпоративном секторе, как правило, имеют хорошее качество.
Проблема 4. Передача данных по плохим каналам связи. В противоположность
корпоративному сектору, в частном секторе практически отсутствуют проблемы с блокировкой протокола UDP, но часто присутствует проблема качества канала связи. Естественно, что если канал связи совсем плох, то ни о каком общении в реальном времени говорить не приходится. Однако пользователи, имеющие такие каналы связи, должны иметь возможность загружать и просматривать архивы конференций.
В отличие от «живой» конференции, просмотр архива не требует передачи данных в реальном времени и, на первый взгляд, может быть реализован с помощью протокола TCP. Однако передача данных по этому протоколу резко ухудшается с ухудшением канала связи. Вызвано это принципиальной недоработкой протокола TCP, заключающейся в том, что в подтверждение о доставке пакета посылается только номер следующего ожидаемого пакета. Таким образом, если, например, пакет номер 5 потерялся, а остальные пакеты - нет, то все они будут повторно пересланы, так как информации об их успешной доставке у передающей стороны нет.
Чтобы устранить указанный недостаток и уменьшить бесполезную пересылку информации по и так плохому каналу связи, нами был разработан собственный протокол гарантированной доставки данных, основанный на протоколе UDP. Суть его состоит в том, что на каждый принятый пакет посылается подтверждение, содержащее информацию о 8 предыдущих пакетах. Если пакет доставлен, то для него устанавливается флаг 1, а если нет - 0. Передающая сторона анализирует данную информацию и пересылает только недоставленные пакеты.
Тестирование данного протокола передачи данных показало, что, по сравнению с протоколом TCP, обеспечиваемая им реальная скорость доставки данных существенно медленнее снижается с ухудшением канала связи.
Таким образом, мы рассмотрели некоторые проблемы, которые возникли при разработке системы интернет-конференций SAVii, и предложенные нами методы их решения. Успешное решение этих и некото-
рых других проблем позволило создать систему, которая два года подряд (в 2008 и 2009 годах) входила в список победителей в номинации «Лучший продукт года для унифицированных телекоммуникаций» по версии TMC Labs [4, 5].
ЛИТЕРАТУРА
1. Маховиков А.Б. Применение систем интернет-конференций как способ повышения эффективности управления горным производством // Записки Горного института / СПГГУ. СПб., 2011. Т.191. С. 262-266.
2. Lutz M. Mediapage Technology - New Technology for Interactive Internet Show / M.Lutz, M.Vange, I.Sinclair, A.Machovikov, O.Barbashov, M.Chernoff, N.Romashov, A.Skobelev, K.Stolyarov, D.Yushmanov // SCI 2002: Proceedings of «The 6th World Multiconference on Systemics, Cybernetics And Informatics». Orlando, Florida, U.S.A., 2002.
3. 2009 Unified Communications TMC Labs Innovation Award Winners. http://news.tmcnet.com/news/2009/05/ 21/4191731.htm.
4. 2008 Unified Communications Product of the Year Award Winners. http://www.tmcnet.com/news/2009/03/ 12/4051798.htm.
5. 2009 Unified Communications Product of the Year Award Winners.- http://unified-communications.tmcnet com/topics/umfied-commumcations/articles/81558-tmcs-uni fied-communications-magazine-announces-2009-product-the.htm
REFERENCES
1. Makhovikov A.B. Internet conferences systems applying as a method of mining works administration efficiency promotion // The Proceedings of the Mining Institute. Saint Petersburg: SPb SMU, 2011. Vol.191. P. 262-266.
2. Lutz M. Mediapage Technology - New Technology for Interactive Internet Show / M.Lutz, M.Vange, LSinclair, A.Machovikov, O.Barbashov, M.Chernoff, N.Romashov, A.Skobelev, K.Stolyarov, D.Yushmanov // SCI 2002: Proceedings of «The 6th World Multiconference on Systemics, Cybernetics And Informatics». Orlando, Florida, U.S.A., 2002.
3. 2009 Unified Communications TMC Labs Innovation Award Winners. http://news.tmcnet.com/news/2009/ 05/21/4191731.htm
4. 2008 Unified Communications Product of the Year Award Winners. http://www.tmcnet.com/news/2009/ 03/12/4051798.htm
5. 2009 Unified Communications Product of the Year Award Winners. http://unified-communications.tmcnet.com/ topics/unified-communications/articles/81558-tmcs-unified-communications-magazine-announces-2009-product-the.htm
