Джонатан Эйнджел

Видео через Web, широковещание в Intranet и видеоконференции объединяются в 'делающих все это' пакетах.

С тех пор как в начале 90-х Apple Computer разработала первую технологию цифрового видео QuickTime, пользователи могут видеть на экранах своих компьютеров нечеткие изображения размером с почтовую марку. В последнее время видеоизображения стали больше в размере, они меньше дергаются и приблизились по качеству к телевизионному вещанию. (Хотя если взять стандарт NTSC для видео в Соединенных Штатах, то это вряд ли можно будет считать комплиментом.)

Network Magazine уже рассматривал видеосерверы в прошлом, так что же заставило нас вернуться к данной теме еще раз? Чтобы ответить на этот вопрос, я вынужден использовать (не меньше трех раз) слово, столь часто не оправдывавшее своего значения в прошлом, что его следовало бы навсегда поместить обратно в словарь. Что же это за слово? Конечно, конвергенция.

Во-первых, это конвергенция пропускной способности. До этого года громадное несоответствие между возможностями домашних (в лучшем случае соединение на 56 Кбит/с) и корпоративных (с локальными сетями на 10 Мбит/с) пользователей означало, что производители видеосерверов не могли в равной мере удовлетворить всех и каждого. Такие компании, как RealNetworks (http://www.real.com), применяли сильное сжатие видео для подачи его 'через тонкую соломинку' домашним пользователям. С другой стороны, такие производители, как Cisco Systems и Starlight Networks (http://www.starlight.com), обеспечивали изображение гораздо более высокого качества, но ориентированное на сети Intranet.

Теперь же благодаря распространению кабельных модемов и адаптеров цифровой абонентской линии (Digital Subscriber Line, DSL) домашние пользователи в США могут получить пропускную способность, сравнимую с той, что доступна в разделяемых сетях Ethernet. Такое изобилие пропускной способности создает гораздо более широкий рынок для любого конкретного видеосервера. Однако не менее важно то, что провайдерам информационного наполнения достаточно создать только одну версию видеоклипа для предоставления как внутри, так и за пределами компании.

Во-вторых, это конвергенция ПК и других типов устройств для просмотра. Из-за высоких требований к вычислительной мощности раньше только персональные компьютеры на базе процессоров Pentium, Power PC или RISC были достаточно мощными для декомпрессии и рендеринга потокового видео. Теперь же это вполне по силам и телевизионным приставкам.

Например, подразделение WebTV компании Microsoft (http://www.webtv.com) заявило в июне 1999 года, что в результате модернизации программного обеспечения ее устройства будут совместимы с кодеком G2 от RealNetworks. Будущие устройства WebTV на базе Windows CE будут поддерживать RealPlayer G2, т. е. по функ-циональности они станут еще ближе к ПК. В том же месяце Panja (http://www.panja.com) объявила о 'шлюзе для развлечений', подключаемом к Internet через кабельный модем Cisco. Это устройство будет способно передавать информационное наполнение в стандартах RealAudio, RealVideo и MPEG на обычные телевизоры и стереосистемы.

TiVo (http://www.tivo.com) продает по цене 500 долларов устройство с процессором Power PC, интегрированным кодированием/декодированием MPEG и специализированным жестким диском Quantum с поддержкой одновременного чтения и записи. Такие устройства должны в конечном итоге заменить видеомагнитофоны и популяризовать потоковое видео. Они должны также способствовать расширению рынка видеосерверов, который, по данным Frost&Sullivan (http://www.frostandsullivan.com), составлял в 1998 году 532 млн долларов (на 45% больше, чем в 1997 году).

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

ЧТО ТАКОГО ОСОБЕННОГО В ВИДЕОСЕРВЕРАХ?

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

Что касается аппаратного обеспечения, то требования во многом те же самые, что и для любого другого сервера с высокими объемами трафика. Это означает, что он должен иметь большой объем оперативной памяти, по возможности несколько процессоров и оптимизированную для передачи файлов дисковую подсистему. В частности, сервер может быть оснащен контроллерами RAID со своими собственными процессорами ввода/вывода, такими, как i960 от Intel. При наличии драйверов, написанных в соответствии со стандартом интеллектуального ввода/вывода (Intelligent I/O, I2O), эти контроллеры позволяют повысить производительность на 60% и более. Наиболее загруженные серверы могут быть даже включены в сеть устройств хранения (Storage Area Network, SAN). Главное отличие между обычным сервером и видеосервером состоит в программном обеспечении. Проще говоря, стандартные серверы HTTP или ftp предназначены для обеспечения надежной загрузки. Они используют протокол TCP, нумерующий каждый пакет таким образом, что данные могут быть правильно восстановлены (собраны) получателем. TCP гарантирует, что в конечном итоге адресат получит все пакеты, так как при потере какого-либо из них он может запросить повторную передачу; кроме того, TCP применяет механизм контроля потока для ограничения скорости соединения, когда сеть близка к насыщению.

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

По этой причине большинство производителей видеосерверов отказывается от использования HTTP и TCP в пользу UDP в качестве базового протокола для транспорта пакетов с потоковыми данными. 'Быстрый и опасный' UDP не гарантирует доставку пакетов; он просто пытается доставить поток как можно быстрее. Именно отсюда потоковое видео получило свое определение.

Содержимое пакетов UDP очень трудно распознать, поэтому некоторые брандмауэры по-прежнему настроены на блокирование их по умолчанию (см. врезку 'Почему такой плохой прием?'). В этом случае многие видеосерверы могут при необходимости вернуться вновь к HTTP. Однако HTTP не позволяет эффективно реализовать такие функции, как быстрая перемотка вперед и назад, а также поиск. И конечно, аудио/видеопотоки могут быть очень длительными: например, программа новостей может длиться 30 минут. В то же время часто пользователям в действительности бывает необходимо посмотреть только какой-то отрывок из программы (скажем, только спортивные новости).

Мы рассмотрим то, как работают видеосерверы, на примере двух поколений продуктов от RealNetworks. В первом поколении (версии до RealServer 5.0) клиентское программное обеспечение пользователя (RealPlayer) инициирует связь посредством установления полнодуплексного соединения TCP. Поначалу это соединение служит для передачи на RealPlayer таких данных о потоке, как текстовая информация об его названии, продолжительности и авторских правах на клип. После того как первоначальное соединение установлено, RealServer 5.х создает симплексный канал UDP и задействует его для доставки данных плейеру.

В RealSystem 5.х соединение TCP могло использоваться плейером для передачи команд RealServer с помощью собственного протокола Progressive Networks Media (PNM), когда были активизированы такие функции, как кнопки 'воспроизведение' и 'стоп'. Однако в 1998 году RealNetworks представила RealSystem G2. Последняя опиралась на стандартные протоколы в большей степени, чем ее предшественница, и была призвана улучшить взаимодействие между сервером и плейером. G2 позволяет реализовать такие функции, как 'утоньшение потока', другими словами, переключение на лету в случае перегрузки сети на требующее меньшей пропускной способности информационное наполнение.

Взаимодействие с G2 начинается все так же с установления полнодуплексного соединения TCP, обычно через порт 554. Однако на этот раз оно использует потоковый протокол реального времени (Real-Time Streaming Protocol, RTSP), определенный как протокол управления прикладного уровня в RFC 2326. RTSP реализует стандартные механизмы 'поиска' по времени в клипах. Он может также контролировать доставку содержимого при многоадресной рассылке.

Как и ранее, аудио/видеоданные доставляются плейеру через симплексный канал UDP, но на этот раз по протоколу передачи в реальном времени (Real-Time Transfer Protocol, RTP). Данный протокол является одновременно предложением по стандарту IETF (RFC 1889) и стандартом ITU (H.225.0). RTP предусматривает отметки о времени, порядковую нумерацию и другие механизмы для правильного упорядочивания поступающих пакетов. Заголовки могут содержать идентификаторы типа, определяющие формат полезной нагрузки и схемы кодирования/сжатия. Некоторые типы полезной нагрузки определены в RFC 1890 (в том числе аудио- и видеопотоки MPEG-1 и MPEG-2, а также видеопотоки JPEG и H.261). Другие типы полезной нагрузки могут быть введены посредством спецификации расширяемого формата полезной нагрузки.

Помимо соединений TCP и RTSP сервер RealServer G2 использует еще и третий полнодуплексный канал UDP для протокола управления трафиком реального времени (Real-Time Control Protocol, RTCP). Он призван обеспечить обратную связь относительно качества доставки данных по протоколу RTP. RTCP разработан таким образом, что управляющий трафик никогда не превышает 5% от общего трафика во время сеанса. Поэтому такие функции, как утоньшение потока, могут быть реализованы без контрпродуктивного TCP.

Большинство коммерческих продуктов для видеосерверов в настоящее время использует RTSP, RTP и RTCP или по крайней мере UDP. Другое важное отличие между видеосерверами состоит в наличии или отсутствии поддержки ими трансляции вживую с помощью многоадресной рассылки.

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

ПОТОКОВОЕ ВИДЕО ДЛЯ ГРОМАДНОГО МИРА

Хотя производители видеосерверов все больше склоняются к единой модели на все случаи жизни, все же вам придется принять решение относительно того, кому вы собираетесь предоставлять потоковое видео - всем пользователям Internet вообще или же узкой группе пользователей в сети с известной высокой пропускной способностью. Если вы ставите перед собой первую цель, то будет чистым безумием отказаться от использования одного из доминирующих серверов RealNetworks, Microsoft или Apple. Имеющиеся в этих продуктах кодеки способны поддерживать такие медленные каналы, как модемное соединение на 28,8 Кбит/с. Они также могут передавать только аудиопотоки, когда это единственное, что вам необходимо. Их главная сила в том, что многие домашние пользователи имеют совместимое программное обеспечение плейера, так что они могут просматривать любое видео без загрузки новых программ.

Мы уже обсуждали RealServer G2 от RealNetworks. Бесспорно крупнейший игрок в области потокового мультимедиа, RealNetworks контролирует около 85% рынка. (Даже Microsoft была вынуждена обеспечить совместимость своего Windows Media Player с RealAudio и RealVideo, хотя он до сих пор не поддерживает всех кодеков G2.) Сервер и клиент G2 первыми стали использовать язык синхронизированной интеграции мультимедийной информации (Synchronized Multimedia Integration Language, SMIL) - стандарт Консорциума World Wide Web (W3C), родственный расширенному языку разметки (Extensible Markup Language, XML). SMIL позволяет создать текстовый файл с метаданными для управления отображением самых разных типов потокового мультимедиа, в том числе видео, аудио, текста, неподвижных изображений и т. п.

Помимо уже упоминавшихся возможностей утоньшения потока G2 имеет также модульную архитектуру, позволяющую расширять функциональность сервера и плейера. Например, подключаемые модули от Digital Broadcasting (http://www.bitcasting.com) обеспечивают поддержку аудио MP3 и видео MPEG-1, хотя эти кодеки отсутствуют в самой RealSystem.

Переход на новые и усовершенствованные кодеки обычно предполагает необходимость загрузки и установки конечными пользователями нового программного обеспечения плейера. К счастью, RealPlayer G2 может сам определить, когда клиенту требуются новые кодеки, и загрузить их автоматически. Подобная возможность также предусмотрена в Windows Media Player компании Microsoft, входящем в общую архитектуру мультимедийных технологий Windows Multimedia Technologies (WMT), известную как NetShow. Microsoft собирается включить поддержку потокового мультимедиа в Windows 2000 Server (см. статью 'Windows 2000: ответы на вопросы' в предыдущем номере).

Microsoft утверждает, что WMT масштабируется до большей пропускной способности и скоростей передачи кадров, чем RealSystem G2, и что она лучше работает на клиентах, где имеется всего лишь процессор Pentium на 133 МГц. Я никак не буду комментировать это заявление, а скажу лишь, что сам факт, что Microsoft предоставляет собственный потоковый сервер, трудно игнорировать. Если вы используете Windows 2000, тогда он имеет смысл. (Однако, в отличие от RealSystem G2, WMT недоступен ни на какой другой платформе.) WMT тесно интегрирована с функциями защиты Windows 2000 Server и готова для реализации платных просмотров и управления цифровыми правами на загружаемые аудиофайлы.

Важным моментом для авторов информационного наполнения является то, что Advanced Streaming Format (ASF) объединяет содержимое и метаданные в одном файле. Это ведет к уменьшению числа требующих контроля файлов в случае сложных мультимедийных презентаций. Однако для редактирования метаданных ASF вам придется вычленить файл заголовка, отредактировать управляющий текст и затем заново вставить его в мультимедийный файл.

Третий часто встречающийся в Internet формат - это QuickTime компании Apple. Файлы QuickTime пользуются популярностью благодаря совершенству инструментария для создания информационного наполнения в этом формате, к тому же они уже давно распространяются через Web с помощью ftp и HTTP. С появлением X QuickTime Streaming Server в 1999 году QuickTime стал поддерживать истинное потоковое мультимедиа (и живое вещание) с помощью RTP и RTSP. По утверждению Apple, Macintosh Server G3 на 400 МГц способен обслуживать 1000 пользователей одновременно.

ТОЛЬКО ДЛЯ ШИРОПОЛОСНОЙ ПЕРЕДАЧИ

При всем уважении к RealNetworks, Microsoft и Apple, их продукты не предназначены для тех потребителей, которым требуется видео телевизионного качества. Здесь-то и вступают в игру специализированные видеосерверы.

Линия продуктов ixJet от 3CX (http://www.3cx.com), например, базируется на NT, но использует специальную видеоориентированную файловую систему для повышения производительности. Streaming Server способен предоставлять до 100 потоков MPEG одновременно. Среди поддерживаемых форматов MPEG-1, MPEG-2, QuickTime и ASF. LiveServer поддерживает многоадресную передачу, аппаратное кодирование MPEG и скорости до 3 Мбит/с. Кроме того, 3CX предлагает полезное приложение для Windows под названием ixJet Explorer. С его помощью пользователи Intranet могут найти и просмотреть имеющееся видео. Таким образом, администратору нет необходимости редактировать страницу Web всякий раз при размещении на сервере нового видео.

Adaptive Media (http://www.adaptivemedia.com) продает Envision Enterprise 2.0, сервер потокового мультимедиа для реализации совместных инженерных проектов. Среди уникальных особенностей системы - возможность объединения в одном потоке видеофайла, файлов САПР и нескольких звуковых дорожек в формате MPEG или WAV. Идея состоит в том, что клиенты могут слушать сопроводительный текст на выбранном языке или с требуемым уровнем технической детализации.

Arachnid от Alex - это программно-аппаратный комплекс старшего класса с несколькими процессорами и массивом RAID на базе Fibre Channel (http://www.alex.com). Как утверждает производитель, его продукт работает с клиентами любых типов - от телевизионных приставок до сетевых компьютеров и ПК. IP-клиенты поддерживаются с помощью RTP, RTCP и RTSP; кроме того, когда необходимо, Arachnid может работать непосредственно по ATM.

IP/TV от Cisco также базируется на стандартах и NT. Он способен предоставлять потоковое видео по запросу, осуществлять многоадресную передачу вживую или плановое повторное вещание на конкретную группу пользователей. Полномасштабная реализация IP/TV включает Control Server, Broadcast Server и Archive Server, выполняющихся на трех и более ЦПУ. Через интерфейс на базе браузера администратор может управлять всем вещанием и проверять факт передачи информации о программах на клиентские настольные системы. Система предоставляет также статистику о зрителях, т. е. она позволяет узнать, кто именно смотрел данную программу. Основанная Ральфом Унгерманном компания FVC (http://www.fvc.com) занимается Internet следующего поколения (Next Generation Internet, NGI). Она предлагает коммутаторы доступа в глобальную сеть и другие продукты тем, кого сильно тревожит влияние видео на их инфраструктуру. Она также продает несколько аппаратных/программных серверных продуктов для передачи потоков H.261, H.263, MPEG-1 или MPEG-2 по сетям IP или ATM. Ее I-Relay представляет собой proxy-сервер для вещания многоадресных программ в сетях IP, где многоадресная рассылка не поддерживается.

InfoValue (http://www.infovalue.com) представила свой видео- сервер на базе NT еще в 1996 году. Сегодня она продает продукт для предоставления видео по запросу QVOD. Один ее сервер способен обслуживать потоки общей пропускной способностью до 750 Мбит/с. Для достижения такой производительности он реализует собственный протокол быстрого потокового видео (QuickVideo Streaming Protocol, QVSTP). Нестандартный плейер устанавливать не требуется, так как клиентское программное обеспечение содержит драйвер, автоматически вызывающий QVSTP для обслуживания загрузки файлов с расширениями .AVI, .MPG, .WAV, .MOV и другими мультимедийными расширениями.

Нестандартные плейеры получают видеопотоки MPEG-1 и MPEG-2 от отдельного QuickVideo Multicast Server. Здесь я хотел бы отметить следующие любопытные моменты: интегрированную поддержку расписания программ и необычную возможность повтора видеофрагмента даже во время живого вещания. При декодировании во время вещания потоки записываются во временный файл, в результате плейер может вернуться назад к любому просмотренному фрагменту, когда бы пользователь того ни пожелал.

Optivision (http://www.optivision.com) специализируется исключительно на рынке MPEG. Эта компания предлагает видеосервер на базе NT, но ее коньком является так называемый 'сетевой кодек' - подключаемое к сети (через порт Ethernet на 10/100 Мбит/с или ряд интерфейсов глобальной сети) устройство для преобразования видео в формате NTSC или PAL в формат MPEG. Устройство поддерживает 64-разрядную файловую систему, поэтому оно не страдает от свойственных Windows ограничений.

Silicon Graphics предлагает мощный комплекс в виде своего программного обеспечения WebForce MediaBase и аппаратного сервера Origin (последний масштабируется до 64 процессоров). Первоначально WebForce MediaBase предназначалось для предоставления видео в форматах MPEG-1 и MPEG-2 с пропускной способностью до 8 Мбит/с; однако начиная с версии 3.1 он включает интегрированный сервер RealSystem G2. Таким образом, одно и то же решение может поддерживать как 'широкополосных' пользователей Intranet, так и 'узкополосных' клиентов Internet (http://www.sgi.com).

Интегрированные серверы RealSystem G2 предлагаются также Sightpath (http://www.sightpath.com). Ее готовые к работе устройства способны обслуживать приблизительно 20 пользователей каждое. Эти дешевыми устройствами можно управлять удаленным образом из браузера Web. Они предназначены для размещения в стратегических точках сети поблизости от коммутирующих устройств и содержат уже упоминавшиеся в статье подключаемые модули Digital Bitcasting.

Приобретенная в 1998 г. компанией PictureTel (http://www.picturetel.com) Starlight Networks продолжает выпускать свою заслужившую высокую репутацию линию серверов, в том числе StarCast - продукт для вещания видеоконференции сотням зрителей посредством многоадресной рассылки по IP. Недавно появившийся PictureTel eVideo Application Server представляет собой продукт на базе NT и предназначен для объединения серверов потокового видео (Starlight, Microsoft, RealNetworks), текстовых интерактивных диалогов и баз данных с результатами анализа. События могут вещаться вживую и записываться для последующего воспроизведения.

VCON (http://www.vcon.com) - еще одна компания, объединяющая видеоконференции и потоковое видео. Ее программное обеспечение MeetingPoint 4.0 позволяет смотреть конференцию как клиентам видеоконференции, так и клиентам потокового видео IP/TV компании Cisco (естественно, первые могут принимать непосредственное участие в обсуждении, а вторые - только смотреть и слушать). MeetingPoint имеет также интегрированную поддержку голоса по IP. Таким образом, пользователи могут участвовать в конференции с помощью двустороннего видео, одностороннего видео или только аудиоканала.

Vsoft (http://www.vsoft.com) предлагает VideoClick 2.0. Этот сервер выполняется на платформах NT и Sun и предоставляет потоковое видео в форматах MPEG-1 и MPEG-2 клиентам в сетях Intranet. Как и продукт InfoValue, он позволяет клиентам останавливать просмотр и осуществлять обратную перемотку даже 'живых' потоков. Кроме того, он имеет такую уникальную функцию, как возможность аннотирования пользователем любого видеокадра посредством текстовых, графических или голосовых комментариев. Аннотации хранятся отдельно в ODBC-совместимой базе данных.

Наконец, такой производитель продуктов для видеоконференций, как VTEL (http://www.vtel.com), предлагает решение для потокового видео в Internet под названием TurboCast. Опирающееся на технологию, приобретенную VTEL вместе с Vosaic ранее в этом году, TurboCast направляет видеопотоки апплетам Java. Как следствие, вещание может приниматься ПК, Macintosh, UNIX и даже некоторыми карманными устройствами.

НЕ ЗАМОЧИВ НОГ...

Можно не сомневаться, что Internet-видео - для демонстрации продуктов, презентаций и множества других целей - вскоре станет неотъемлемой частью большинства серверов Web точно так же, как изображения в формате GIF или JPEG сегодня. Тем временем Intranet-видео вытеснит корпоративные тренинги, совещания и те видеомагнитофоны, что сегодня тихо примостились в уголке на передвижном столике.

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

Прокрустово ложе

Есть ли что-либо более вызывающее опасения, чем видео, когда речь идет о потребляемой пропускной способности? Для каждого отображаемого на экране пиксела цифрового видео требуется хранить 24 бита информации с описанием его цвета. При той же частоте кадров, что и для видео в стандарте NTSC, этот пиксел должен меняться 30 раз каждую секунду. А если вы хотите иметь полноэкранное изображение, то требуется хранить информацию о 640 пикселах по горизонтали и 480 пикселах по вертикали. Общий объем памяти, необходимый для хранения одной секунды несжатого видео, составляет таким образом:

24 (бит) * 30 (кадров) * 640 (пикселов) * 480 (пикселов) = 221 Мбит.

И это только для немого видео. Но кому нужно изображение без звука? Таким образом, место на диске необходимо будет выделить и для аудиоданных.

Наиболее распространенный способ уменьшить объем хранимого цифрового видео - это урезать размер кадра. В случае изображения размером 320 на 240 пикселов их число уменьшается в четыре раза по сравнению с изображением размером 640 на 480. При сокращении частоты кадров наполовину качество воспроизведения движения остается приемлемым, тогда как объем необходимой памяти снижается еще в два раза. Однако вам по-прежнему требуется свыше 3 Мбайт на диске для записи каждой секунды видео, в результате короткий видеоклип продолжительностью в минуту будет занимать на диске целых 180 Мбайт.

К счастью, видеоинформация может быть сжата двумя разными способами (вообще же, конкретных способов больше, каждый из них отличается своими особенностями, но в целом они сводятся к двум нижеописанным). Оба метода сжатия видео ведут к некоторой потере информации, так как они предполагают исключение как можно большего объема данных. Первый метод - внутрикадровое сжатие. Каждый кадр делается насколько возможно меньше по размеру с помощью тех же технологий, что ранее традиционно применялись для компьютерной графики, в том числе Run Length Encoding (RLE, как в стандартном растровом формате Windows), JPEG и более новых - фрактального сжатия и теории малых волн.

Второй метод - межкадровое сжатие. При этом методе первый кадр любого видеоклипа или нового эпизода (съемка с другой камеры, изменение сцены и т. д.) записывается с максимально возможной детализацией. Этот кадр затем становится ключевым. После определения ключевого кадра последующие хранятся в виде 'дельта-кадров'. Дельта-кадры содержат информацию только об изменившихся по отношению к ключевому кадру пикселах (или, в зависимости от используемой конкретной схемы сжатия, по отношению к предыдущему дельта-кадру). Применяемые вместе, эти методики позволяют радикально уменьшить объем цифрового видео. Именно они позволили добиться того, что полнометражный фильм умещается на видеодиске DVD. Кодеков для компрессии/декомпрессии видео существует множество, в том числе H.261, MPEG-1, MPEG-2 и MPEG-4 (предварительный стандарт). Каждый из них обычно рассчитан на определенную пропускную способность. Однако не надейтесь, что полноэкранное видео можно будет без помех смотреть по модемному соединению.

Почему такой плохой прием?

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

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

'Многие компании придерживаются политики не менять заданные по умолчанию параметры брандмауэра или же не открывать никакие порты, пока пользователи не попросят об этом', - объясняет Снауден Армстронг, менеджер по продуктам в RealNetworks. Практически все поставщики брандмауэров поддерживают Real-Time Streaming Protocol (RTSP), но 'они не озаботились созданием сверхдружелюбной конфигурации, чтобы администраторы могли активизировать его поддержку одним щелчком мыши. Мы работаем над тем, чтобы брандмауэры поставлялись полностью сконфигурированными для RTSP и требовалось только чье-либо решение для их включения'.

Используемый в RealServer G2 и QuickTime 4 протокол RTSP обычно работает через порты 554 и 7070 с данными RTSP/TCP и через порты 6970-7170 - с поступающими данными RTP/UDP. Альтернативные конфигурации, в том числе с proxy-серверами, также возможны. Точку зрения пользователей по этому вопросу можно узнать на http://www.broadcast.com/faq/tech_faq.stm/. Помощь администраторам брандмауэров предлагают RealNetworks на http://service.real.com/firewall/adminfw.html и Apple на http://www.apple.com/quicktime/resource/qt4/us/proxy/.