Управление компоновкой конференции и протокол управления

Управление компоновкой конференции и протокол управления

Иллюстрации

Показать все

Реферат

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

Настоящая заявка относится к одновременно поданным предварительным заявкам на патент США № 60/814477 "Intelligent Audio Limit Method " авторов Richard E. Huber, Arun Punj и Peter D.Hill, имеющей номер в реестре поверенного FORE-119; № 60/814491 "Associating Independent Multimedia Sources Into a Conference Call", авторов Arun Punj, Richard E. Huber и Gregory H. Smith, имеющей номер в реестре поверенного FORE-121, обе из которых включены в настоящее описание по ссылке.

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

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

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

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

В отношении компоновки дисплея, в обычной основанной на MSU конференц-связи, MSU управляет размещением (компоновкой) потоков видео в отношении каждого участника. Фактически, MSU посылает одно и то же изображение всем участникам. Например, в конференц-связи с 10 участниками MSU будет выбирать любые 4, скажем B, C, D, E, и формировать составное изображение с B, C, D и E (вероятно, как Голливудские квадраты) и посылать его всем участникам.

В ViPr ("Виртуальное присутствие") эта модель была расширена до такой, где каждый участник может независимо индивидуально выбирать размещение (компоновку). Таким образом, А может просматривать 2 как большие видео (скажем, B и C) и просматривать другие 7 как маленькие видео. B может выбирать 1 большое видео, 3 маленьких видео и канал ТВ в качестве своего отображения.

В отношении протокола рассмотрим конференц-связь с 10 участниками. В традиционном протоколе сигнализации, когда имеется изменение в состоянии конференции, например если P1 отключает свое видео, должно быть послано сообщение с информацией для всех сторон P1-P10; это вызывает серьезные проблемы, связанные с масштабируемостью. Настоящее изобретение обеспечивает методику управления очень большой конференц-связью (с сотнями участников) эффективным способом. Методика является такой, посредством которой должно быть послано только различие, например в случае, упомянутом выше, маленькое событие NOTIFY (Уведомление) посылают с информацией, что P1 выключил свой передатчик.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг.21 изображает блок-схему настоящего изобретения, показывая несколько узлов.

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

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

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

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

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

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

При реализации изобретения настоящее изобретение обеспечивает методику управления компоновкой экранного отображения индивидуального участника конференции от одного из участников конференции. Например, если имеются участники P1-P10 в конференц-вызове, то один из участников может стать координатором и вынудить P2 просматривать (P1 и P5) в виде большого видео, а оставшиеся - в виде маленького видео соответствующие «живые» сцены каждого участника. Экранное отображение каждой стороны может индивидуально управляться этим способом.

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

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

Механизм управления компоновкой генерирует сообщение компоновки, которое содержит требуемую экранную компоновку для участников конференции. Сообщение компоновки также содержит список участников, которые должны принять это сообщение. Это сообщение компоновки затем посылают посредством события SIP NOTIFY (Оповещение SIP) в центр конференции или Хост. Центр конференции затем добавит это сообщение к очереди исходящих сообщений каждой стороны, содержащейся в этом списке. Центр затем пошлет это сообщение, когда он обработает все поставленные в очередь события, для каждой стороны. Когда сообщение послано и принято конкретной стороной, эта сторона модифицирует свою компоновку экранного отображения так, чтобы соответствовать запросу, содержащемуся в сообщении. Если изменение компоновки на экране требует, чтобы эта сторона подключилась или отсоединилась к/от новому(го) потоку(а) мультимедийной информации, то эта сторона выдаст соответствующие события, чтобы выполнить запрошенные изменения.

В настоящем изобретении была добавлена функциональная возможность, которая позволяет пользователю или набору пользователей (координатор/координаторы) индивидуально управлять компоновкой изображения на каждом видеотелефоне ViPr в конференции. Это управление может быть частичным или полным. В формате полного управления компоновкой изображения каждый участник в конференции вынуждается отображать видео в конкретном формате. Это отчасти аналогично MSU, однако отличается тем, что каждый участник может быть связан (синхронизирован) с различным форматом. Но как только участник связан с заданным форматом, он не имеет никакого контроля над компоновкой изображения конференц-связи. Например, А может быть связан так, чтобы отображать 3 больших видео «живых» сцен от C, D и E и 6 маленьких видео от F, G, H, I, J, K.

В формате частичного управления отображением каждый участник инструктируется отображать некоторые потоки в конкретных местоположениях. Но он имеет контроль над тем, что отображать на остальной части экрана. Например, А может быть проинструктирован, чтобы отобразить B в его левом большом видео. Однако он может выбирать, отображать ли 1, 2 или 3 больших видео. Точно так же схема может быть доступна для аудио/малого видео. Сообщения Управления Компоновкой посылают как SIP/NOTIFY сообщения, хотя они "могут" быть посланы посредством других средств SIP или HTTP.

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

Если участник вызова хочет координировать вызов, то он может использовать функциональную особенность «Управление Компоновкой», чтобы наложить ограничения на некоторые или все другие терминалы. Эти ограничения могут включать в себя (указание), каких участников отображать как большие окна видео. Они могут также управлять тем, какие из маленьких окон видео связаны (закреплены) с конкретным участником. Ограничения могут быть определены как обязательные или необязательные, что в свою очередь определяет, может ли участник отменять выбор координатора или нет. Управление компоновкой может также использоваться, чтобы управлять компоновкой вторичных изображений на экране. Управление компоновкой может также управлять размером любых вторичных изображений на экране. Управление компоновкой может также управлять глушением аудио от удаленных сторон и способностью удаленных сторон запрашивать уровень шума, когда они желают быть распознанными (над) уровнем шума и быть незаглушенными.

Сообщение SIP/NOTIFY, содержащее опции управления компоновкой, посылают в хост конференции, и затем хост конференции распространяет это сообщение всем другим сторонам.

Координатор вызова использует стандартный механизм SIP/SDP "a=Rx-List: А B C", чтобы определить, какие стороны отображает координатор вызова, где "А B C" представляют Идентификаторы Сторон удаленных сторон, которые просматриваются. При работе в режиме координируемого вызова они все обрабатываются как «необязательные» позиции компоновки (размещения), если только "m" не добавлено к стороне, например "Аm Bm Cm". "m" является флагом обязательности и сообщает удаленному Интерфейсу пользователя, какие стороны обязаны быть зафиксированными (связаны с) в позиции на экране. Необязательные стороны все еще могут быть изменены независимо каждым удаленным терминалом, если интерфейс пользователя желает это разрешать. Интерфейс пользователя может предписывать режим «все обязательно» в конференции, когда все стороны обрабатываются как обязательные при работе в координируемом вызове.

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

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

заявка на патент США № 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 или более узлов.

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

Предпочтительно, каждый узел сообщает только изменение только сторонам, на которые изменение воздействует.

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

Предпочтительно, этап передачи включает в себя этап передачи только изменения только к узлам, на которые воздействует это изменение. Этап создания предпочтительно включает в себя этап создания изменения состояния одного из узлов. Предпочтительно, этап создания включает в себя этап создания изменения состояния конференции. Имеется предпочтительно этап посылки направленного сообщения от одного из узлов только к некоторым, но меньше чем всем, узлам. Предпочтительно, этап установления включает в себя этап установления конференции на основании способов SIP NOTIFY/OK.

Изменение в конференции предпочтительно включает в себя изменение состояния одного из узлов. Предпочтительно, изменение в конференции включает в себя изменение состояния конференции. Один из узлов посылает направленное сообщение только к некоторым, но меньше чем всем, узлам. Предпочтительно, множество узлов устанавливает конференцию на основании способов SIP NOTIFY/OK. Каждый узел предпочтительно имеет контроллер 19 и Сетевой Интерфейс 42, находящийся в связи с контроллером 19 и сетью 40. Контроллер 19 осуществляет любое изменение в своем узле и посылает изменение через сетевой интерфейс 42 к и через сеть 40 к другим узлам конференции.

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

При работе предпочтительного варианта осуществления механизм управления большой конференцией использует сообщение управления конференцией, чтобы управлять всеми сторонами в отношении вызова. Участник формирует сообщение управления конференцией, которое содержит и свойства переданных потоков, и желательные списки потоков приема от других участников конференции. Это сообщение управления конференции затем посылают посредством события SIP NOTIFY (Уведомление SIP) в центр конференции или Хост. Центр конференции затем добавит это сообщение к очереди исходящих сообщений каждой стороны, на которую воздействует это сообщение. Центр затем пошлет эти сообщения, когда он обработает все поставленные в очередь события, для каждой стороны. Когда сообщение послано и принято конкретной стороной, эта сторона добавит запрашивающую сторону к своему списку исходящих потоков. Сообщение управления конференцией может также быть послано, чтобы указать желание перевести потоки видео в состояние «включено удержание» или «выключено удержание» для управления только речевой операцией.

Изобретение сигнализации большой конференции

Конференция ViPr ранее была основана на модели "предложение/ответ". В этой модели полное состояние конференции передавали в каждом сообщении, обмениваемом между участниками конференции. Например, рассмотрим конференцию между 5 участниками P1-P5. В этом случае эти пять сторон могут быть связаны в конференцию через центральную точку, называемую хостом. Хост мог формировать таблицу, которая содержит полное состояние конференции. Подобно тому, как если стороны P1-P3 передают/принимают видео/аудио, а стороны P2 и P3 только передают/принимают аудио, только эта таблица будет указывать это полное состояние. Когда какое-либо изменение случается в конференции, хост мог повторно вычислять таблицу и посылать каждому эту информацию. Например, если P3 прекратил передавать видео, он изменял таблицу 1 на таблицу 2 и посылал эту полную таблицу каждому.

Таблица 1
P1	Video (tx=0n, rx=0n),Audio (tx=on, rx=on)
P2	Video (tx=0n, rx=0n), Audio (tx=on, rx=on)
P3	Video (tx = 0n, rx=0n), Audio (tx=on, rx=on)
P4	Video (tx=0ff, rx=on), Audio (tx=on, rx=on)
P5	Video (tx=off, rx=on), Audio (tx=on, rx=on)

Таблица 2
P1	Video (tx=0n, rx=0n), Audio (tx=on, rx=on)
	Video (tx=0n, rx=0n), Audio (tx=on, rx=on)
	Video (tx = 0n, rx=0ff), Audio (tx=on, rx=on)
P4	Video (tx=0ff, rx=on), Audio (tx=on, rx=on)
	Video (tx=off, rx=on), Audio (tx=on, rx=on)

Эта схема работала хорошо, потому что была совместима с существующими стандартами SIP и разрешала добавлять расширения к основному протоколу SIP, чтобы разрешить конференц-связь стиля ViPr ("Виртуальное присутствие").

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

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

$ Состояние конференции может изменяться в двух отношениях. Или один из участников запросил изменение в его состоянии (локальной стороны), или одна из сторон запросила изменение в состоянии всей конференции (глобальное изменение). Когда бы ни было сделано любое такое изменение, только информация, специфичная для измененной стороны или глобального состояния конференции, передается между участниками конференции. Чтобы использовать пример из таблицы 2, только информация, соответствующая P3, должна быть выдана, а не полная таблица. [Таким образом, только строка, относящаяся к P3, будет повторно послана другим участникам.] Примеры Глобальных Событий:

-> Изменение названия конференции,

-> Изменение состояния координатора конференции,

-> Изменение состояния запроса уровня шума,

-> Изменение типа конференции,

-> Сообщения состояния конференции (сторона, отклоненная от присоединения к конференции и т.д.).

Примеры событий сторон:

-> переключение камеры стороны,

-> состояние переключения удержания стороны,

-> удаление стороны,

-> добавление стороны,

-> изменение состояния стороны (становится/прекращает быть координатором),

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

$ Только стороны, на которые воздействует изменение, принимают измененную информацию.

$ Возможно посылать направленное сообщение от одной стороны P1 к любому числу сторон. Например, P1 может запросить хост передать сообщение к P2, P3 и P4, но не к P5. Эта последняя функциональная возможность важна, чтобы разрешить основанную на группе сигнализацию в конференц-связи.

Новая структура основана на способах SIP NOTIFY/OK и определяет новый пакет событий. Стандарты RFC 3261 и RFC 3264 определяют основные технические требования для SIP. RFC 3265 определяет структуру для использования событий, оба из которых включены в настоящее описание по ссылке.

Например, хост всегда требуется для ViPr конференции. Фактически, стороны в конференции не выполняют когда-либо непосредственно сигнализацию друг с другом. Например, если имеется конференц-связь между A, B и C, имеются три участка маршрута (ответвления) вызова SIP:

- Хост к А

- Хост к B

- Хост к С

Потоки мультимедийной информации передаются непосредственно между A, B и C.

В настоящем изобретении B в настоящее время принимает видео от А и теперь желает также принимать видео от C. Это изменение может быть сообщено любым способом из двух.

B посылает NOTIFY к хост, причем поле в NOTIFY [называемом dest-party-list:C (список сторон-адресатов:С)] указывает, что это сообщение может быть послано только к C. Альтернативно, Хост может обнаруживать, что это сообщение воздействует только на C, и может посылать это сообщение только к C, хотя B был явно не помещен в какое-либо такое поле.

Видеофон

Со ссылками на Фиг.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.

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

Функциональные возможности видеофона 15 управляются сенсорным экраном 74 на мониторе. Сенсорный экран 74, который является стандартным стеклянным сенсорным экраном, выдает необработанные сигналы на контроллер 76 сенсорного экрана. Необработанные сигналы воспринимаются ультразвуковыми волнами, которые создаются на стекле, когда пользователь касается стекла в данном местоположении, как известно в данной области техники. Контроллер 76 сенсорного экрана затем принимает необработанные сигналы и преобразовывает их в значимую информацию в отношении позиции X и Y на дисплее и передает эту информацию на основной контроллер 50.

Если телевизионное соединение или соединение с видеомагнитофоном доступны, подача (сигналов) для телевидения или кинофильма обеспечивается на декодер 34, где такая подача управляется, как любой другой сигнал видео, принятый видеофоном 15. Телевидение или кинофильм могут появляться помимо сцены от видеосоединения с другим видеофоном 15 на дисплее 54.

Аудиопоток сцены по существу следует параллельным и аналогичным путем с потоком видео/аудио, за исключением того, что поток аудио обеспечивается от приемника 58 аудио, такого как микрофон, звуковой платы, головного телефона или микротелефонной трубки к аудиоинтерфейсу 60 CS Crystal 4201 или, например, кодеку, который выполняет аналого-цифровое и цифроаналоговое преобразование сигналов, а также управляет громкостью и смешением (микшированием), которое оцифровывает аудиосигнал, и выдает его к цифровому сигнальному процессору (DSP, ЦСП) 62 типа TCI 320C6711 или 6205. DSP 62 затем пакетирует цифровой поток аудио и передает цифровой поток аудио к FPGA 38. FPGA 38, в свою очередь, выдает его на PCI интерфейс 44, где он затем передается на сетевую интерфейсную плату 56 для передачи в сеть 40. Поток аудио, который принят прини