Интеллектуальный способ, система и узел ограничения аудио

Интеллектуальный способ, система и узел ограничения аудио

Иллюстрации

Показать все

Реферат

Перекрестная ссылка на связанные заявки

Настоящая заявка относится к одновременно поданным предварительным заявкам на патент США № 60/814476 "Conference Layout Control and Control Protocol" авторов Richard E. Huber и Arun Punj, имеющей номер в реестре поверенного FORE-120; №60/814491 "Associating Independent Multimedia Sources Into a Conference Call", авторов Arun Punj, Richard E. Huber и Gregory H. Smith, имеющей номер в реестре поверенного FORE-121, обе из которых включены в настоящее описание по ссылке.

Область техники

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

Предшествующий уровень техники

При участии в большой конференц-связи сумма всех возможных каналов аудио может превысить ресурсы центрального процессора и сети. Использование VAD (обнаружение речевой активности) является стандартным способом статистически сохранить количество одновременных потоков аудио ограниченным. Однако имеются моменты времени, когда большое количество участников может генерировать аудиоответ, который может заставить почти все узлы начать осуществлять передачу.

Максимальное число участников конференции для большой конференции представляет проблему обработки аудио, не имеющей место при 15-сторонней конференции. Предположим, что конференция со 100 сторонами была скоординирована, но все удаленные стороны не были подавлены (заглушены) и таким образом способны передавать аудио в любое время. Основная говорящая сторона делает комментарий, на который каждый отвечает и в течение довольно короткого промежутка времени 100-300 мс каждый ViPr терминал начинает посылать данные аудио, таким образом создавая "аудиошторм пакетов". Результатом воздействия такого шторма на конференцию может быть увеличение принятого уровня шума, и все сигналы испытывают скачок, равный 20 дБ на выходе аудио. Терминал обрабатывает 5000 аудио RTP-пакетов (пакетов протокола реального времени) в секунду. Любая линия связи с малой полосой частот, подсоединяющая ViPr терминал к остальной части конференции, должна была бы состязаться с потоком данных аудио 8 Мбит/с. (Примечание: число 8 Мбит/с получено из того, что каждый терминал ViPr передает со скоростью 64 кбит/с для данных аудио, 4,8 кбит/с для служебных RTP, и служебные сигналы IP приблизительно 4 кбит/с). Настоящее изобретение описывает как обнаружить, что конференция входит в это состояние перегрузки, и как управлять тем, какие отправители должны прекратить посылать. Настоящее изобретение обеспечивает механизм ограничения эффектов от слишком большого количества одновременных потоков аудио.

Краткая сущность изобретения

Настоящее изобретение относится к системе организации телеконференций. Система содержит сеть. Система содержит множество узлов, обменивающихся друг с другом через сеть аудиопотоками, которые узлы передают друг другу, чтобы сформировать конференцию. Каждый узел способен обнаруживать состояние перегрузки, когда имеются более чем заранее определенное количество одновременных потоков аудио, передаваемых узлами, и вместе с другими узлами управлять количеством потоков аудио, передаваемых одновременно, чтобы завершить (прервать) состояние перегрузки.

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

Настоящее изобретение относится к узлу организации телеконференции для сети с другими узлами. Узел содержит сетевой интерфейс, который обменивается с другими узлами, чтобы сформировать конференцию. Узел содержит контроллер, который обнаруживает состояние перегрузки, при котором имеются более заранее определенного количества одновременных потоков аудио, передаваемых узлами, и вместе с другими узлами управляет количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

Краткое описание чертежей

На сопроводительных чертежах иллюстрируются предпочтительный вариант осуществления изобретения и предпочтительные способы осуществления изобретения, на которых:

Фиг.1 изображает схематическое представление системы для настоящего изобретения.

Фиг.2 изображает схематическое представление сети для настоящего изобретения.

Фиг.3 изображает схематическое представление видеофона, связанного с персональным компьютером и сетью.

Фиг.4 изображает схематическое представление системы для настоящего изобретения.

Фиг.5a и 5b изображают схематические представления видеофона на видах спереди и сбоку.

Фиг.6 изображает схематическое представление панели соединений видеофона.

Фиг.7 изображает схематическое представление многоэкранной конфигурации для видеофона.

Фиг.8 изображает блок-схему видеофона.

Фиг.9 изображает блок-схему архитектуры видеофона.

Фиг.10 изображает схематическое представление системы.

Фиг.11 изображает схематическое представление системы.

Фиг.12 изображает схематическое представление системы согласно настоящему изобретению.

Фиг.13 изображает схематическое представление другой системы согласно настоящему изобретению.

Фиг.14 изображает схематическое представление смесителя аудио согласно настоящему изобретению.

Фиг.15 изображает блок-схему архитектуры для смесителя.

Фиг.16 изображает блок-схему SBU.

Фиг.17 изображает схематическое представление UAM видеофона в конференции видеофона.

Фиг.18 изображает схематическое представление UAM видеофона при двухстороннем телефонном вызове.

Фиг.19 изображает схематическое представление сети для смесителя.

Фиг.20 изображает блок-схему настоящего изобретения.

Подробное описание изобретения

Обращаясь к чертежам, на которых аналогичные цифровые обозначения относятся к подобным или идентичным частям на нескольких представлениях (видах), и более конкретно к фиг.20, заметим, что на ней показана система 10 организации телеконференций. Система 10 содержит сеть 40. Система 10 содержит множество узлов, таких как терминалы или видеофоны, обменивающихся друг с другом через сеть 40 аудио потоками реального разговора, которые терминалы передают друг другу, чтобы сформировать конференцию. Каждый терминал способен обнаруживать состояние перегрузки, при которой имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых терминалами, и вместе с другими терминалами управлять количеством потоков аудио, передаваемых одновременно, чтобы завершить (прервать) состояние перегрузки.

Предпочтительно, каждый терминал определяет, должен ли он прекратить передавать свой поток аудио, когда обнаружено состояние перегрузки, на основании потока аудио, который он передает, и потоков аудио, передаваемых другими терминалами. Каждый терминал предпочтительно приходит к одному и тому же решению независимо от других терминалов относительно состояния перегрузки без каких-либо сообщений синхронизации от сети 40.

Настоящее изобретение относится к способу, обеспечивающему конференц-связь (телеконференцию). Способ содержит этапы, на которых множество терминалов обмениваются друг с другом через сеть 40 потоками аудио реального (живого) разговора, которые терминалы передают друг другу, чтобы сформировать конференцию. Имеется этап обнаружения каждым терминалом состояния перегрузки, при котором имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых терминалами. Имеется этап управления количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

Предпочтительно, этап управления включает в себя этап управления количеством потоков аудио, передаваемых одновременно, и состояния перегрузки каждым из терминалов. Этап управления предпочтительно включает в себя этап, на котором каждый терминал определяет, должен ли он прекратить передавать свой поток аудио, когда состояние перегрузки обнаружено, на основании потока аудио, который он передает, и потоков аудио, передаваемых другими терминалами. Предпочтительно, этап управления включает в себя этап, на котором каждый терминал приходит к одному и тому же решению независимо от терминалов, имеющих отношение к состоянию перегрузки, без каких-либо сообщений синхронизации от сети 40.

Способ предпочтительно включает в себя этап разрешения узлам, имеющим наиболее недавно переданные потоки аудио разговора, продолжать передавать их потоки аудио. Предпочтительно, этап разрешения включает в себя этап оценки каждого узла, при этом узлы, имеющие самое большое значение оценки, продолжают передачу. Этап оценки предпочтительно включает в себя этап использования подсчета пакетов аудио для каждой стороны за прошлые 60 секунд, чтобы определить оценку.

Настоящее изобретение относится к узлу 12 организации телеконференций для сети 40 с другими узлами. Узел содержит интерфейс сети 40, который обменивается с другими узлами, чтобы сформировать конференцию реального (живого) разговора. Узел содержит контроллер 19, который обнаруживает состояние перегрузки, при котором имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых терминалами, и вместе с другими терминалами управляет количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки. Предпочтительно, узел включает в себя приемник 58 аудио, чтобы принять разговор, и устройство изображения, чтобы захватывать живые изображения в узлах, и динамики 64, чтобы воспроизводить потоки аудио, принятые от других узлов.

При работе в предпочтительном варианте осуществления максимальное число участников конференции для большой конференции "в живую" представляет проблему обработки аудио, не имеющую места в конференции с 15 сторонами. Предположим, что конференция с 100 сторонами была скоординирована, но все удаленные стороны не были подавлены (приглушены) и таким образом они способны передавать аудио в любое время. Основная говорящая сторона 64 делает комментарий, на который каждый отвечает, и в течение довольно короткого промежутка времени 100-300 мс каждая оконечная точка начинает посылать данные аудио, таким образом создавая "аудио шторм пакетов". Результатом влияния такого шторма на конференцию может быть увеличение принятого уровня шума, и все сигналы испытывают скачок, равный 20 дБ на выходе аудио. Оконечная точка обрабатывает 5000 RTP (протокол реального времени) пакетов аудио в секунду. Любая линия связи с малой полосой частот, подсоединяющая ViPr терминал к остальной части конференции, должна была бы состязаться с потоком данных аудио, равным 8 Мбит/с. (Примечание: число 8 Мбит/с получено из того, что каждая оконечная точка передает со скоростью 64 кбит/с для данных аудио, 4,8 кбит/с для служебных RTP, и IP служебных (пакетов) приблизительно 4 кбит/с).

При обнаружении сравнивают частоту принятых пакетов аудио с порогом. Каждая оконечная точка независимо определяет, присутствует ли шторм и должна ли она продолжать посылать данные аудио или выполнить глушение самой себя. Общий поток, который оконечная точка совместно использует, является таким, что каждая оконечная точка может оценивать статистику активности разговора других оконечных точек, так как они будут принимать аудио данные друг друга.

Исходя из моделирования, можно ожидать, что число передаваемых каналов аудио превышает предел в течение короткого времени, обычно менее чем 300 мс. Причина этого заключается в том, что имеется задержка в сети 40, которая будет влиять, когда любая оконечная точка сможет обнаружить шторм. Если задержка равна 50 мс, то до трех пакетов может быть на маршруте прежде, чем оконечная точка обнаружит шторм. Аналогично, каждая оконечная точка должна решить, должна ли она сама выполнить глушение самой себя. При типичных вариациях в статистике из-за различий в моменте времени, когда каждая оконечная точка обнаруживает шторм и решает, как смягчить его, будет большее или меньшее количество молчащих оконечных точек, чем ожидаемых. Некоторые будут заглушены немного позже, если недостаточно оконечных точек замолкают, чтобы подавить шторм. В этом процессе имеется случайность, вызванная различными временами, когда оконечные точки выполняют обнаружение шторма и процесс подавления, так же как и случайность канала или дрожание (флуктуация).

Шторм обнаружен (или объявлен), когда количество принятых пакетов аудио в данном интервале времени превышает порог обнаружения.

Обнаружение аудиошторма и подавление

Режим самоконсервации

Цель состоит в том, чтобы предотвратить запирание ViPr терминала аудиоштормом, так как процесс аудио имеет наивысший приоритет. Вызывается только если Режим Защиты Качества Аудио не является активным и послано чрезмерное число пакетов аудио. Этот режим также предотвращает атаки типа "отказ в обслуживании".

Входящие пакеты подсчитываются в течение относительно малого периода времени (100-200 мс), и если порог превышен, тогда любые последующие принятые пакеты отбрасываются в течение этого периода времени.

Режим Защиты Качества Аудио

Цель состоит в том, чтобы ограничить посылку пакетов аудио, чтобы предотвратить перегрузку сети 40 и предотвратить чрезмерный шум и громкость аудио в каждом из удаленных терминалов.

1. Все терминалы собирают статистику обо всех аудиопотоках, включая локальный терминал.

2. Все терминалы независимо обнаруживают возникновение аудиошторма, отслеживая количество входящих каналов, которые активно посылают данные.

3. Каждый терминал независимо решает, прекратить или нет посылать свой поток аудио на основании своей оценки своей локальной передачи аудио и таковой от удаленных терминалов.

Ключевые особенности, которые являются новыми относительно обнаружения и подавления аудио шторма ViPr.

Каждый терминал полностью автономен от других терминалов в решении посылать ли данные аудио.

Тем, что связывает процессы принятия решения всех терминалов вместе, является то, что все терминалы вычисляют приблизительно одинаковую статистику для каждого канала.

Ниже следует в основном описание того, как построить устройство для "Обнаружения Аудио Шторма и Восстановления".

Каждая сторона в конференц-связи (конференц-вызове) посылает пакеты аудио реального разговора через регулярные интервалы времени ко всем другим сторонам в вызове. Первичным способом ограничить сеть 40 и загрузку процессора для каждой стороны является прекращение посылки этих пакетов аудио в течение периодов тишины. В типичном вызове только несколько сторон будут говорить одновременно, а все другие стороны будут находиться в режиме "молчания". Так, каждая сторона будет только активно принимать пакеты от других немногих сторон. Когда новая сторона отвечает на вопрос, логика Обнаружения Активности Аудио будет разрешать передачу пакетов аудио от этой оконечной точки. Аналогично, когда сторона прекращает говорить, логика Обнаружения Активности Аудио будет снова активизировать режим "молчания", чтобы остановить поток пакетов.

Всякий раз, когда возникает ситуация, которая создает большой одновременный аудиоответ, каждая сторона начнет передавать пакеты, так как она выходит из режима "молчания". Когда много потоков аудио активны в одно и то же время, функция смешивания аудио, применяемая в каждой оконечной точке, более интенсивно использует процессор. Имеется также существенное увеличение загрузки сети 40. Это является состоянием, которое называется "Аудиошторм", и нижеследующее описание подробно описывает решение, чтобы обнаруживать и остановить аудио штормы.

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

Начальное обнаружение аудиошторма является относительно простым. Аудиошторм просто объявляется всякий раз, когда сторона активно принимает данные аудио от по меньшей мере числа сторон, равного "nStormThreshold". Жесткая (аппаратная) часть решает, как управлять этим штормом. Идеальная ситуация заключается в том, чтобы иметь одну(и) и ту(е) же сторону или стороны, которые говорили перед штормом, все еще остающимися слышимыми. Каждая также должна все еще быть способна слышать множество дополнительных сторон так, чтобы они также могли слышать ее реакцию.

История предыдущих пакетов аудио, приходящих от каждой стороны, используется для создания "оценки", которая затем будет решать, какие стороны были самыми последними говорящими сторонами (абонентами). Количество "NsimultaneousTalkers" сторон вверху списка может быть затем использовано, чтобы решить, какие являются немногими выбранными для продолжения передачи после того, как был обнаружен аудиошторм. Так как все оконечные точки сохраняют точную одну и ту же историю пакетов аудио, они должны всегда иметь точный один и тот же список оценок. Если конкретная оконечная точка находится вверху списка, то она должна продолжить передачу; иначе, она должна немедленно прекратить передавать. Другое использование этого списка заключается в том чтобы ограничить, которые стороны декодируются и смешиваются для воспроизведения аудио. Эффекты аудиошторма будут ослабевать и только немногие стороны, находящиеся наверху списка, будут продолжать передавать и будут услышаны.

Последняя оставшаяся вещь состоит в том, чтобы ожидать, пока аудиошторм не завершится, чтобы возобновить нормальную работу конференции. Так как будет иметься точное количество "nSimultaneousTalkers" сторон, передающих изначально, то необходимо ожидать, чтобы было меньше, чем количество "nStormEndThreshold1" сторон, передающих перед объявлением того, что аудиошторм закончился.

Типичный алгоритм оценки должен использовать подсчет пакетов аудио для каждой стороны в течение последних 60 секунд. Этот подсчет затем увеличивается на 100 для каждого предшествующего интервала в 500 миллисекунд, когда по меньшей мере один пакет также был принят от этой стороны. Это продолжается для каждой стороны в обратную сторону за 60-секундную историю до (обнаружения) первого интервала в 500 миллисекунд, не содержащего никаких пакетов. Этот способ оценки благоприятствует тому, чтобы самые недавние говорящие стороны были первыми, а затем - стороны, которые сказали что-нибудь за последние 60 секунд.

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

Предложенное решение аудиошторма предполагает, что терминалы должны действовать независимо, чтобы обнаруживать и смягчить шторм (всплеск появления) пакетов аудио. При обнаружении сравнивают частоту принятых пакетов аудио с порогом. Каждый терминал независимо определяет, присутствует ли шторм, и должен ли он продолжать посылать данные аудио или выполнить глушение самого себя. Общий подход, который терминалы ViPr используют совместно, состоит в том, что каждый терминал может оценивать статистику активности разговора других терминалов, так как они будут принимать данные аудио друг друга.

Исходя из моделирования, можно ожидать, что число переданных каналов аудио превысит предел в течение короткого времени, обычно менее чем 300 мс. Причина этого заключается в том, что имеется задержка сети 40, которая будет оказывать влияние, когда любой терминал может обнаружить шторм. Если задержка равна 50 мс, то в маршруте может быть до трех пакетов, прежде чем терминал обнаружит шторм. Также каждый терминал должен решить, выполнить ли глушение самого себя. Учитывая типичные изменения в статистике из-за различий во времени, когда каждый терминал обнаруживает шторм и решает, как его подавить, будет или большее или меньшее количество подавленных терминалов, чем ожидается. Некоторые будут подавлять (глушить) передачу немного позже, если недостаточное количество терминалов молчат, чтобы подавить шторм. В этом процессе имеется случайность, вызванная различными временами, когда терминалы выполняют процесс обнаружения и подавления шторма, а также случайные события или флуктуации канала.

Хронология шторма пакетов аудио

Имеет место большая конференция с более чем 50 участниками. Один или два участника активно говорят, и остальные находятся в режиме прослушивания. Произносится забавное предложение и внезапно более 50 участников начинают смеяться. В каждом ViPr терминале алгоритм VAD (обнаружения речевой активности) начинает обнаруживать увеличение в уровне аудио микрофона, и если это продолжается в течение 60 мс, тогда посылается пачка из 4 или 5 пакетов, и пакеты тогда посылаются в интервалах по 20 мс. Терминалы, которые принимают эту пачку, будут использовать ее для предварительной загрузки буфера смещения во времени (флуктуаций) и начинать воспроизводить принятое аудио. Как только смех спадает, VAD обнаруживает тишину и начнет двухсекундный отсчет обратно до отсечения пакетов.

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

Алгоритм передачи пакета

Пакеты передаются, если выполнены следующие условия:

VAD алгоритм обнаружил речь

И

в координируемой конференции и координатор не заглушил этого участника

ИЛИ

в некоординируемой конференции и нижеследующее является истинным:

шторм аудио пакетов не обнаружен

ИЛИ

шторм аудиопакетов обнаружен,

Участник является важной говорящей стороной

ИЛИ

Был послан ранг участника, основанный на сравнении последних данных аудио с последними данными аудио, принятыми от каждого из других участников.

Обнаружение шторма аудио пакетов

Шторм обнаруживается (или объявляется), когда количество принятых пакетов аудио в данном интервале времени превышает порог обнаружения. Алгоритм является следующим.

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

Каждые 100 мс

Если Аудио шторм не обнаружен, BStormDetected устанавливается равной "истина", если g_nPktsRcvd> m_nPktsStormDeclared

Если Аудио шторм обнаружен, BStormDetected устанавливается равной "ложь", если g_nPktsRcvd <m_nPktsStormOver

Установить g_nPktsRcvd равной 0.

Измерение активности говорящей стороны

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

Инициализировать циклический буфер TT_local всеми нулями и индекс (счетчик) indxTT равным 0.

Каждые две секунды и если шторм пакетов аудио не обнаружен, установить 1 в TT_local [indxTT], если локальный участник говорит или установить его в 0 в противном случае. Увеличить indxTT.

Количество единиц в массиве TT_local, разделенное на размер массива, представляет процентное соотношение от времени разговора. Интервал выборки, равный 2 секундам, основан на том, что VAD имеет минимальное время включения, равное 2 секундам. Размер массива TT_local установлен так, чтобы производить выборку последней минуты. Локальная говорящая сторона классифицируется как важная, если разговор был обнаружен в течение 25% последней минуты.

Второй способ измерения активности говорящей стороны использует последний момент, когда пакет был принят или передан. При рассмотрении происхождения шторма пакетов простое использование времени прибытия последнего пакета не будет выдавать полезные результаты. Более интересным является последний момент времени, когда пакет аудио был послан до начала текущего шторма пакетов аудио. Следующий алгоритм отслеживает это время прибытия пакетов.

Если PktRcvTime> PktRcvTimeLast + 1 секунда, то

Последний пакет принят до текущего шторма пакетов аудио и таким образом PktRcvTimeLast копируют в PktRcvTimeLast1.

PktRcvTimeLast = PktRcvTime.

Тот же самый алгоритм используется для передачи пакета аудио, но PktXmtTime заменяет PktRcvTime.

Реализация

В AudioMan вызывается функция SetTalkTimeLast() доступа, если EncoderRdy() возвращает результат "истина" в encoder_decoder_loop() в AudioMan.cpp. Состояние возврата EncoderRdy управляется посредством VAD. Находят SetXmtTimeLast() в AudioStorm.cpp.

Каждые 2 секунды вызывается UpdateTalkerActivity () в Encoder_decoder_loop в AudioMan.cpp. UpdateTalkerActivity() смотрит на состояние eVADstate говорящей стороны VAD, используя функцию IsTalking() доступа, чтобы определить, говорит ли локальный участник. Если разговор обнаружен, тогда "1" загружают в циклический буфер TT_local.

Для каждого принятого пакета вызывается функция SetRecTimeLast(iChannel). Время последнего принятого пакета для этого канала записывают, используя функцию SetRecTimeLast(iChannel) доступа, и увеличивают количество nPktsRcvStorm принятых пакетов для обнаружения шторма пакетов аудио.

Каждые 100 мс StormDetect() использует nPktRcvStorm, чтобы обнаружить, имеет ли место шторм пакетов. StormDetect() расположен вверху цикла while(1) в цикле encoder_decoder_loop(). Если шторм обнаружен, то StormDetect() будет вызывать функцию SetStormMute(истина) доступа VAD, если только локальный участник не является важной говорящей стороной или ранги являются достаточно высокими.

Алгоритм декодирования пакетов

AudioMan выполняется в ядре реального масштаба времени и если загружено больше чем 40 входящими потоками G.722, то будет занимать 100% процессорного времени. Сенсорная панель перестанет отвечать до тех пор, пока количество входящих пакетов аудио не станет меньше 40. (Значение 40 является грубым приближением). Эти значения возможны в большой конференции, если кто-то говорит что-то, на что реагирует большинство участников, например реакция на шутку. AudioMan подсчитывает количество принятых пакетов в течение указанного периода времени. Если подсчет пакетов превышает заданный порог, пакеты аудио, которые прибывают прежде, чем этот период истекает, просто отбрасываются. Количество отброшенных пакетов отслеживается посредством g_nPacketsPoliced, и если более чем нуль отображены в Help (Справка), то отображают экран Show Status (Показать состояние).

Как и во всем в AudioMan, параметрами настройки сервера являются

Audio_MaxReceivedPackets=70

Audio_MaxReceivedPacketsPeriod=40

В этом примере декодируются первые 70 принятых пакетов аудио, принятых в 40 мс период. Любые пакеты, принятые после 70-го, отбрасываются до того, как 40 мс период истечет, и затем процесс запускается снова.

Одной из ключевых "уникальных" особенностей относительно обработки аудиошторма является то, что каждый терминал приходит к "точно" такому же решению независимо "без" каких-либо дополнительных сообщений синхронизации. Это сделано возможным, так как все они принимают одни и те же потоки аудио и все они используют одни и те же правила подсчета оценок.

Следующие заявки включены в настоящее описание по ссылке:

Заявка на патент США № 10/114402 "Videophone And Method For A Video Call",

Заявка на патент США № 10/871852 "Audio Mixer And Method",

Заявка на патент США № 11/078193 "Method And Apparatus For Conferencing With Stream".

Узел может включать в себя элемент, сторону, терминал или участника конференции. Конференция обычно содержит по меньшей мере три узла и может иметь 10 или 20, или даже 50 или 100, или 150 или более узлов.

Количество участников	Общая пропускная способность (Кбит/с)	Пропускная способность с использованиемVAD (5 говорящих сторон)	Пропускная способность с использованиемVAD (25 говорящих сторон)	Пропускная способность с использованиемVAD (все говорящие стороны)	Пропускная способность с использованиемуправления аудиоштормом (все говорящие стороны)
10	640	320	640	640	640
25	1600	320	1600	6400	640
100	6400	320	1600	6400	640

Общая пропускная способность аудио НИКОГДА не должна превысить 1000 Кбит/с или видео может быть искажено.

Способ управления пропускной способностью аудиошторма ограничивает максимальное количество говорящих сторон 10-ю, чтобы предотвратить ухудшение видео и аудио.

Видеофон

Со ссылками на фиг.8, 9, 10 и 11 устройство 30 отображения, такое как обычная аналоговая камера 32, обеспечиваемая фирмой Sony с функцией S-видео, преобразовывает изображения сцены от устройства 30 отображения в электрические сигналы, которые посылаются по проводам к видео декодеру 34, такому как Philips SAA7114 NTSC/PAL/декодер. Видеодекодер 34 преобразовывает электрические сигналы в цифровые сигналы и выдает их как поток пикселей сцены, например, согласно формату BT 656. Поток пикселей выдается из видеодекодера 34 и разбивается на первый поток и второй поток, идентичный первому потоку. Кодер 36, предпочтительно кодер IBM eNV 420, принимает первый поток пикселей, обрабатывает первый поток и формирует поток данных в формате MPEG-2. Поток данных, произведенный видеокодером 36, сжимается примерно до размера 1/50 по сравнению с данными, которые были сформированы в камере. Поток MPEG-2 является кодированным цифровым потоком и не подвергается буферизации кадров до того, как впоследствии будет пакетирован для минимизации любой задержки. Кодированный MPEG-2 цифровой поток пакетируют с использованием RTP посредством программируемой пользователем вентильной матрицы (FPGA) 38 и программным обеспечением, к которому подается MPEG-2 поток, и передают на сеть 40, такую как Ethernet 802.p или ATM (асинхронной передачи данных) со скоростью 155 мегабит в секунду, используя сетевые интерфейсы интерфейс 42 - интерфейс 44 PLX 9054 PCI. Если требуется, поток видео, ассоциированный с видеомагнитофоном VCR или телевизионным показом, таким как CNN или кинофильм, может быть принят декодером 34 и выдан непосредственно на контроллер 52 дисплея для отображения. Контроллер 46 декодера, расположенный в FPGA 38 и соединенный с декодером 34, управляет работой декодера 34.

Альтернативно, если используется цифровая камера 47, результирующий поток, который сформирован камерой, уже представлен в цифровом формате и не должен быть выдан на декодер 34. Цифровой поток от цифровой камеры 47, который находится в формате BT 656, расщепляется на первый и второй потоки непосредственно от камеры, без прохождения через какой-либо видеодекодер 34.

В другом альтернативном варианте может использоваться камера 48 стандарта FireWire, такая как камера 48 с интерфейсом стандарта 1394 FireWire, чтобы выдавать цифровой сигнал непосредственно на FPGA 38. Камера 48 стандарта FireWire обеспечивает то преимущество, что если формирование потока данных должно иметь место на чуть большем, чем очень короткое расстояние от FPGA 38, то цифровые сигналы могут поддерживаться на этом более длинном расстоянии, например, посредством кабельного соединения от камеры 48 стандарта FireWire. FPGA 38 обеспечивает цифровой сигнал от камеры 48 стандарта FireWire к кодеру 36 для обработки, как описано выше, а также создает поток с низкой скоростью передачи кадров, как описано ниже.

Второй поток подается на FPGA 38, где FPGA 38 и программное обеспечение формируют поток с низкой скоростью передачи кадров, такой как поток JPEG движущихся изображений, который требует малой полосы частот по сравнению с первым потоком. FPGA 38 и основной контроллер 50 с программным обеспечением выполняют кодирование, сжатие и пакетирование в отношении этого потока с низкой скоростью передачи кадров и выдают его на PCI интерфейс 44, который, в свою очередь, передает его сетевому интерфейсу 42 через сетевую интерфейсную плату (СИП) 56 для передачи на сеть 40. Кодированный MPEG-2 цифровой поток и поток с низкой скоростью передачи кадров являются двумя по существу идентичными, но независимыми потоками данных, за исключением того, что поток данных с низкой скоростью передачи кадров масштабируется с уменьшением по сравнению с потоком данных MPEG-2, чтобы обеспечить меньшее представление той же самой сцены относительно потока MPEG-2 и требовать меньшее количество ресурсов сети 40.

По сети 40 каждый цифровой поток передают к требуемому видеофону 15 приемника или видеофонам 15 приемника, если в конференцию вовлечены более двух сторон. Данные маршрутизируют с использованием SIP. Сетевая интерфейсная плата 56 принимающего видеофона 15 принимает пакеты, ассоциированные с первым и вторым потоками данных, и выдает эти данные из пакетов и видеопотока (первого или второго), выбранные основным контроллером, к памяти приема. Основной контроллер 50 принимающего видеофона 15 с программным обеспечением декодирует и расширяет выбранный принятый поток данных и передает его контроллеру 52 дисплея. Контроллер 52 дисплея отображает воссозданные изображения на цифровом плоскопанельном дисплее стандарта VGA, используя стандартные аппаратные средства масштабирования. Пользователь в принимающем видеофоне 15 может выбирать, какой просматривать поток из этих двух потоков данных на сенсорном экране 74, или, если желательно, выбирает оба, и тогда и большое, и малое изображения сцены отображаются, хотя отображение обоих потоков из передающего видеофона 15 обычно не воспроизводится нормально. Описание протоколов для отображения описано ниже. При наличии опции выбирать или большее представление сцены или меньшее представление сцены, пользователь имеет возможность распределить ресурсы системы 10 так, чтобы те личности в данный момент, которые являются более важными для зрителя, были видны на более крупном, более ясном изображении; в то время как те, которых пользователь все еще хотел бы видеть, но не являются настолько важными в этот момент, могут все же быть видны.

Контроллер 52 дисплея вынуждает, чтобы каждый отличный поток видео, если имеются более одного (если имеет место вызов конференц-связи), появлялись рядом на дисплее 54. Изображения, которые сформированы рядом на дисплее 54, обрезаются и не масштабируются посредством уменьшения, так размеры самих объектов в сцене не изменяются, а только удаляются внешние границы с каждой стороны сцены, ассоциированной с каждым потоком данных. Если желательно, изображения из потоков, ассоциированные с меньшими изображениями сцен, могут быть отображены рядом в нижнем правом углу экрана 54 дисплея. Контроллер 52 дисплея обеспечивает стандартное цифровое видео на LCD (ЖК) контроллер 72, как показано на фиг.9. Контроллер 52 дисплея, произведенный фирмой ATI или Nvidia, является стандартным контроллером VGA. ЖК контроллер 72 принимает стандартизированное цифровое видео от контроллера 52 дисплея и делает изображение надлежащим для конкретной используемой панели, такой как панель Philips для Fujitsu.

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