По MIME-типу файла (например, video/mp4) браузер определяет способ его воспроизведения. В нашем случае используется медиаплеер, который показан как вспомогательное приложение, хотя это также может быть и плагин. Браузер сохраняет весь фильм, чтобы запустить файл с диска (шаг 3). Затем запускается медиаплеер, которому передается имя полученного файла. Наконец, на четвертом шаге медиаплеер начинает читать файл и проигрывать фильм.

В принципе, такой подход совершенно корректен. Фильм пользователь увидит. Загрузка остается простой загрузкой файла, никаких сетевых проблем реального времени. Единственная серьезная проблема заключается в том, что вся видеозапись должна быть предварительно передана по сети. Большинство клиентов не хотят ждать час, прежде чем они смогут посмотреть «видео по заказу». С этой моделью возникают проблемы, даже когда она применяется к аудио. Если музыкальный файл занимает 4 Мбайт (типичный размер аудиофайла с песней в формате MP3), а пользователь может принимать информацию со скоростью 1 Мбит в секунду, он будет наслаждаться тишиной в течение почти 30 с, прежде чем услышит музыку. Далеко не все меломаны приходят от этого в восторг.

Как обойти эту проблему, не внося изменений в работу браузера? Видеосайты могут использовать схему, показанную на рис. 7.27. Файл, связанный гиперссылкой с названием фильма, на самом деле является не видеофайлом, а метафайлом (metafile). Метафайл обычно очень короткий. Он включает название (и, возможно, несколько ключевых характеристик). В типичной ситуации он состоит всего лишь из одной текстовой строки, которая выглядит примерно так: rtsp://joes-movie-server/movie-0025.mp4

Браузер, как обычно, получает страницу. Затем следуют шаги 1 и 2. Затем он запускает проигрыватель и передает ему, как обычно, имя временного файла (шаг 3).

Проигрыватель видит, что временный файл содержит URL того места, где можно получить фильм. Он соединяется с сервером joes-video-server и запрашивает видеоролик (шаг 4). Затем фильм передается на медиаплеер (шаг 5). Преимущество этого способа заключается в том, что медиаплеер запускается быстро, сразу после загрузки короткого метафайла. После этого браузер не используется. Медиафайл передается плееру напрямую, и просмотр можно начинать до того, как будет загружен весь файл.

Рис. 7.27. Проигрывание медиафайлов при помощи Всемирной паутины и медиасервера

На рис. 7.27 мы показали два сервера, так как сервер, указанный в метафайле, часто не совпадает с веб-сервером, содержащим ссылку на метафайл. Более того, обычно это даже не HTTP-сервер, а специализированный мультимедийный сервер. В приведенном примере этот сервер использует протокол RTSP (Real Time Streaming Protocol — потоковый протокол реального времени), это становится понятно при взгляде на ссылку — она начинается с названия схемы, rtsp.

Проигрыватель мультимедиа (медиаплеер) решает следующие 4 основные задачи.

1.    Управление интерфейсом пользователя.

2.    Обработка ошибок передачи.

3.    Распаковка сжатых данных.

4.    Устранение неустойчивости синхронизации (джиттера).

Большинство современных программ для воспроизведения мультимедиа имеют привлекательный интерфейс. Часто они имеют панели управления с изменяемым внешним видом, называемые «скинами» (skins), которые пользователь может менять. Как мы уже сказали, в задачи проигрывателя входит общение с пользователем.

Другие задачи связаны с сетевыми протоколами. Мы поговорим о всех них, начиная с преодоления ошибок при передаче. Способ их преодоления зависит от того, используется ли транспорт на основе TCP, такой как HTTP, или основанный на UDP, такой как RTP. На практике используются оба. При использовании передачи на основе TCP медиаплееру не придется исправлять ошибки, так как TCP обеспечивает высокую надежность при помощи повторной передачи. Это довольно простой способ преодоления ошибок, по крайней мере, для медиаплеера, но он усложняет удаление джиттера на более позднем шаге. Передача, основанная на UDP, такая как RTP, предлагает альтернативный вариант. Мы рассмотрели его в главе 6. Эти протоколы не используют повторные передачи. Таким образом, потеря пакета из-за затора или ошибки при передаче приведет к тому, что часть медиа не будет доставлена. С этой проблемой должен справляться медиаплеер. Давайте разберем проблему, с которой мы столкнулись. Потери при передаче являются проблемой, так как пользователи явно не обрадуются большим пропускам в песнях или фильмах. Однако эта проблема не так серьезна, как потери при передаче обычного файла, так как потеря небольшой части медиа не поставит крест на всей передаче медиафайла. В случае с видео пользователь вряд ли заметит, если за секунду будет проиграно 24 вместо 25 кадров. В случае с аудио небольшие прерывания могут маскироваться звуками, близкими по времени. И пользователь не заметит подмены, если не будет очень внимательно прислушиваться.

Однако все это справедливо только в том случае, если прерывания в передаче очень короткие. Ошибки при передаче или получении часто приводят к тому, что теряется весь пакет или даже несколько пакетов. Чтобы сократить влияние потери пакетов при передаче медиа, может быть использовано две стратегии: FEC и интерливинг. Мы опишем каждую из них.

FEC (Forward Error Correction — заблаговременное исправление ошибок) является просто кодированием исправления ошибок, которое мы рассмотрели в главе 3, применительно к прикладному уровню. Примером является межпакетный контроль четности (Shacham и McKenny, 1990). Для каждых четырех отсылаемых пакетов данных может быть сконструирован и отослан пятый пакет контроля по четности (parity packet), как показано на рис. 7.28 (пакеты A, B, C и D). Пакет контроля по четности, P, содержит избыточную информацию по принципу суммарного контроля по четности или исключающего ИЛИ, при этом учитывается сумма битов в каждом из четырех пакетов данных. Остается лишь надеяться, что будут доставлены все пакеты в большинстве групп из пяти пакетов. В этом случае пакет контроля по четности просто игнорируется на принимающей стороне. А если теряется только контрольный пакет, проблемой это не становится.

Рис. 7.28. Использование пакета с контролем по четности для предотвращения потерь

Однако иногда при передаче может быть утерян какой-либо пакет, как, например B на рис. 7.28. Медиаплеер получает только 3 пакета данных, A, C и D, а также контрольный пакет, P. При использовании данной схемы биты отсутствующего пакета могут быть восстановлены при помощи данных пакета P. А точнее, если символом «+» обозначить «исключающее ИЛИ» или «сложение по модулю2», B может быть реконструирован по формуле B = P + A + C + D при помощи свойств исключающего ИЛИ (то есть X + Y + Y = X ).

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

В технике, упомянутой выше, также есть интересный нюанс. В главе 3 мы описали использование контроля по четности для обнаружения ошибок. Здесь мы говорим об исправлении ошибок. Как возможно и то и другое? Ответ заключается в том, что на сей раз нам известно, который из пакетов потерян. Потерянные данные называются разрушенными (erasure). В главе 3, когда мы рассматривали кадр, в котором несколько битов содержали ошибки, мы не знали, какие именно. Этот случай сложнее, чем разрушенные пакеты. Таким образом, при потере пакетов пакет контроля по четности может обеспечить исправление ошибок, а в случае, описанном в главе 3, возможно лишь обнаружение ошибок. Скоро, когда речь пойдет о многоадресной передаче, мы познакомимся еще с одной неожиданной выгодой, которую можно извлечь из контрольного пакета.