Мультимедиа по запросу по HTTP

Первоначально мультимедийные потоки в Web передавались точно так же, как традиционные текст и изображения. Клиент отправляет HTTP-запрос на Web-cepвер, а сервер передает запрошенный ресурс клиенту. Заголовок Content-Type в co- общении-ответе HTTP указывает на формат’ кодирования (например, Content- Type: video-mpeg). На основе значения заголовка Content-Type браузер вызывает соответствующее вспомогательное приложение, чтобы интерпретировать ответ, как об этом говорилось в главе 2 (раздел 2.4.3). Для данных  аудио и видео вспомогательным приложением обычно является медиаплейер, который декодирует и отображает ответ. Плейер может также предоставить графический интерфейс для регулирования громкости и выполнения функций видеомагнитофона, таких как пауза, прямая и обратная перемотка. С точки зрения браузера медиаплейер не отличается от любого другого вспомогательного приложения — браузер просто направляет данные приложению.

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

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

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

•          Чередование потоков аудио и видео. Вспомогательное приложение работает с содержимым одного сообщения-ответа. Рассмотрим HTTP-запрос на мультимедийный сеапс, который содержит как аудио-, так и видеоданные. Web- cepвep должен чередовать аудио- и видеосодержапие в одном сообщении-от- вете, чтобы дагь возможность плейеру воспроизводить данные по мере их поступления. В некоторых случаях аудио- и видеоданные уже объединены вместе в одном файле.

•          Издержки надежного транспорта. HTTP подразумевает наличие надежного протокола транспортного уровня, такого как TCP. Передача данных потокового мультимедиа с помощью TCP сама по себе неэффективна. Обнаружение и повторная передача утерянных пакетов приводит к дополнительной задержке при отображении мультимедийного содержания. Это может вызвать прерывистое воспроизведепие потока медиаплейером.

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

HTTP не слишком хорошо подходит для передачи поуоков мультимедийного содержания; для преодоления указанных выше ограничений были разработаны другие подходы.

Вместо того чтобы получать данные от браузера, медиаплейер может взаимодействовать непосредственно с сервером. Это взаимодействие не обязательно должно осуществляться но HTTP. Плейер может взаимодействовать с мультимедийным сервером с использованием протокола, который лучше подходит для работы с мультимедийными потоками. Параллельно с разработкой стандартных протоколов, поставщики программных продуктов реализовывали свои собственные подходы к координации действий между плейером и сервером. Как правило, для инициирования мультимедийной передачи используется HTTP. В ответ на HTTP-запрос сервер возвращает ответ, содержащий метаданные о мультимедийном потоке. Например, тело HTTP-ответа может включать URL мультимедийного сервера с указанием желаемого содержания (например, pnm://media.foo.com/clip). Браузер активизирует вспомогательное приложение, которое обрабатывает ответ, устанавливая свое собственное соединение с мультимедийным сервером.

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100