Сегодня большая часть потокового аудио и видео в Internet носит исключительно развлекательный, потребительский характер, основное их содержание составляет музыка, реклама и т. п. Однако все большее число компаний начинает использовать потоковое мультимедиа как инструмент бизнеса. Стимулом к этому служат ситуации, подобные трем описанным ниже.
Например, руководитель компании хочет напрямую обратиться к служащим, партнерам и основным заказчикам для объяснения основных положений стратегии компании. Традиционно это делалось посредством спутникового вещания. Если же наряду с телевизорами вещание охватит и персональные компьютеры, то руководитель сможет донести информацию до большего числа людей удобным для них способом.
Заказчик обращается в службу технической поддержки с вопросом, как соединить Икс с Игреком. Объяснение на словах займет 10 мин. На Web-узле компании есть пятиминутный видеоклип, но заказчику придется потратить 20 мин. на его скачивание.
Специалисты компании по продажам и маркетингу должны быть осведомлены о последних новинках в продукции компании, но они рассеяны по всему земному шару, а менеджерам по продуктам необходимо провести с ними короткий инструктаж. Расходы и транспортные издержки на то, чтобы собрать всех этих людей в одном зале, выглядят обескураживающе.
Привлекательность потоковой передачи данных очевидна: аудио и видео приковывают внимание людей и позволяют представить информацию в легко воспринимаемом виде. Подача материала в аудио- и видеоформате очень эффективна при торговле, рекламе, обучении и инструктировании. Для компаний это означает увеличение дохода, большую эффективность и меньшие затраты на доставку информации. К сожалению, получение аудио- и видеоинформации для определенной аудитории может оказаться весьма непростым и дорогостоящим делом. Поэтому многие компании заинтересованы в использовании Internet, в силу невысокой стоимости его услуг и повсеместной распространенности.
Простая загрузка файлов из сети недостаточно хороша для аудио- и видеоданных даже с учетом того, что клиентские соединения становятся быстрее. Например, по словам Санджая Сриваставы, вице-президента подразделения Acamai по корпоративному бизнесу, средняя эффективная пропускная способность канала связи с пользователями Интерактивной мультимедийной службы (Interactive Media Services, IMS) через ее Сеть доставки информационных ресурсов (Content Delivery Network, CDN) составляет 70 Кбит/с. Но даже такие скорости недостаточны для загрузки видеофайлов, размер которых часто составляет десятки мегабайт, как, впрочем, и аудиофайлов, объем которых равен по меньшей мере нескольким мегабайтам.
ПОТОКОВАЯ ТЕХНОЛОГИЯ ПРИХОДИТ НА ПОМОЩЬ?
Решение проблемы больших файлов существует вот уже несколько лет: потоковая технология. Используя потоковый мультимедиа-плейер, например QuickTime компании Apple, Media Player компании Microsoft или RealPlayer компании RealNetworks, пользователь может воспроизвести видео- и/или аудиофайл спустя несколько секунд после поступления первых битов потока на его компьютер. Эти плейеры также поддерживают такой режим работы, как «видео по требованию», при котором на потоковом сервере хранится копия информационного ресурса, которую клиент может затребовать в любой момент.
Базовая технология потоковой передачи данных относительно недорога. Поставщик информационного наполнения должен оцифровать необходимый информационный ресурс и настроить сервер в расчете на определенных клиентов, но при этом, без учета затрат на персональные компьютеры, суммарные расходы поставщика информационного наполнения на аппаратное и программное обеспечение составляют, как правило, тысячи долларов на один потоковый сервер. Например, RealNetworks оценивает аппаратный и программный пакет для потоковой передачи данных в пределах 3000 долларов. Все, что при этом требуется клиентам, — приобрести программное обеспечение (плейер, как правило, распространяется бесплатно или стоит недорого) и звуковую карту (стоимость которой варьируется в пределах от 20 до 150 долларов).
Однако до недавнего времени потоковая передача данных по Internet в бизнесе использовалась лишь в редких случаях. Из-за ограниченной пропускной способности изображение делалось дерганым, а недостаточная надежность приводила к пропуску видеокадров или исчезновению звука. Потоковая передача данных по Internet была затруднена также из-за несогласованности качества обслуживания (Quality of Service, QoS), что вызывало различные виды искажений при воспроизведении видео- и аудиофайлов.
Однако ситуация меняется. Заложенный в потоковую передачу данных потенциал побуждает поставщиков попытаться заставить ее работать в бизнесе. Взгляните на эти цифры: согласно информации Кристиана Перея, президента Perey Research & Consulting, в 1999 г. американские компании потратили от 600 до 700 млн долларов на продукцию для реализации потоковой передачи данных. К 2003 г., говорит Перей, эта цифра должна вырасти до 4 млрд долларов. Рынок сетевых услуг потоковой передачи данных, по прогнозам Internet Research Group, будет расти даже быстрее, с теперешнего значения в 100—150 млн долларов до порядка 2,5 млрд в 2004 г.
По оценке Перея, весь рынок потоковой передачи данных будет к 2004 г. составлять 22 млрд долларов в год. Эта цифра включает расходы на преобразование данных или их сбор, аппаратную и программную инфраструктуру, доступ к сети и транспортные сервисы, а также на такие услуги, как установка оборудования и ПО и техническая поддержка. Она включает применение потоковой передачи данных в развлекательных и потребительских приложениях.
Никто не возьмется точно предсказать, какая доля прогнозируемого роста может быть отнесена на счет бизнес-приложений. Однако поставщики и аналитики согласны с тем, что сейчас в бизнес-секторе происходит «брожение». По словам Эрика Вулфорда, вице-президента по маркетингу продукции и развитию бизнеса компании-разработчика программного обеспечения для обеспечения широкомасштабной потоковой передачи данных по Internet в реальном режиме времени FastForward Networks, уже сейчас спрос делится примерно поровну между приложениями для бизнеса и развлечений.
Сегодня сфера сбыта и маркетинга является, возможно, основной областью применения потокового мультимедиа. Среди других быстро развивающихся приложений для бизнеса — корпоративные коммуникации, обучение и клиентская поддержка.
Как говорит ведущий аналитик Jupiter Communications Питер Кристи: «Распространение бизнес-приложений будет носить взрывообразный характер». Каждый пресс-релиз и всякий маркетинговый материал должны быть представлены в потоковой форме как в реальном времени, так и «по требованию».
Учитывая все это, можно сказать, что поставщикам программного обеспечения и услуг предстоит решить три основные проблемы: предоставление услуг, мониторинг производительности и управление информационным наполнением. Ниже мы рассмотрим каждый вопрос отдельно. (Заметим, что услуги и сопровождение, также весьма важные вопросы, выходят за рамки этой статьи.)
ПРОБЛЕМЫ ИНФОРМАЦИОННОГО ОБМЕНА
Для потокового трафика путь от поставщика информационных ресурсов до клиента оказывается менее надежным, чем в случае обычных данных, например таких, как страницы Web или загружаемые файлы. Недостаточная пропускная способность и низкий QoS, только замедляющие обычный трафик, могут привести к полному разрыву потокового трафика без каких-либо надежд на его восстановление.
Большое внимание уделяется «последней миле» — от точки присутствия ISP до клиента, где все большее значение приобретают технологии наподобие цифровых абонентских линий (Digital Subscriber Line, DSL) (см. статью Р. Свитта «DSL: благословение или проклятие» в апрельском номере LAN за 2000 г.). Не менее важны, однако, и усилия по обеспечению потоковой передачи через остальную часть Internet.
Узлы обмена трафиком между различными ISP являются своего рода фокальными точками, где концентрируется большинство проблем Internet. Здесь заторы трафика и очереди пакетов — типичная ситуация. По словам Вулфорда, при возникновении каких-либо проблем потеря от 20 до 30% пакетов в этих точках является обычным делом. А это катастрофа для потокового видео.
Существующая система взаимных отношений в Internet препятствует попыткам ее преобразования. Именно эта проблема больше всего волнует сейчас ISP и поставщиков информационного наполнения, так как им нужны гарантии, что информация будет доставлена с приемлемым уровнем производительности, надежности и QoS.
НА КРАЮ
Пограничное кэширование приобретает все большую популярность как средство решения проблемы с узлами обмена трафиком. При пограничном кэшировании содержимое узла Web копируется на компьютер поблизости от конечного пользователя, когда информационный ресурс запрашивается пользователем в первый раз. Последующие запросы на тот же ресурс обрабатываются ближайшим компьютером, что обеспечивает более быстрый и надежный доступ, так как при этом магистраль Internet и ее узлы обмена трафиком оказываются не задействованы. Определение «пограничный» указывает на тот факт, что кэш расположен на краю сети провайдера Internet в его точке присутствия, куда подведены линии доступа пользователя.
Примерами программных продуктов для пограничного кэширования могут служить специализированные устройства CacheFlow для кэширования Internet, MediaMall от InfoLibria, Traffic Server от Inktomi, NetCache от Network Appliance и Internet Caching System (ICS) от Novell.
Эти продукты используются провайдерами услуг CDN, например Adero, Akamai, Cidera, Digital Island, Edgix, iBEAM и Mirror Image. Перечисленные компании занимаются пограничным кэшированием в Internet, создавая наложенные сети для поддержки требовательных приложений, наподобие потокового мультимедиа.
Сети CDN, в свою очередь, продают свои услуги поставщикам информационного наполнения, часто на одноразовой основе (например, когда некая компания намерена транслировать собрание акционеров). Стоимость включения Internet-трансляции в существующую спутниковую передачу обычно составляет порядка 5000—10 000 долларов.
СКАЗАНО — СДЕЛАНО
Помимо пограничного кэширования в целях обеспечения своевременности доставки и целостности потокового трафика в CDN могут использоваться другие приемы.
Одним из таких приемов является постадийная (hop-by-hop) ретрансляция. Этот прием позволяет минимизировать задержку и повысить эффективность повторной передачи аудио- и видеоматериала в реальном времени. Часто в сетях с большим числом транзитных маршрутизаторов повторная передача имеет ограниченную эффективность для потоковой технологии, так как повторно переданный материал прибывает после того, как аудиофайл или видеоклип был воспроизведен клиентом. Это происходит потому, что он поступает от потокового сервера. При использовании постадийной ретрансляции повторную передачу осуществляет некое промежуточное устройство, так что ретранслируемые пакеты следуют по более короткому пути (через меньшее число транзитных узлов) и поэтому прибывают с меньшей задержкой.
Другая возможность заключается в организации многоадресной рассылки на прикладном уровне. Если обычно потоковые серверы направляют каждому получателю отдельный поток, то при многоадресной рассылке всякий раз, когда это возможно, по магистрали передается один поток. Концептуально данный подход аналогичен групповой маршрутизации в IP, но на прикладном уровне. Приложением в этом случае является потоковый сервер. В CDN функциональность потоковых серверов реализуется в каждой из точек присутствия, чтобы поток мог исходить из любой точки сети.
Кроме того, пограничные серверы могут заново сформировать один почти совершенный поток из нескольких избыточных. Поскольку потоки направляются по различным маршрутам, то наиболее вероятно, что проблемы с прохождением того или иного потока будут возникать в разное время. В каждый момент времени, как правило, будет иметься по крайней мере один хороший поток.
Одним из примеров возможного решения проблем потоковой передачи с использованием как постадийной ретрансляции, так и многоадресной рассылки на прикладном уровне является сеть распределения мультимедиа (Media Distribution Network, MDN) компании FastForward Networks, схема которой приведена на Рисунке 1.
Главным компонентом этого решения является программное обеспечение MediaBridge для операционных систем Linux или Solaris. MediaBridge «запоминает» все, что проходит мимо (не задерживая поток), и может при необходимости осуществить повторную передачу. При этом MediaBridge отслеживает топологию сети в целях наиболее эффективной маршрутизации потоков. Если на одном узле обмена трафиком обычно теряется 20 или 30% от поступающих пакетов, то, по словам Вулфорда, MDN позволяет снизить долю потерянных пакетов до величины менее одного процента.
Сети CDN могут также решить проблему внезапного всплеска числа запросов, приводящих к перегрузке сервера Web. Такой поток запросов могут теперь обслужить многочисленные пограничные серверы кэширования вместо одного централизованного сервера.
В случае CDN — чем крупнее, тем лучше: большее количество серверов подразумевает большую информационную емкость, а также большую вероятность наличия сервера вблизи определенного клиента. Основные CDN находятся на стадии активного расширения. Akamai имеет сейчас свыше 4000 серверов и продолжает расти дальше. Тем временем компания Digital Island заявила, что в течение следующих двух лет она установит 8000 серверов Compaq ProLiant с Windows 2000, в результате чего имеющиеся у нее мощности должны увеличиться в 30 раз.
Пока еще неясно, в какой мере CDN действительно необходимы. «Время покажет, — говорит Сривастава. — Но посмотрите, что произошло в области компьютерных технологий. Радикальное увеличение производительности персональных компьютеров побудило пользователей задаться вопросом, когда появятся приложения, которые действительно могли бы использовать преимущества этой мощности? Такие приложения появились и заняли ведущее место в корпоративных сетях. Мы полагаем, что потоковая технология должна стать основой для общения между компаниями».
МОНИТОРИНГ ХАРАКТЕРИСТИК
Поскольку содержимое потока чрезвычайно чувствительно к доступной пропускной способности и QoS, качество воспроизведения, с точки зрения пользователя, тесно связано с такими низкоуровневыми характеристиками, как производительность, вариация задержки и количество потерянных пакетов. Таким образом, потоковым приложениям требуются системы мониторинга характеристик потока и услуги по отслеживанию этих характеристик. Подобный мониторинг предлагает целый ряд поставщиков программных пакетов и услуг.
Например, Mercury Interactive является поставщиком программного обеспечения и услуг тестирования и мониторинга сети. Ее услуга мониторинга Topaz ActiveWatch ориентирована на потоковую технологию. В июне 2000 г. компания Akamai заявила о своем намерении предлагать Topaz ActiveWatch своим клиентам. Большинство систем мониторинга производительности проводит измерения на пограничном сервере, поэтому они способны предоставить лишь косвенную информацию о проблемах на линии доступа или у самого клиента.
Молодая компания WebHancer решила снять это ограничение. Ее программный пакет Customer Companion, устанавливаемый на клиентских компьютерах, позволяет проводить измерение характеристик, их анализ, выдачу сообщений и оптимизацию. Ориентация на клиентов открывает путь к измерению сквозных характеристик и возможность предоставлять информацию относительно распределения клиентов в сети и об их действиях. (По утверждению WebHancer, измерения носят лишь статистический характер. Этот продукт не предназначен для сбора конфиденциальной личной информации.)
Customer Companion пересылает информацию на концентратор Assurance Hub для ее агрегации и составления отчетов. Возможности WebHancer предлагаются в качестве подписной услуги провайдера приложений (Application Service Provider, ASP), куда входит составление отчетов, выдача тревожных сообщений и диагностика при достижении пороговых значений. В будущем, с реализацией адаптации к скорости, WebHancer собирается обеспечить возможность доставки информационного наполнения в реальном масштабе времени в соответствии с параметрами доступа клиентских компьютеров и рабочими характеристиками сервера и узла Web. Сегодня такими функциями адаптации к скорости наделен потоковый плейер.
Новый пристальный интерес к низкоуровневым характеристикам поднимает вопрос о соглашениях об уровне сервиса (Service Level Agreement, SLA), гарантирующих, что определенные характеристики будут оставаться внутри согласованных границ. Однако SLA для CDN представляются слишком расплывчатыми и слабо соотносятся с впечатлениями пользователей.
Например, согласованная пропускная способность или QoS могут быть установлены относительно уровней исходного сервера. Это разумно, так как CDN не требует каких-либо изменений в исходном сервере и будет, естественно, давать разные результаты в зависимости от качества исходной передачи.
С другой стороны, при формулировке в относительных величинах SLA не обеспечивает корреляции ни с одним из конкретных уровней восприятия конечного пользователя. Проблемы с исходным сервером могут быть устранены, если провайдер информационного наполнения загрузит всю свою информацию на сервер CDN еще до первого обращения к нему конечного пользователя. Однако такой подход требует значительных затрат ресурсов CDN и не работает при трансляции в режиме реального времени.
SLA может быть сформулировано в терминах средних величин, рассчитываемых и усредняемых, например, за полный день. И снова это может отражать лишь наилучшие ожидания, учитывая непредсказуемый характер Internet. CDN может столкнуться с условиями, находящимися вне ее контроля, например такими, как перебои в функционировании сети, последствия чего для потокового трафика оказываются просто катастрофическими. При незначительных перебоях CDN часто может поддерживать потоковый трафик за счет использования избыточных путей; однако возможность крупномасштабных заторов в сети, затрагивающих все маршруты, нельзя полностью исключить. Таким образом, сколько-нибудь определенный прогноз — и, как следствие, гарантии — можно дать лишь в отношении усредненных рабочих характеристик.
К сожалению, качество восприятия пользователя в сильной степени зависит от вариаций задержки при доставке потоковой информации, которые не находят отражение в средней величине. Например, знание средней ежедневной производительности ничего не говорит о том, насколько сильно колеблется этот параметр от одного момента времени к другому.
SLA может фокусировать внимание исключительно на одном показателе, например на производительности. Многие CDN начались с доставки критических, непотоковых данных, для которых пропускная способность часто является хорошим индикатором качества восприятия услуги пользователем. Для потоковых данных производительность важна, но впечатления клиента тем не менее могут оказаться негативными, если, например, вариация задержки и/или потери пакетов слишком велики. CDN предпринимают усилия по ослаблению этих проблем, но все же в первую очередь они стремятся увеличить производительность.
Основная проблема состоит в том, что любой заданный поток в любое заданное время могут обрабатывать различные поставщики услуг Internet с разными уровнями возможностей обработки данных. Это делает невозможным предложение провайдерам информационного наполнения SLA, которые они предпочли бы иметь. Самое большее, что CDN могут гарантировать, — среднюю производительность, надежность и QoS по сравнению со стандартным сервером Web поставщика информации.
УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ НАПОЛНЕНИЕМ
Если компании приходится регулярно рассылать потоковые данные, то ей требуется нечто большее, чем просто система управления информационным наполнением. Как правило, управление начинается с реализации эффективного поиска и навигации путем создания метаданных для индексирования. Затем метаданные сохраняются на сервере приложений, в то время как видео — на видеосервере.
Метаданные часто создаются «вручную», но с увеличением объемов создание вручную становится неприемлемым: например, для эффективного индексирования изображения может потребоваться задать очень большой набор ключевых слов.
Поисковые системы мультимедийных данных представляют собой автоматизированный программный инструментарий для анализа видеоданных, при этом каждый кадр сравнивается с известными изображениями и вычисляется «схожесть» изображений. Такие программные средства способны фиксировать изменения в сцене и жестах и могут распознавать лица и фигуры ораторов, паузы и текст на экране. Они также создают и индексируют перевод голосовой информации в текстовую.
Индексирование видеоданных приводит к интенсивной загрузке ресурсов процессора. Кроме того, используемые при вычислении «схожести» изображения критерии (например, цвет, форма, структура и текстура) не раскрывают «смысл» изображения. Поэтому смысловой контекст способна установить только специальная экспертиза. По этим причинам многие компании поручают такую работу ASP.
По словам Перея, лидером в этой области является Virage, причем ей принадлежит больше половины американского рынка. Процесс SmartEncode компании Virage кодирует видео одновременно в несколько форматов (например, RealPlayer, Media Player, QuickTime и MPEG) и в расчете на разные скорости передачи, индексирует видеоданные, создает доступную для просмотра информационную панель «истории» изображений и дополнительно поддерживает ввод редакторских аннотаций с привязкой к отдельным кадрам в видеоряде. SmartEncode используется или в программном продукте VideoLogger компании Virage или в качестве «внешней» функции, доступной благодаря службе Virage Interactive.
Virage также предлагает поисковый видеосервер, Internet Video Guide, который позволяет осуществлять поиск по ключевым словам, сортировку по категориям, информативные описания и предварительный просмотр. Он поддерживает форматы RealPlayer, Windows Media Technologies и QuickTime. (На Рисунке 2 показан обычный экран поиска Internet Video Guide.)
ПОКАЖИТЕ МНЕ ДЕНЬГИ
Процесс управления информационными ресурсами нацелен на получение дохода. Обеспечение возможности поиска и навигации является необходимым начальным шагом на пути к продаже информационного наполнения.
Excalibur Technologies является разработчиком продуктов управления информационными ресурсами. К тому моменту, когда вы будете читать эти строки, компания будет, по всей видимости, переименована после объединения с Interactive Media Services (IMS). IMS специализируется на вопросах защиты информационного наполнения и текстового аннотирования аудио- и видеоданных. Новая компания, 60% которой будет принадлежать акционерам Intel, а 40% — Excalibur, собирается объединить систему поиска с управлением знаниями и технологиями IMS. Новая компания будет предлагать услуги владельцам прав собственности на определенные аудио- и видеоданные, например отснятые спортивные состязания и развлечения. Вместе с тем, Excalibur по-прежнему будет продавать свои собственные технологии (для индексирования, поиска, восстановления и управления мультимедийными данными) в виде программных продуктов.
Технология управления информационным наполнением могла бы позволить более эффективно с точки зрения затрат продавать информацию, менее чем за традиционные полчаса или час. По словам Перея, «будущее потоковой индустрии заключается в работе с большими блоками информационного наполнения как составными».
Например, если компания выпускает образовательные видеофильмы, то она может проиндексировать их и предоставить потребителям возможность просмотреть именно те части, которые они хотели бы увидеть, экономя тем самым свое время и деньги. Это открывает новые источники доходов для владельцев информационных ресурсов, так как объединение видеоданных в новые блоки порождает и новых клиентов. К примеру, компания-производитель информации образовательного содержания для профессионалов в области информационных технологий может располагать разбросанными по разным видеофильмам данными по отдельным компьютерным платформам и не иметь отдельных видеофильмов по каждой платформе. Если какой-нибудь пользователь заинтересовался определенной платформой, он сможет отметить все интересующие его части, создавая при этом новый видеоряд — и новый продукт для продажи.
Однако получение дохода от информации выходит за рамки непосредственного процесса ее купли-продажи. Например, индексирование дает возможность вставлять целевую рекламу, к примеру, посредством привязки рекламы к индексированным разделам.
Другой аспект превращения информации в деньги заключается в контроле за тем, кто обращается к определенной информации в любой момент времени. Устройства CDN на границах сетей неплохо подходят для исполнения данной функции; они также и технически готовы для этого, так как ориентированы на обслуживание потоков. Одним из поставщиков, работающих в этом направлении, является FastForward.
Компании могут связать публикацию содержимого с другими бизнес-функциями. Например, помимо производства, публикаций и архивирования трансляций Akamai предлагает своим клиентам приложение для управления приглашениями и регистрацией. В частности, регистрационная форма может содержать вопросы наподобие «Вы принимаете решение о покупке?» и «Планируете ли Вы покупку в течение следующих 12 месяцев?».
«Другой аспект управления состоит в выявлении устаревших информационных материалов», — говорит Сривастава. Какая-либо компания с тысячами видеолент в библиотеке может вдруг обнаружить, что она не следит за тем, какие материалы в течение долгого времени не запрашивались сотрудниками компании. При использовании потокового мультимедиа все обращения можно отследить, наиболее популярные информационные ресурсы занести в кэш в стратегических точках сети, а ресурсы, к которым в течение долгого времени никто не обращается, можно поместить в архив.
ПРЫГАЯ В ПОТОК
Инфраструктура быстро развивается, так что надежная доставка потокового информационного наполнения по Internet с приемлемой скоростью станет вполне возможной и будет приносить доход. Все больше и больше компаний рассматривают возможность использования потоковых технологий. Аналитики предсказывают, что, как и в случае со многими другими событиями в мире Internet, вал потоковой информации будет очень быстрым и неистовым, и тот, кто окажется на его гребне, получит наибольшую выгоду. Поток ниспадает в бизнес. Сейчас наступило время для бизнеса, чтобы войти в поток.
Майкл Гурвиц пишет о компьютерных сетевых технологиях. С ним можно связаться по адресу: mhurvicz@pcgroup.com.Ресурсы Internet
В Центре ресурсов кэширования (Caching Resource Center) есть ссылки на новости, комментарии аналитиков и технические статьи. См. http://www.caching.com.
Получить информацию о минимальном пакете RealNetworks можно по адресу: http//www.realnetworks.com/ promos/starterkit/ index.html?src=000629realhome,home_061200a_serve/.
Часто обновляемый набор ссылок, касающихся потокового мультимедиа, можно найти на узле http://html.about.com/ compute/ html/ msubstreaming.htm?rnk=r2&terms=streaming/. Эта информация предназначена главным образом для конечных пользователей и касается настройки клиентских систем.
Аннотированные ссылки на ресурсы потокового видео, продукцию и статьи можно найти на узле http://desktopvideo.about.com/ compute/ desktopvideo/ library/ weekly/ aa091899.htm.
«Мир потокового мультимедиа» по адресу: http://www.streamingmediaworld.com, является Web-узлом, посвященным исключительно потоковому мультимедиа. Этот узел предоставляет всем желающим новости, информацию, руководства и ссылки.
Хорошие описания и примеры поисковых систем мультимедийных данных — включая примеры поисков, которые приводят к успеху, и примеры поисков, которые приводят к неудаче при желании найти точно соответствующие запросу изображения, — все это доступно по адресу: http://www.ai.mit.edu/~braincom/Images/.