Соединение независимых мультимедийных источников в конференц-связь

Соединение независимых мультимедийных источников в конференц-связь

Иллюстрации

Показать все

Реферат

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

Настоящая заявка относится к одновременно поданным предварительным заявкам на патент США № 60/814,477 "Intelligent Audio Limit Method " авторов Richard E. Huber, Arun Punj и Peter D.Hill, имеющей номер в реестре поверенного FORE-119; №60/814,476 "Conference Layout Control and Control Protocol" авторов Richard E. Huber и Arun Punj, имеющей номер в реестре поверенного FORE-120; обе из которых включены в настоящее описание по ссылке.

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

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

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

Рассмотрим сеанс связи ViPr ("Виртуального присутствия") (или любую мультимедийную конференцию или p2p (одноранговую)), в котором 2 или более сторон обмениваются с помощью аудио/видео/данных друг с другом, например видеовызов между A, B и C. Теперь пользователь А желает, чтобы B и C просматривали на своем видеофоне мультимедийный поток S, который в настоящее время просматривает А. Например, этот поток S может быть видеоканалом, подобным PBS (Государственной службы радиовещания). Пользователи обычно требуют, чтобы была возможность обсудить события, когда они воспроизводятся на внешнем мультимедийном потоке S. Настоящее изобретение позволяет это выполнить с помощью программной сигнализации.

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

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

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

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

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

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

Фиг.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 содержит узел 207 с контентом, имеющим контент и адрес в сети 40, и находящийся в связи с сетью 40. Система 10 содержит первый пользовательский узел 201 и второй пользовательский узел 203, находящиеся в связи друг с другом через сеть 40, чтобы сформировать конференцию. Первый пользовательский узел 201 способен обеспечивать адрес узла 207 с контентом через сеть 40 к первому и второму узлам, так что первый и второй узлы могут оба обращаться к контенту узла 207 с контентом в течение конференции.

Предпочтительно, первый пользовательский узел 201 посылает сообщение, имеющее адрес, на второй пользовательский узел 203. Адрес предпочтительно включает в себя URL (унифицированный указатель информационного ресурса). Предпочтительно, сообщение включает в себя параметры защиты, необходимые для второго пользовательского узла 203, чтобы обратиться к контенту. Контент предпочтительно включает в себя изображение. Предпочтительно, сообщение является сообщением SIP/NOTIFY, которое передает сигнализацию, содержащую параметры защиты и URL.

Контент предпочтительно включает в себя поток видео. Предпочтительно, система 10 включает в себя третий пользовательский узел 205 в конференции, который также принимает сообщение SIP/NOTIFY от первого пользовательского узла 201, чтобы обратиться к контенту.

Сообщение SIP/NOTIFY от первого пользовательского узла 201 предпочтительно позволяет второму и третьему пользовательским узлам 203, 205 обращаться к контенту без какого-либо вмешательства со стороны второго и третьего пользовательских узлов 203, 205.

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

Предпочтительно, этап обеспечения включает в себя этап посылки сообщения, имеющего адрес, на второй пользовательский узел 203. Этап посылки предпочтительно включает в себя этап посылки сообщения, имеющего адрес, который включает в себя URL, ко второму пользовательскому узлу 203.

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

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

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

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

При реализации предпочтительного варианта осуществления настоящее изобретение решает потребность ассоциировать хорошо известный мультимедийный поток с реальной конференц-связью. Например, имеются три участника в конференции A, B и C, говорящие с друг другом и просматривающие друг друга «в живую». (Должно быть отмечено, что могут быть 10, 20, 50, 100, 500 или даже 1000 участников в реальной конференц-связи.) (Участник) А смотрит некоторые реальные новости, имеющие место на видеоканале, т.е. экономические новости, и желает, чтобы B и C смотрели этот видеоканал автоматически. Новый разработанный способ дает возможность B и C обратиться к этому видеоканалу без какого-либо вмешательства или действия пользователем В или C. Множество таких каналов или мультимедийных потоков может быть ассоциировано с одной и той же конференцией.

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

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

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

1. Пользователь Фред просматривает источник вещания по Web/TV, называемый Channel_A (Канал А).

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

3. Пользователь Фред инициализирует конференцию с участниками Фред/Вилма/Барни.

4. Пользователь Фред "совместно использует" информацию относительно того, как принять канал Channel_A с Вилма/Барни.

В вышеупомянутом примере на этапе 3 конференц-связь устанавливается между Фред/Вилма/Барни с использованием обычных VOIP/SIP методов конференц-связи (см. RFC 3261 и RFC 3264, обе из которых включены в настоящее описание по ссылке, и документацию патентной заявки ViPr, указанной ниже, и ViPr и его информацию о продуктах, продаваемых от Ericsson. Настоящее изобретение использует ViPr в качестве платформы). На этапе 4 пользователь нажимает кнопку Share (Совместное использование) на видеофоне ViPr для этого канала. Когда пользователь совместно использует канал TV/Webcast, программное обеспечение передает всем участникам сеанса связи (в этом случае Вилме/Барни) атрибуты, требуемые для "настройки на" этот канал Channel_A.

Сигнализацию, требуемую для этого, передают в сообщении SIP NOTIFY. Помимо прочего оно содержит следующую информацию:

URL (SIP или SIPS или HTTP)	Оно относится к одному из местоположений, из которых поток может быть запрошен Вилмой/Барни
Информация о безопасности	Эта информация может содержать любой маркер защиты или механизм аутентификации, который пользователи Вилма/Барни могут использовать, чтобы принять канал Channel_A

Должно быть отмечено, что, если Вилме и Барни не позволено просмотреть Канал A из-за политики защиты/политики администратора/политики цензуры, они должны быть лишены доступа к Каналу A. Должно быть отмечено, что Канал A может быть видеоканалом, и каналом аудио или каналом передачи данных, сигнализация работает одинаковым образом для всех из них. Должно также быть отмечено, что сопутствующий канал может быть совместно использован при вызове p2p (соединении равноправных узлов) или обратном вызове.

Передача сообщений

Пусть Фред использует ViPr телефон V1, Вилма находится на V2, и Барни находится на V3.

#	Фред	Вилма	Барни
1	Фред совместно использует Канал A. Сообщение SIP - NOTIFY посылается от V1 к V2 и V3. Это уведомление содержит информацию URL /параметров защиты в дополнительной информации, требуемой, чтобы описать атрибуты внешнего потока.
2		Вилма принимает NOTIFY и инициализирует передачу обычного SIP приглашения для просмотра Канала А	Барни принимает NOTIFY и инициализирует передачу обычного SIP приглашения для просмотра Канала А
3	Пользователи Фред/Барни/Вилма могут теперь обсуждать Канал А

Ниже представлен список некоторых из возможных источников для «Изображения», который может быть распределен в форме «Адрес»:

Вещание Видео

TV передачи

Web-вещание

Неподвижное изображение

Интерактивная переписка

Microsoft Word

Электронные таблицы Excel

Удаленное экранное изображение от VNC (система числового управления с речевым вводом команд) или удаленного настольного компьютера

Microsoft Live Meeting

DVD

Сотовый телефон с аудиопотоком

Web-страница

Файл

«Адресом» может быть URL или IP-адрес или что либо еще, что может использоваться для поиска или просмотра с помощью индекса.

В качестве опции, это изображение может быть "опосредованным" этим Изображением посредством организации копии, которая должен быть сделана, и эта копия распределена вместо адреса.

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

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

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

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

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

Видеофон

Со ссылками на Фиг. 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. Поток аудио, который принят принимающим видеофоном 15, передается к FPGA 38 и затем на DSP 62, и затем к аудиоинтерфейсу 60, который преобразовывает цифровой сигнал в аналоговый сигнал для воспроизведения на динамиках 64.

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

Плата ENC-DSP содержит MPEG-2 кодер IBM eNV 420 и схему поддержки, DSP 62 для кодирования и декодирования аудио и PCI интерфейс 44. Она содержит аппаратные средства, которые необходимы для (обеспечения) полных функциональных возможностей терминала видеофона 15, заданных высокопроизводительной платформой ПК 68 и дисплеем 54 системы 10. Она является полноразмерной PCI 2.2 - совместимой конструкцией. Камера, микрофон(ы) и динамики 64 взаимодействуют с этой платой. DSP 62 будет для аудио выполнять кодирование, декодирование, смешивание, размещение стерео, регулировку уровня, заполнение промежутков, пакетирование и другие функции аудио, такие как AEC (компенсация акустического эха, КАЭ) стерео, управление лучом, подавление шума, отмена щелчка клавиатуры, или дереверберация. FPGA 38 разработан, используя инструментальные средства Celoxia (Handel-C), и является полностью реконфигурируемой. Топология поддерживает части в диапазоне 1-3 миллиона логических вентилей.

Эта плата включает в себя микросхему интерфейса цифровой камеры 47, основанной на аппаратных средствах или на "видео DSP", многоканальный интерфейс видеодекодера 34, наложение видео с использованием входных и выходных соединителей стандарта DVI, вплоть до возможностей полностью немого буфера кадров с наложением видео.

Используя видеосигнал в стандарте NTSC или PAL, кодер 36 должен сформировать 640×480, и предпочтительно 720×480 или с еще лучшим разрешением высококачественный поток видео. Скорость передачи в битах должна управляться так, чтобы максимальное количество битов на кадр было ограничено, чтобы предотвратить задержку на передачу сигналов по сети 40. Декодер 34 должен начать декодировать вырезку (срез) после приема первого макроблока данных. Некоторая буферизация может потребоваться, чтобы скомпенсировать незначительную флуктуацию и таким образом улучшить изображение.

MPEG-2 широко используется и развернут, является базовым для DVD и VCD кодирования, цифровых видеомагнитофонов и устройств смещения времени, таких как TiVo, а также как DSS и другого вещания цифрового TV. Обычно рассматривается как нормальный выбор передачи видеосигнала от 4 до 50 Мбит/секунду. Из-за его широкого использования, относительно низкой стоимости, высоко интегрированных решений для декодирования и более последнее - кодирования в настоящее время (он) является коммерчески доступным.

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

Представляющими интерес для проекта видеофона 15 являются вопросы кодирования и декодирования с низкой задержкой, а также вопросы, связанные с сетью 40. Имеются три первичные проблемы в MPEG-2 алгоритме, которые должны быть поняты, чтобы обеспечить видео высокого качества с малой задержкой по сети 40:

= структура GOP (Группа Изображений) и ее влияние на задержку,

= влияние скорости передачи информации в битах, вариации размера кодированного кадра и буфера VBV на задержку и требования сети 40,

= влияние структуры GOP на качество с потерей пакетов.

Структура GOP и задержка

MPEG-2 определяет 3 вида кодированных кадров: I, P и B. Наиболее общая структура GOP, находящаяся в использовании, имеет длительность 16 кадров:

IPBBPBBPBBPBBPBB. Проблема с этой структурой заключается в том, что каждый последующий кадр B, так как кадр B является движением, оцененным исходя из предыдущего и последующего кадра, требует, чтобы последующие кадры были захвачены перед тем, как может начинаться кодирование кадра B. Так как каждый кадр имеет длительность 33 мсек, это добавляет минимум 66 мсек дополнительной задержки для этой структуры GOP по сравнению с таковой без B кадров. Это приводит к структуре GOP с малой задержкой, которая содержит только I и/или кадры P, определенные в MPEG-2 спецификациях как кодирование SP@ML (Простой профиль).

Скорость передачи информации в битах, размер кодированного кадра и VBV

Как только B кадры удалены, чтобы минимизировать задержку кодирования, GOP состоит из I кадров и кадров P, которые являются относительными для I кадров. Поскольку I кадр является кодированным полностью внутрикадровым образом, требуется много битов, чтобы выполнить это, и меньшее количество битов для последующих P кадров.

Следует заметить, что I кадры могут быть в 8 раз большего размера, чем кадр P, и в 5 раз больше номинальной скорости передачи (частоты следования) информации в битах. Это имеет прямое воздействие на требования сети 40 и задержку: если имеется ограничение полосы частот, I кадры будут буферизированы с ограничением сети 40, приводя к добавленной задержке времени передачи множества кадров для передачи в ограниченном сегменте. Этот буфер должен быть согласован в приемнике, потому что скорость воспроизведения устанавливается посредством видео, а не полосой частот сети 40. Выборка, используемая для вышеупомянутых данных, была сценой офиса с малым движением; в контенте с большим движением с изменениями сцены кадрам будут назначены больше или меньше битов, в зависимости от контента, с несколько большими P кадрами, встречающимися в изменениях сцены.

Чтобы управлять этим поведением, MPEG-2 реализует буфер VBV (Верификатор буферизации видео, ВБВ), который допускает степень управления соотношением между максимальным размером закодированного кадра и номинальной скоростью передачи информации в битах. Сильно ограничивая VBV так, чтобы I кадры были ограничены менее чем 2-кратным размером, указанным номинальной скоростью передачи информации в битах, добавленная задержка буферизации может быть ограничена временем 1 дополнительного кадра. Стоимостью ограничения размера VBV является качество картинки: причина для больших I кадров должна обеспечить хорошее основание для последующих P кадров, и качество серьезно ухудшается при более низких скоростях передачи информации в битах (<4 Мбит), когда размер I кадров ограничен. Полагая, что при 2 Мбит средний размер кадра равен 8 Кбайт, и даже двукратный этот размер не является достаточным, чтобы закодировать JPEG изображение 320×240 с хорошим качеством, которое является подверженным DCT-сжатию, аналогично I кадру.

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

Спецификация MPEG-2 определяет режимы CBR (постоянная скорость передачи информации в битах) и VBR (переменная скорость передачи информации в битах) и учитывает переменную структуру GOP в пределах потока. Режим CBR определен, чтобы формировать постоянное количество битов для каждой GOP, используя заполнение по мере необходимости. VBR предназначен, чтобы обеспечить постоянное качество, допуская вариации при кодировании полосы частот, с трудом разрешая распределить потоку больше битов для кодирования областей, пока это компенсируется более низкими скоростями передачи информации в битах в более простых секциях. VBR может быть реализован способами с двумя проходами или единственным проходом. Переменная структура GOP допускает, например, размещение I кадров на границах перехода сцены, чтобы устранить видимые артефакты сжатия. Из-за требования малой задержки и необходимости небольшого предвидения, чтобы реализовать VBR или переменную GOP, эти режимы имеют небольшой интерес для применения в видеофоне 15.

Поскольку P и B кадры в типичной структуре GOP являются зависимыми от I кадра и предшествующих P и B кадров, потеря данных воздействует на все кадры после ошибки до следующего I кадра. Она также воздействует на задержку начала, например, при переключении каналов в системе DSS 10, где декодер 34 ожидает I кадры, прежде чем он сможет начать отображение изображения. По этой причине длина GOP, структура и скорость передачи информации в битах должны быть настроены на приложение и систему 10 поставки. В случае совмещения реального времени, использующего IP, используется ненадежный транспортный протокол, такой как RTP или UDP, потому что последний пакет должен быть обработан как потерянный, так как вы не можете допустить задержку, требуемую для того, чтобы иметь дело с надежным квитированием протокола и повторной передачей. Различный анализ был сделан в отношении влияния потери пакета на качество видео с результатами, показывающими, что для типичной структуры GOP IPB потеря 1% пакетов приводит к потере 30% кадров. Более короткие структуры GOP, и в конечном счете только потоки I кадров (с потерей качества), помогают этому в некоторой степени, и немного могут помочь методы FEC (прямого исправления ошибок), когда происходит потеря, но несомненно одной из проблем, связанных с MPEG-2, является та