Видео по сети

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

СТАНДАРТ КАК ОН ЕСТЬ
T.120: суперстандарт

АУДИО/ВИДЕО ФОРМАТ БЕЗ ПЕРЕРЫВОВ
Активный потоковый формат

Если вас интересуют новости из сетевой отрасли, тогда вы наверняка знаете, что видео для настольных систем стало очередной ide,e fixe. Такие видеоприложения, как конференции в реальном времени, "живые" новости из Internet или вдохновенное обращение исполнительного директора станет скоро получать и ваша настольная система. Это, конечно, означает, что администратор должен будет их поддерживать.

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

БАЗОВОЕ ВИДЕО: КАДРЫ И ПИКСЕЛЫ

Мир видео может быть разделен на две части. Во-первых, это видео реального времени, когда запись осуществляется одновременно с ее просмотром. Видеоконференции классический тому пример. Типичным источником видео реального времени являются небольшие камеры с зарядовой связью (Charged Coupled Device, CCD), например QuickCam производства Connectix. В зависимости от мощности настольного ПК эти небольшие камеры (обычно размещаемые над монитором) осуществляют съемку с частотой от 5 до 30 кадров в секунду, причем последняя величина соответствует нормальному качеству вещания. Разрешение видео реального времени может меняться в значительных пределах от крупных изображений, требующих большей пропускной способности, но более подходящих для нормального общения, до небольших "почтовых марок", вмещающих только говорящую голову.

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

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

Ориентированное на массового потребителя программное обеспечение видеоконференций, такое как CU-SeeMe от White Pine Software, заполняет изображением лишь часть экрана с разрешением 640*480 пикселов, как правило, одну четвертую (320*240 пикселов) или одну шестнадцатую (160*120 пикселов). Другое программное обеспечение, например системы видеоконференций NetMeeting компании Microsoft или LiveLAN компании PictureTel, использует общий промежуточный формат (Common Intermediate Format); CIF, иногда называемый Full CIF (FCIF), определяет окно размером 352*288 пикселов.

Стандартными производными этого формата являются Quarter CIF (QCIF, 176*144 пикселов) и Subquarter CIF (SQCIF, 128*96 пикселов), т. е. реально экран в одну девятую экрана CIF. Стандарты видеоконференций, такие как H.261 для сжатия видео, разрабатывались с учетом форматов CIF, QCIF, SQCIF, 4-CIF (704*576 пикселов) и 16-CIF (1408*1152 пикселов).

Используемая глубина цвета имеет зачастую более важное значение, чем размер изображения. Глубина цвета колеблется в диапазоне от 256 (8 бит на пиксел) до миллиардов цветов (32 бит на пиксел). В Таблице 1 приводятся наиболее распространенные размеры изображений с указанием глубины цвета, а также минимально необходимой пропускной способности при передаче несжатых данных. Пропускная способность варьируется в широких пределах - от 768 Кбит/с для небольших дергающихся картинок до свыше 221 Мбит/с для полноэкранных изображений с хорошим разрешением.

ТАБЛИЦА 1. НЕОБХОДИМАЯ ПРОПУСКНАЯ СПОСОБНОСТЬ ДЛЯ НЕСЖАТОГО ВИДЕО

НА МАЗИ

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

Всего несколько производителей предлагают сетевое программное обеспечение видеосервера. Starlight Net-works продает семейство программных видеосерверов для Windows NT Server, Solaris, HP-UX и AIX в сетях IP. Продукт Starlight под названием StarWorks 3.2 для потокового видео способен предоставлять 150 Мбит/с с Windows NT

и поддерживать до 100 видеосеансов. Для доступа к системе клиенты используют браузеры Web с модулем расширения StarWorks. Сопутствующий продукт StarCast обеспечивает многоадресную передачу мультимедиа по IP от аналоговых и цифровых источников. Оба продукта понимают форматы MPEG-1 и Indeo.

Web Theater Server компании VXtreme, оптимизированный для работы в сети, но могущий работать и через модем со скоростью 28,8 Кбит/с, также использует модули расширения браузера на стороне клиента. Последняя версия, 2.2, может передавать видео в формате CIF по соединению на 56 Кбит/с. По утверждению VXtreme версия Windows NT 4.0, установленная на сервере с одним процессором Pentium 90 МГц с оперативной памятью емкостью 64 Мбайт, способна поддерживать до 25 видеопотоков; сервер с четырьмя процессорами Pentium Pro на 200 МГц может обслуживать до 500 видеопотоков. Web Theater Server работает также и под управлением UNIX (на Solaris и IRIX).

Другое решение для видеосерверов, CU@Work компании White Pine, предназначено главным образом для проведения настольных видеоконференций, - это сетевая версия популярного программного обеспечения CU-SeeMe для видеообщения по Internet. Базовый вариант CU@Work - сервер на 50 пользователей с 25 клиентами на основе IP Multicast. Последнее предложение компании, Meeting Point, - более надежный сервер, опирающийся на стандарты H.323 и T.120. Выполняется он на серверах Windows NT, Solaris, IRIX и HP-UX. Meeting Point взаимодействует с клиентами на базе H.323 (о них мы поговорим позднее), а не только с клиентами CU-SeeMe. (Дополнительную информацию о T.120 смотри во врезке "T.120: суперстандарт".)

Если Windows NT ваша основная платформа, то NetShow 2.0 компании Microsoft устанавливается в качестве сервиса (он включается также в состав комплекта SiteServer) и предоставляет потоковое видео по коммутируемым или сетевым соединениям. Дополнительная функция, NetShow FSV (Full Screen Video), позволяет передавать видео MPEG-1 или MPEG-2 по коммутируемому Ethernet и ATM; в настоящее время клиент поддерживает только MPEG-1. По утверждению Microsoft максимальная скорость, с которой NetShow FSV может подавать потоковое видео через сетевую плату Ethernet на 100 Мбит/с, составляет 80 Мбит/с, а всего он может обслуживать около 40 потоков. В случае сетевой платы ATM на 155 Мбит/с скорость потокового видео достигает 100 Мбит/с, а число одновременно обслуживаемых потоков - 50.

Один из наиболее интересных вопросов - дисковая подсистема. Многие производители видеосерверов настоятельно рекомендуют, главным образом для улучшения скорости передачи, использовать дисковую подсистему RAID-5. Крупные системы RAID обеспечивают лучшие характеристики, чем типичные для чередования RAID; они, например, имеют большой аппаратный кэш. Небольшие же серверы могут опираться на обычные адаптеры SCSI для выполнения функций RAID, а функции чередования и избыточности осуществляться серверной ОС.

Жесткий диск типичного сервера с кэшем 512 Кбайт способен обслуживать до 5 Мбайт/с - эта величина намного меньше скоростей передачи данных, приводимых производителями накопителей, но они обычно указывают максимальную скорость пакетной передачи, достигаемую на внешних дорожках накопителя.

Новое поколение так называемых "аудио/видеодисков" намного превосходит скорости прежних, например Tomahawk AV на 9,1 Гбайт компании Mic-

ropolis вращается со скоростью 7200 оборотов в минуту. По словам Сэма Сойера, менеджера линии продуктов в Micropolis, средняя скорость передачи данного продукта 6,5 Мбайт/с, а максимальная - около 10,5 Мбайт/с. Диски, подобные Tomahawk со встроенным кэшем на 2 Мбайт, намного превосходят производительность систем RAID-5 младшего класса. Однако Сойер считает, что системы RAID-5 с большим аппаратным кэшем (скажем, от 20 до 30 Мбайт) не в силах извлечь аналогичные преимущества из данных накопителей. Если у вас есть такой контроллер, то он рекомендует установить менее дорогие накопители с меньшим встроенным кэшем.

ПЕРЕДОВОЕ ВИДЕО: ДА ЗДРАВСТВУЕТ КОДЕК!

Наихудшая ситуация в случае цифрового видео - когда видео передается в несжатом виде, например 30-кадровое изображение в формате QCIF требует пропускной способности 12 Мбит/с. Но это довольно редкая ситуация, поскольку цифровое видео упаковывается (сжимается) кодеками (сокращение от английского compressor/decompressor). С помощью разнообразных схем кодирования, применение которых зависит от вычислительной мощности, доступной пропускной способности и требуемого качества видеоизображения, необходимая пропускная способность может быть уменьшена до приемлемого уровня. Однако помните: любая схема сжатия не лишена недостатков. Например, накладные расходы на сжатие могут оказаться непомерными для снабженных видеокамерой старых ПК с 486-м процессором. Видеоприложения поддерживают, как правило, несколько кодеков - в основном, посредством подключаемых модулей. Некоторые кодеки, такие как MPEG-2, предназначены для обработки потокового видео; они относительно легко поддаются распаковке, но сжатие способен осуществить только достаточно мощный ЦПУ.

Более подробную информацию о кодеках можно найти на узле Codec Central Web по адресу: www.codecetral.com (этот сервер поддерживается производителем кодеков Terran Interactive). Самая последняя информация всегда в цене, а информация о кодеках появляется постоянно.

Одним из последних кодеков для видео в реальном времени является RealVideo. Он встроен в видеосистему RealPlayer компании Progressive Net-work. CU-SeeMe компании White Pine Software использует Motion JPEG, или M-JPEG, для соединений по локальной сети либо ISDN.

Кодек Indeo компании Intel разрабатывался изначально под Video for Windows компании Microsoft. Net-Meeting 2.0 от Microsoft поставляется с тем, что Microsoft называет кодек для видео в реальном времени MPEG-4. Но, по словам Даррена Гайлза, технического директора Terran Interactive, MPEG-4 находится пока в стадии разработки. "Так что Microsoft опережает события", - гово-рит он. (Дополнительную информацию о семействе мультимедийных стандартов группы Motion Picture Experts Group можно почерпнуть из ответов на часто задаваемые вопросы по адресу: www.mpeg1.de/mpegfaq.)

Кодеки также бывают стандартными, например видеокодек H.263 поддерживается несколькими системами для проведения конференций от PictureTel и Intel. Имеются и отдельные аудиокодеки, наиболее распространенными среди которых являются MPEG уровня 3 группы MPEG и G.723 от ITU-T.

Выбор кодека зависит от того, какая пропускная способность необходима и какое будет видео - по запросу или в реальном времени. Многие видеосерверы и клиенты работают с различными кодеками. По этому поводу Гайлз говорит следующее: "Утверждения типа MPEG-2 лучше, чем H.263, абсолютно беспочвенны в отрыве от контекста. В определенных условиях каждая технология способна проявить себя наилучшим образом".

Например, MPEG-1 предназначался для работы со скоростью 150 Кбайт/с, с разрешением 320*240 пикселов при частоте 30 кадров/с; MPEG-2 - со скоростью от 400 до 800 Кбайт/с с видео телевизионного качества. H-263 разрабатывался под медленные модемы со скоростью порядка 10 Кбайт/с и разрешением 160*120 пикселов (частота кадров зависит от требуемого качества воспроизведения).

Рассмотрим 8-разрядное подвижное изображение в формате QCIF вместе с 8-разрядным монофоническим аудиосигналом с частотой оцифровки 11 кГц. По заявлению Microsoft, видеокодек MPEG-4 и аудиокодек MPEG уровня 3 в программном обеспечении NetMeeting 2.0 способны обрабатывать от 5 до 10 кадров/с по модемному соединению на 28,8 Кбит/с, от 10 до 15 кадров/с по ISDN на 56 Кбит/с и 15 кадров/с по обычной коммутируемой локальной сети 10BaseT. В несжатом виде данный видеоформат потребовал бы для скорости передачи 3041 Кбит/с, а аудиоформат - 88 Кбит/с.

Потоковое видео от видеосерверов налагает специальное требование: видеофайл должен быть записан в формате, который не только сжат при записи, но и оптимизирован для просмотра на клиенте в процессе его передачи. Прежние форматы цифрового видео, такие как MPEG-1 и Quick-Time, разрабатывались с учетом вышесказанного. Microsoft продвигает новый формат - Action Streaming Format, благодаря которому потоковое видео передается более равномерно. Дополнительную информацию об ASF смотри во врезке "Активный потоковый формат".

ATM ИЛИ IP?

Один из наиболее актуальных вопросов относительно видео по сети состоит в следующем: достаточно ли Ethernet с IP или лучше сразу переходить к ATM? Во многих ситуациях это вопрос столь же вкуса, сколь и техники, поскольку потоковые мультимедиа и видео в реальном времени совместимы и с IP, и с ATM. Ввиду значимости этого вопроса и последствий его решения не только для мультимедиа, мы рассмотрим те особенности ATM и IP, которые имеют непосредственное отношение к передаче высококачественного видео.

архитектура ATM подходит естественным образом для сетевого мультимедиа в силу своих трех основных и одной побочной особенностей. Во-первых, коммутируемые виртуальные соединения (Switched Virtual Circuit, SVC) позволяют создавать высокоскоростные соединения между узлами по необходимости, например между двумя участниками видеоконференции или между видеосервером и клиентом.

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

В-третьих, это стандарт Multiprotocol over ATM (MPOA). Активно продвигаемый Cisco, Fore Systems и Newbridge Network, MPOA является в настоящее время первым стандартом для коммутации третьего уровня в сети. MPOA расширяет эмуляцию ЛС на втором уровне за счет создания виртуальных соединений практически со скоростью линии через несколько подсетей. По сути MPOA решает ту же самую проблему, что и так называемая IP-коммутация (которую мы тоже обсудим), с тем только отличием, что производители пришли к согласию относительно MPOA - стандарт был одобрен ATM Forum в июле прошлого года.

В-четвертых, многие операторы свя-зи имеют магистрали ATM; AT&T, MCI и Sprint предлагают сервисы на 155 Мбит/с, а некоторые другие собираются модернизировать свою магистраль до ATM на 622 Мбит/с. В корпоративной среде ATM находит основное применение на магистрали; лишь немногие компании прокладывают ATM до настольных систем или даже до коммутатора рабочей группы/отдела. Ethernet и IP доступны на несравнимо большем числе настольных систем, и, таким образом, они охватывают все предприятие. IP - это стандартный протокол Internet, и, как таковой, он естественным образом используется для транспортировки видео по Internet и виртуальным частным сетям на базе IP. Но, в отличие от ATM, Ethernet не имеет стандартных средств для обеспечения качества услуг из конца в конец. По сути коммутация со скоростью линии между подсетями - иными словами, коммутация третьего уровня - застряла в трясине несовместимых разработок.

Однако и Ethernet, и IP способны кое-что предложить для обеспечения качества услуг, а значит, компании могут воспользоваться уже имеющимися технологиями.

Протокол передачи в реальном времени (Real-time Transport Protocol, RTP) призван заменить TCP и UDP. В отличие от TCP, RTP поддерживает многоадресное распространение информации, а в отличие от UDP он предоставляет информацию о времени, необходимую для передачи в реальном времени.

Протокол управления передачей в реальном времени (Realtime Transport Control Protocol, RTCP) обеспечивает обратную связь для RTP-совместимых приложений о сети и качестве доставки, благодаря которой эти приложения могут вносить необходимые коррективы на лету.

Третьим членом этой троицы стал протокол резервирования ресурсов (Resource Reservation Protocol, RSVP), с помощью которого конечные системы (клиенты и серверы) могут резервировать сетевые ресурсы, необходимые для обеспечения качества услуг при трафике RTP. Вместе RTP и RSVP обладают многими достоинствами качества услуг ATM - по крайней мере, когда они поддерживаются из конца в конец во всей сети. (Подробное обсуждение этих протоколов смотри в статье "RTP и RSVP: доставка в срок" в сентябрьском номере журнала за прошлый год.)

Что касается доставки мультимедиа, то Ethernet имеет еще один козырь в рукаве: IP Multicast, определенный в IETF RFC 1112. С помощью IP Multicast отправитель может передать сообщение только один раз; вместо широковещательной рассылки всем конечным узлам сообщение тиражируется и доставляется хостам, являющимся членами группы многоадресной рассылки. IP Multicast, опирающийся на RTP, может, таким образом, быть использован для доставки видео в реальном времени нескольким участникам конференции в корпоративной сети при условии, что все компоненты (в том числе маршрутизаторы) поддерживают данный протокол.

В настоящее время IP Multicast проходит экспериментальную обкатку в рамках такого подмножества Сети, как Multicast Backbone. Несмотря на доступность, технологию IP Multicast можно смело отнести в разряд перспективных; однако, благодаря поддержке 65 производителей - членов инициативы IP Multicast Initiative (www.ipmulticast.com), эта перспектива становится реальностью весьма быстрыми темпами.

Короче говоря, когда дело касается передачи видео по сети, преимущества АТМ очевидны. Качество услуг встроено в этот протокол, и, таким образом, все устройства ATM, а также накопленный опыт в обеспечении качества услуг и жесткая конкуренция между производителями привели к оптимизации его характеристик. Щднако, многие из функций АТМ появляются одна за другой и у Ethernet/IP. Если вы готовы подождать, то переходить от Ethernet к ATM - как в случае решения от одного поставщика, так и собранного по частям - не имеет смысла, во всяком случае, ради поддержки видео в сети. Если вам этот вариант не подходит, ну что ж, тогда ATM - лучшее, что есть.

КАК ПОЛУЧИТЬ КАРТИНКУ?

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

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

СТАНДАРТ КАК ОН ЕСТЬ

T.120: суперстандарт

ITU-T (www.itu.ch) одобрил T.120 между 1993 и 1995 гг. Стандарт охватывает широкий спектр тем, в том числе взаимодействие систем различных поставщиков, обнаружение и исправление ошибок, многоадресную передачу (его расширение, поддерживающее IP Multicast, будет, как ожидается, ратифицировано в 1998 году), независимость от платформы, масштабируемость, прозрачность сети и даже независимость от приложения.

Стандарт разбит на несколько уровней. Верхний уровень составляют два протокола для приложений по проведению конференций: Т.126 для обмена и редактирования неподвижных изображений идельно подходит для электронных досок, а T.127 - для передачи любых типов двоичных файлов во время конференции.

Нижние уровни стандарта обеспечивают непосредственное проведение конференции. T.123 включает специфические сетевые транспортные протоколы для телефонной связи, ISDN и цифровых сетей с коммутацией каналов и пакетов. Вместе T.122 и T.125 определяют базовые программные сервисы и сам протокол передачи данных. T.125 описывает способ взаимодействия между приложениями, использующими протоколы T.126 и T.127. Стандарт управления конференцией T.126 позволяет организовать и проводить конференцию, вести учет приложений и узлов, обеспечивать защиту, а также он описывает "дирижера", или менеджера конференции.

Родственный стандарт, T.121, не являющийся частью базового стандарта T.120, определяет типичный шаблон приложения. Шаблон приложения предназначен для улучшения согласованности и взаимодействия T.120-совместимых приложений.

Семейство стандартов T.120 далеко от завершения. Так, ITU-T собирается стандартизовать поддержку ATM, frame relay и других технологий глобальных сетей. Другая группа ITU-T работает над T.130 - в настоящее время представляющий собой ряд рекомендаций, касающихся аудио/визуального управления мультимедийными конференциями. T.130 может использовать различные механизмы конференций, в том числе T.120 для поддержки конференций с обменом данными между несколькими участниками и H.320 для аудио/видеоконференций на базе ISDN.

АУДИО/ВИДЕО ФОРМАТ БЕЗ ПЕРЕРЫВОВ

Активный потоковый формат

Active Streaming Format (ASF) - это новый формат файлов, предложенный Microsoft. Он призван обеспечить потоковую доставку и синхронизированное воспроизведение различных типов мультимедийных файлов, в том числе видео, анимации, графики, аудио, MIDI-музыки и текста.

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

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

По утверждению Microsoft формат ASF способен заменить ряд традиционных форматов аудио/видеофайлов, таких как AVI той же Microsoft, QuickTime компании Apple, а также общеупотребительные MPEG-1 и MPEG-2. Для этой цели Microsoft предоставила предварительную версию ASF (поддерживаемую программным обеспечением потокового видео NetShow и видеоконференций NetMeeting) приблизительно 50 компаниям, в том числе Progressive Network, Intel и Adobe. Вторая версия черновой спецификации ASF была завершена 10 сентября 1997 года. По заявлению Microsoft, после внесения исправлений проект стандарта будет предоставлен международной организации по стандартизации, хотя, какой конкретно, пока неизвестно. Дополнительную информацию об ASF можно найти по адресу: www.microsoft.com/netmm/asf.