3.3.3 Отправка звукового сигнала на другие устройства

После того, как звук в камер обработан цифровым аудиомикшером в ATEM-1 M/E Production Switcher и подан на какой либо из входов аналогового аудиомикшера, общий звуковой сигнал можно отправить на сторонний аудиомикшерный пульт. Отправка на другое устройство обработки звука осуществляется при помощи выхода Alt 3-4 аудиомикшерного пульта. Выход Alt 3-4 - это выход с отдельной стереошины аудиомикшера. С помощью этого выходы мы можем маршрутизировать сигнал на выходе аудиомикшера и подать его либо далее по тракту обработки аудиосигнала в ПТС, либо подать его на стороннее устройство.

3.4 Структура тракта управления видеомикшерным пультом и сигнализация

Рисунок 3.4 – Структурная схема организации управления видеомикшером и подачи сигналов операторам.

Управление всеми функциями ATEM-1 M/E Production Switcher осуществляется через протокол Ethernet.

Все устройства, «общающиеся» между собой, это ПК с программой управления видеомикшером, ATEM-1 M/E Broadcast Panel, интерфейс сигнализации и сам видеомикшер, подключаются через один коммутационный узел – маршрутизатор. Каждому устройству устройству присваивается свой IP-адрес, который будет неизвестен другим устройствам в подсети, только маршрутизатору. Любая команда управления отсылается на маршрутизатор, а тот отсылает эту команду всем устройствам, подключенным к нему. В зависимости от команды устройства либо распознают инструкцию, либо ее игнорируют. Например, отсылая сигнал переключения с одного источника видеосигнала на другой, видеомикшер и GPI&Tally Interface отреагируют на эту команду одновременно, а ATEM-1 M/E Broadcast panel или ПК проигнорируют эту команду.

GPI&Tally Interface – устройство сигнализации и связи с операторами источников видеосигнала. При переключении источников в эфир, устройство посылает сигнал в блок управления сигнализацией, а тот в свою очередь отправляет питание на светодиод, закрепленный на камере оператора. Светодиод загорается, давая при это оператору понять, что его камера сейчас в эфире.

Рисунок 3.4.1 – Подключение GPI&Tally Interface

3.5 Структура тракта передачи готового контента

Рисунок 3.5 – структурная схема тракта передачи видео контента на медиасервер.

Входным сигналом системы является сигнал SD или HD SDI. Кодер преобразует видео в формат Mpeg-4 с необходимой скоростью кодирования

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

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

Поскольку MPEG-4 это формат сжатия, который используется повсеместно, то видеофайл можно воспроизводить на большом спектре устройств: ПК, мобильные устройства, Smart TV и т.д.

3.6 Настройка Broadcast медиасервера

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

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

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

При организации потокового видео с медиа-сервера возникает множество трудностей, поскольку архитектура самого процесса передачи видео в этом случае несколько сложнее, чем первый вариант. Например, далеко не каждый видеоформат предусматривает возможность потоковой передачи, а среди тех форматов, которые поддерживают такую возможность, популярны в народе только три: Windows Media, RealMedia, Quicktime.

WindowsMedia в последнее время распространяется все шире и даже не потому что ее продвигает Microsoft. Формат со всеми своими кодеками от версии к версии становится все более совершенным. Windows Media отличается хорошим качеством при высоком уровне компрессии: на сайте производителя приведены таблицы, в которых отмечены преимущества этого продукта перед аналогами.

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

QuickTime – продукт производства фирмы Apple. По понятным причинам в России широкого распространения не получила, тем более что уровень компрессии недостаточен для российских линий связи

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

Существует два похода к организации потокового видео. Первый основывается на особенностях протокола HTTP (Hyper Text Transfer Protocol): вся настройка сводится к размещению на web-сервере видеофайла, подготовленного специальным образом. Второй подход намного сложнее и подразумевает использование специализированного ПО. Так или иначе, конечного пользователя это никак не коснется, поэтому можно выбрать любой из подходов. Первый вариант простой и надежный, но второй вариант, безусловно, предоставляет намного более широкий простор для деятельности.

Первый вариант, это HTTP Streaming. Принцип его работы основывается на разбиении видеопотока на несколько более мелких. То есть, если при загрузке видео пальзователям приходи поврежденный пакет, то устройство пользователя автоматически закачивает еще один такой же из, предположительно, бесконечного числа таких пакетов. Главным его достоинством является поддержка большого количества одновременно подключенных абонентов. Минусом является сложность реализации и стоимость, так как этот способ требует специального программного обеспечения, которое довольно дорого стоит.

С HTTP все намного проще: нужен рабочий web-сервер, заранее заготовленный файл, выложенный на этом сервере, и созданная на него гиперссылка. Пользователь, желающий просмотреть видеоматериал, нажимает на гиперссылку, его проигрыватель незамедлительно обрабатывает ее и начинает потоковую закачку и отображение видео.

Простота этой технологии также накладывает некоторые неприятные ограничения. Такой подход применим скорее для сайтов с небольшим трафиком и скромным количеством одновременных подключений, чем для каких-либо крупных проектов. Для каждого такого подключения открывается отдельный поток, который занимает свою часть канала. При большом количестве подключений может не хватить ширины канала, а это, повлияет не только на просмотр видео, но и на работу web-сайта в целом. Второе ограничение: такой способ позволяет передавать только конечный файл и не предоставляет возможности прямой трансляции, например, с камеры. В итоге невозможно удаленно определить скорость абонентского подключения. Следовательно, придется создавать несколько версий видео с различным разрешением, чтобы файл комфортно передавался на любой, даже минимальной скорости.

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

Существует довольно много разнообразных узконаправленных утилит, которые форматируют видеофайл под нужный формат. Для нас больше всего интересна 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-сервер.

В сети интернет доступно множество разработок в этой области и у всех имеются и достоинства, и недостатки. Огромную популярность завоевал пакет Helix Universal Server - продукт известной конторы Real Networks. Это одна из немногих программ, которая поддерживает передачу самых разных форматов видео, и в то же время она портирована под несколько операционных систем, поэтому для работы будем использовать именно ее.

Наиболее сложным моментом установки Helix Universal Server является указание портов, резервируемых программой под сервисы. В общем случае все можно оставить по умолчанию. Проблемы вероятны только с портом web-сервера: Helix Universal Server имеет свой собственный web-сервер, который по умолчанию устанавливается на 80-й порт. Если на ПК уже установлен web-сервер (80-й порт), то второй сервис на этот же порт установить невозможно.

Управление работой утилиты осуществляется через 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 Files\Real\Helix Server\Content были удаленно доступны по адресу <IP-адрес или имя сервера>/<имя файла>. Для удобства достаточно скопировать обработанный Adobe Premier'ом файл в директорию Content.

Файл в зависимости от своего формата может быть передан по одному из специфических протоколов, но тем не менее, файлы большинства форматов по-прежнему могут быть переданы по HTTP. Действия происходят аналогично созданию ссылок для видеофайлов на web-сервере. Принцип тот же, но в качестве web-сервера выступает Helix Universal Server.

Протоколы потоков

• Real Time Streaming Protocol (RTSP) - основной протокол для передачи потокового видео и аудио. С его помощью мультимедиасерверы "разговаривают" и обмениваются данными со всеми клиентскими подключениями.

• Progressive Networks Audio (PNA) - несколько устаревший протокол, который когда-то применялся для потоковой передачи звука.

• Microsoft Media Services (MMS) - протокол для потоковой передачи мультимедиафайлов в формате Windows Media. При этом вся управляющая информация идет по протоколу TCP, а данные - по UDP

Передача файлов, предназначенных для просмотра в RealOne Player, RealPlayer, QuickTime Player, осуществима по RTSP-протоколу. Адрес медиафайла в этом случае имеет вид rtsp://<IP-адрес сервера>/<имя файла>. Тем не менее передавать такие ссылки напрямую в браузер нельзя - они предназначены специально для него. Ссылки обрабатываются специальными программами - плеерами, указание на запуск которых должен дать браузер, что легко осуществляется метафайлом с расширением .ram, который содержит реальный RSTP-адрес файла. Как создавать такие файлы и гиперссылки на них, мы уже договорились.

Для файлов Windows Media, передаваемых по MMS-протоколу, адрес будет выглядеть аналогично - mms://<IP-адрес сервера>/<имя файла>. Разумеется, здесь также не обойдется без метафайлов, однако в этом случае они будут с расширением не .ram, а .asx, хотя они конструируются по тому же принципу.