Суровая правда о потоковом видеовещании
Бывает, смонтируешь новый ролик и думаешь: "Что делать с ним дальше?" Вполне
логичным шагом в этом случае была бы его публикация в интернете. Задача, по сути,
несложная, но только для тех, кто знает, как это сделать.
Поток или не поток?
Для пользователя существует два способа просмотреть видео через интернет. Первый
и самый простой - полностью скачать видеофайл в какую-нибудь директорию (хотя
бы во временную) и проиграть его с жесткого диска. Этот путь, безусловно, довольно
привлекателен, так как всегда можно с минимальными проблемами повторять просмотр
и при этом не тратить драгоценный трафик. Более того, только при таком просмотре
видео можно буквально за несколько мигов обратиться к любому эпизоду фильма, к
началу или середине. Однако при всех плюсах очевиден недостаток этого способа:
приходится довольно долго ждать, пока закончится загрузка объемного видеофайла.
Для тех, кто не любит тратить время в ожидании, есть другой вариант - потоковая
трансляция видео, при которой просмотр можно начать не после закачки файла, а
во время нее. Программное обеспечение скачивает минимальный отрывок видео (производит
буферизацию) и сразу же выводит его на экран, а одновременно с этим закачивает
следующий отрывок. Получается, что видеофайл передается постоянным потоком и его
можно просматривать по мере скачивания. На этом плюсы потокового видео не заканчиваются:
можно также транслировать в прямом эфире через интернет события, в реальном времени
передавать в Сеть данные с DV- или web-камеры. Справедливости ради стоит отметить,
что и такой способ не лишен недостатков. Во-первых, потоковое видео редко сохраняется
на диск - для этого нужны дополнительные утилиты. Во-вторых, пользователь не может
прервать просмотр и обратиться к нужному эпизоду видео: можно просматривать только
то, что передается. И в конце концов, качество передаваемой картинки часто оставляет
желать лучшего. На разрешении и количестве кадров в секунду часто приходится серьезно
экономить, чтобы видео было плавным, без рывков и заиканий.
Потоки бывают разные
Какой способ выбрать для публикации своего материала – решать только тебе. Если
потоковое вещание тебе не импонирует, то никаких проблем с публикацией возникнуть
не должно. Просто оцифруй свой видеоролик в приемлемом качестве любимым DivX‘ом
и выкладывай в Сеть прямиком на web-сервер. Большого ума здесь не требуется.
А если ты решишься организовать потоковое вещание, то будь готов бороться с его
недостатками, с которыми столкнешься с самого начала работы. Например, далеко
не каждый видеоформат предусматривает возможность потоковой передачи, а среди
тех форматов, которые поддерживают такую возможность, популярны в народе только
три: Windows Media, RealMedia, Quicktime.
Windows Media (www.microsoft.com/windows/windowsmedia/default.asp) в последнее время распространяется все шире и даже не потому что ее продвигает
Microsoft. Формат со всеми своими кодеками от версии к версии становится все более
совершенным. Windows Media отличается хорошим качеством при высоком уровне компрессии:
на сайте (см. начало абзаца) приведены таблицы, которые вполне отражают действительное
положение дел.
RealVideo (www.realnetworks.com/products/codecs/realvideo.html) - некогда популярный формат, изначально разработанный для потокового вещания.
Некоторое время не развивался и из-за этого практически растерял былую популярность.
Последняя 10-я версия RealVideo значительно превосходит свою предшественницу и
по куче параметров "обходит" своих оппонентов. Единственный минус RealVideo этой
версии - необходимость пользоваться специальным проигрывателем (правда, бесплатным).
QuickTime (www.apple.com/quicktime) - детище Apple. По понятным причинам в России широкого распространения не получила,
тем более что уровень компрессии недостаточен для все еще распространенных в России
модемных линий (да, мы верим, что ты не такой, но для любителей выделенки с платным
трафиком это тоже немаловажно).
Каждый из форматов имеет свои плюсы и минусы, но выбор в общем осуществляется
по личным пристрастиям. Для того чтобы успешно покорять сердца пользователей,
рекомендую подготовить видеоматериал во всех трех форматах, благо это совсем несложно.
Впрочем, мало выбрать для себя подходящий формат - нужно еще и разобраться с
тем, каким образом передать видео пользователю. Существует два похода к организации
потокового видео. Первый основывается на особенностях привычного для нас протокола
HTTP (Hyper Text Transfer Protocol): вся настройка сводится к размещению на web-сервере
видеофайла, подготовленного специальным образом. Второй подход намного сложнее
и подразумевает использование специализированного ПО. Так или иначе, конечного
пользователя это никак не коснется, поэтому можно выбрать любой из подходов. Можешь
выбрать первый вариант и при этом не бояться потерять доверие пользователей, но
второй вариант, безусловно, предоставляет намного более широкий простор для деятельности.
HTTP спешит на помощь
Если у тебя нет никакого желания долго возиться с организацией потокового вещания,
то HTTP Streaming - это определенно то, что доктор прописал. Для выбора в пользу
последнего может быть несколько причин. Во-первых, отпадает всякая необходимость
использовать дополнительное ПО. И это очень важно, так как установить какую-нибудь
софтину на удаленном сервере - задача не из легких. Да и кто разрешит сотворить
такое, если у тебя куплен обычный виртуальный хостинг? Скорее всего, придется
приобрести свой собственный выделенный сервер или оговорить особые условия с хостером.
Оба варианта влетят в копеечку.
С HTTP все намного проще: нужен всего-то рабочий web-сервер, умение выкладывать
заготовленный (об этом чуть позже) файл на сервер и устанавливать гиперссылку
на него. Пользователь нажимает на твою ссылку, его проигрыватель незамедлительно
обрабатывает ее и начинает потоковую закачку и отображение видео.
Правда, простота этой технологии накладывает и некоторые неприятные ограничения.
Такой подход применим скорее для сайтов с небольшим трафиком и скромным количеством
одновременных подключений, чем для каких-либо крупных проектов. Для каждого такого
подключения открывается отдельный поток, который занимает свою часть канала. При
большом количестве подключений может элементарно не хватить ширины канала, а это,
сам понимаешь, повлияет не только на просмотр видео, но и на работу web-сайта
в целом. Второе ограничение не менее обидное: такой способ позволяет передавать
только конечный файл и не предоставляет возможности прямой трансляции, например,
с камеры. В итоге невозможно удаленно определить скорость абонентского подключения.
Следовательно, придется создавать несколько версий видео с различным разрешением,
чтобы файл комфортно передавался на любой, даже минимальной скорости.
Предположим, в нашем распоряжении есть подготовленный видеофайл. Что именно он
представляет собой - неважно. В каком формате находится - по большому счету тоже.
В любом случае его нужно сначала обработать, то есть подготовить к потоковому
вещанию.
Существует довольно много разнообразных узконаправленных утилит, которые подгоняют
видеофайл под нужный формат. Для нас больше всего интересна Adobe Premier - отличная
программа, которая окажет тебе услуги не только как редактор видеоматериалов,
но и как универсальное средство для подготовки потокового видео. Работать с Adobe
Premier несложно. Все, что требуется от тебя, - это открыть видеоролик в Premier‘е
и через меню File выбрать пункт Export Clip. Здесь доступны самые разнообразные
подпункты, среди них нужные нам как раз сейчас - RealMedia, Windows Media and
Quicktime. Вполне возможно использовать другой пункт - Save for Web, но это лишь
промежуточный шаг перед вызовом предыдущих. После вызова этого пункта откроется
специальное окно с несколькими актуальными для потокового видео параметрами (правильнее
сказать - "с наборами параметров"), которые хранятся в уже подготовленных разработчиками
и поэтому простых в обращении профилях.
Параметр для каждого формата, по сути, только один - скорость, на которой будет
передаваться видеофайл. Она варьируется в широких пределах, и ты праве наштамповать
столько файлов, сколько посчитаешь нужным. Однако желательно создать как минимум
три файла: для скорости 56 Кбит/с (модемное соединение), 128 Кбит/с (для низкоскоростной
выделенки) и 512 Кбит/с - ради пользователей с широким интернет-каналом.
После того как файл для потокового видео будет создан, зальем его на web-сервер.
Думаю, здесь комментарии излишни: FTP-клиент в зубы и вперед :). Следующий шаг
- создание гиперссылки и ее размещение на web-сайте. Тип гиперссылки во многом
зависит от формата файла. В случае с Windows Media вполне сойдет обычная ссылка
- <a href="video.wmv">Кликните сюда - здесь видео</a>. Но уже для RealMedia
просто указать <a href="video.rm">RealMedia видео</a> нельзя, так как в
этом случае файл просто скачается на жесткий диск пользователя. Для того чтобы
обеспечить именно потоковую передачу, нужно создать вспомогательный метафайл с
расширением .ram. Это обычный текстовый файл, который содержит одну строчку -
HTTP-адрес .rm файла. Только после этого можно будет создавать ссылку на своем
web-сайте, но уже не на видеофайл, а на созданный .ram-файл - <a href="video.ram">Потоковое
видео</a>. Стоит отметить, что для корректной обработки этих ссылок пользовательским
приложением твой web-сайт должен правильно распознавать .rap, .ram, .rm and .rpm
расширения.
С файлами в Quicktime-формате все довольно прозрачно. Для создания прямой ссылки
на файл вполне работоспособен стандартный прием: <a href="video.mov">Quicktime
видео</a>. Хотя рекомендую делать это вот так: <EMBED SRC="video.mov" TYPE="image/x-quicktime"
HEIGHT=180 WIDTH=320 BGCOLOR="#000000" QTSRC="www.tvoi.site.ru/video.mov">.
А как же альтернатива?
Как ты заметил, наладить потоковое видео через протокол HTTP элементарно и просто.
Но что делать, если нужно провести прямую трансляцию какого-то события? Или если
нужно сделать так, чтобы по одному и тому же адресу время от времени передавались
разные ролики? Вполне понятно, что описанный способ тут не пройдет - нужны специализированные
медиасерверы. Потоковые серверы предоставляют намного больше возможностей, но
они гораздо сложнее в администрировании, чем обычный web-сервер. Так что в барке
с HTTP не стоит надеяться на сладкую жизнь.
В Сети доступно множество разработок в этой области (успешных и не очень). Огромную
популярность завоевал пакет Helix Universal Server - продукт известной конторы
Real Networks (www.realnetworks.com/products/media_delivery.html). Это одна из немногих программ, которая поддерживает передачу самых разных
форматов видео, и в то же время она портирована под несколько операционных систем.
Вполне логично, что осваивать мы будем именно ее.
Первое, что отмечу - это платность утилиты. На те же деньги можно купить приличную
машину :). Если ты небогат и не пользуешься услугами одноглазых и одноногих людей
с попугаями на плечах, придется поэксплуатировать триальный 30-дневный ключ. Для
этого качаем утилиту с официального сайта, указав в анкете настоящий e-mail (лицензионный
ключ будет отправлен именно на него).
Наиболее сложным моментом установки Helix Universal Server является указание
портов, резервируемых программой под сервисы. В общем случае все можно оставить
по умолчанию. Проблемы вероятны только с портом web-сервера: Helix Universal Server
имеет свой собственный web-сервер, который по умолчанию устанавливается на 80-й
порт. Понятно, что если на машине уже установлен web-сервер (80-й порт), то второй
сервис на этот же порт установить невозможно. Позаботься, чтобы подобной конфликтной
ситуации не возникло.
Если все было сделано правильно, то сразу после установки программа запустится
без проблем. В большинстве случае что под Windows, что под *nix‘ом Helix Universal
Server работает в качестве сервиса и не мозолит глаз. Управление ее работой осуществляется
через web-интерфейс: http://<IP-адрес компьютера>:<порт админки>/admin/index.html. Для того чтобы получить администраторские
привилегии, проходим авторизацию, то есть указываем логин и пароль, которые ты
задал во время установки программы. Админка имеет десяток групп настроек, среди
которых - Server Setup.
Ports. Отсюда можно переназначить используемые программой порты. Важно, чтобы
все они были заданы корректно: иначе может отказать передача видео по некоторым
из протоколов потокового видео.
IP Binding. Выбор IP-адресов, которые будет использовать Helix Universal Server.
MIME Types. Создание дополнительных и редактирование уже имеющихся MIME-ассоциаций.
Connection Control. Здесь находятся все опции по ограничению доступа, а также
лимитированию по трафику и типу.
Redundant Servers. С помощью этого подраздела можно слинковать несколько серверов.
Так, в случае чрезмерной нагрузки все лишние клиенты будут перенаправлены на альтернативные
серверы, указанные в этом разделе.
Mount Points. Этот раздел содержит настройки точек монтирования, которые присутствуют
в каждой ссылке на файл, хранящейся на Helix Server file. Грубо говоря, это краткий
виртуальный адрес на папку, которая на самом деле физически находится в труднодоступном
месте.
URL Aliasing и HTTP Delivery. Здесь задаются используемые сокращения в URL-адресах,
а также настраиваются папки web-сервера.
Cache Directives. В этом разделе можно указать те файлы и папки, которые не могут
быть кешированы пользователем. По умолчанию сервер разрешает кешировать все передаваемые
им потоки видео. Благодаря этому некоторые прокси-серверы умеют дифференцировать
поток видео и разбивать его на части. В случае запроса на передачу уже кешированного
файла прокси передаст его пользователю, так сэкономится трафик и обойдется без
обращения к серверу.
Помимо перечисленных, доступны еще несколько групп разделов, которые отвечают
за безопасность передачи данных, параметров протоколов, управление шириной канала
и т.п. Однако даже описанных настроек вполне достаточно для организации полноценной
работы сервера.
Экстрим в действии
Впрочем, Helix Universal Server окажется с вполне работоспособной конфигурацией
сразу после установки. Недоверчивые могут легко проверить это с помощью раздела
Media Samples, имеющегося в административном интерфейсе. Этот раздел содержит
ссылки на демонстрационные файлы самых разнообразных форматов, которые передаются
по различным протоколам. Просто кликай по ним - и результат превзойдет все ожидания.
Вот и развеялись твои сомнения, теперь тобой, скорее всего, овладело желание
попробовать выложить на сервер свои собственные видеофайлы. Не вопрос! Любая ссылка
на медиаресурс скалывается из следующих составляющих: <название протокола>://<адрес
сервера>:<номер порта>/<точка монтирования> /<путь>/<название файла>.
Я уже рассказывал о точках монтирования. В базовой установке Helix Universal
Server по умолчанию присутствуют некоторые из них. Одна из них делает так, что
все файлы локальной папки C:Program FilesRealHelix ServerContent (у тебя папка
может быть другой) были удаленно доступны по адресу <IP-адрес или имя сервера>/<имя
файла>. Удобно? Не то слово. Чтобы не заморачиваться избыточными трудностями,
просто скопируй свой обработанный Premier‘ом файл в директорию Content. По сути,
она уже на сервере!
Файл в зависимости от своего формата может быть передан по одному из специфических
протоколов, но тем не менее, файлы большинства форматов по-прежнему могут быть
переданы по HTTP. Действуй аналогично тому, как мы уже создавали ссылки. Принцип
тот же, но в качестве web-сервера выступает Helix Universal Server.
Передача файлов, предназначенных для просмотра в RealOne Player, RealPlayer,
QuickTime Player, осуществима по RTSP-протоколу. Адрес медиафайла в этом случае
имеет вид rtsp://<IP-адрес сервера>/<имя файла>. Тем не менее передавать
такие ссылки напрямую в браузер нельзя - они предназначены специально для него.
Ссылки обрабатываются специальными программами - плеерами, указание на запуск
которых должен дать браузер, что легко осуществляется метафайлом с расширением
.ram, который содержит реальный RSTP-адрес файла. Как создавать такие файлы и
гиперссылки на них, мы уже договорились.
Для файлов Windows Media, передаваемых по MMS-протоколу, адрес будет выглядеть
аналогично - mms://<IP-адрес сервера>/<имя файла>. Разумеется, здесь также
не обойдется без метафайлов, однако в этом случае они будут с расширением не .ram,
а .asx, хотя они конструируются по тому же принципу.
Ленивым на заметку
Заинтересовался возможностями потокового видео, но опасаешься за свои технические
возможности? Не беда! Благодаря многочисленным конторам, которые возьмут на себя
все заботы по кодированию и размещению видеоинформации в интернете, ты полностью
избавишься от каких-либо проблем. Среди таких фирм: streaming.netro.ca, www.servepath.com/hosted/streaming_servers.htm, www.playstream.com (15 дней бесплатно!) и многие другие.
Помимо всего прочего, такие службы позволяют проводить закрытые (защищенные паролем)
трансляции, поддерживают групповую (multicast) передачу данных для снижения нагрузки
на каналы связи, а также ведут информативные отчеты с подробной статистикой о
посетителях и об использовании материалов. А самое главное - услуги этих служб
могут обойтись намного дешевле, чем покупка выделенного сервера.
Протоколы потоков
Real Time Streaming Protocol (RTSP) - основной протокол для передачи потокового
видео и аудио. С его помощью мультимедиасерверы "разговаривают" и обмениваются
данными со всеми клиентскими подключениями.
Progressive Networks Audio (PNA) - несколько устаревший протокол, который когда-то
применялся для потоковой передачи звука.
Microsoft Media Services (MMS) - протокол для потоковой передачи мультимедиафайлов
в формате Windows Media. При этом вся управляющая информация идет по протоколу
TCP, а данные - по UDP.
