Потоковое видео и открытые системы

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Потоковое видео и открытые системы

Потоковое видео и открытые системы

Министерство образования Российской Федерации

Уфимский Государственный Авиационный Технический Университет

Курсовая работа

по предмету: Администрирование информационных систем

на тему: Потоковое видео и открытые системы

Уфа, 2010

Оглавление

1. Теоретическая часть

1.1 Общие сведения о потоковом мультимедиа

1.2 Потоковое вещание и хранение информации

1.3 Протоколы потокового вещания

1.4 Преимущества потокового вещания

1.5 Обзор мультимедиа серверов

2. Практическая часть

2.1 Установка сервера

2.2 Организация потокового вещания по протоколу UDP Unicast

2.3 Организация потокового вещания по протоколу HTTP

2.4 Создание web-страницы транслирующей медиапоток с сервера

2.5 Удаленное управление сервером VideoLAN

Заключение

1. Теоретическая часть

Потоковое мультимедиа (от. англ. stream media) -- это мультимедиа, которое непрерывно получается пользователем от провайдера потокового вещания. Это понятие применимо как к информации, распространяемой через телекоммуникации, так и к информации, которая изначально распространялась посредством потокового вещания (например, радио, телевидение) или непотоковой (например, книги, видеокассеты, аудио CD).

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

С конца 1980-х и до 1990-х компьютеры, доступные потребителям, уже были способны отображать различные виды информации. Основными техническими проблемами потокового вещания были:

- наличие достаточно производительного CPU и шины для передачи мультимедиа необходимого битрейта

- создание ОС, при работе которых гарантируется высоконадёжная передача данных.

Тем не менее, компьютеры сети оставались ограниченными, а потоковое мультимедиа уступало традиционному (CD-ROM).

В период с 1990 до 2000 пользователи интернета получили:

- высокую пропускную способность сетей, в частности, на последней миле

- возросло количество абонентов сетей, особенно Интернета

- стали использоваться стандартизованные протоколы и форматы, такие как TCP/IP, HTTP и HTML

- появилась коммерция в Интернете

Эти достижения в области сетей в совокупности с высокопроизводительными домашними компьютерами и современными операционными системами сделали потоковую мультимедийную информацию доступной широкому кругу простых пользователей. Автономные приёмники интернет-радио предлагали пользователям возможность прослушивания потокового звука без наличия компьютера.

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

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

Размер, необходимый для хранения потоковой мультимедиа информации (в большинстве файловых систем выражается в мегабайтах, гигабайтах, терабайтах и т. д.) вычисляется в зависимости от скорости передаваемой информации и продолжительности информации по следующей формуле (для одного пользователя и файла):

размер хранилища (в мегабайтах) = продолжительность (в секундах) * битрейт (в кбит/с) / (8 * 1024)

Пример:

Один час видео, закодированного со скоростью 300 кбит/с (типичное видео транслируемое в интернете, имеющее размер 320?240 пикселов) будет занимать:

(3,600 с * 300 кбит/с) / (8*1024) порядка 130 Мб места на диске

Если файл, хранимый на сервере с режимом передачи по запросу будет просматриваться 1000 людей одновременно по протоколу Unicast (1 клиент -- 1 соединение), то сервер должен иметь следующую пропускную способность:

300 кбит/с * 1,000 = 300,000 кбит/с = 300 Мбит/с сетевого интерфейса

Это эквивалент порядка 125 Гб информации в час. Разумеется, при использовании протокола Multicast нагрузка на сервер намного ниже, так как для передачи информации всем клиентам используется единственный поток. Следовательно, такой поток будет занимать всего 300 кбит/с сетевого интерфейса сервера.

Разработка сетевых протоколов потокового вещания вызывает следующие проблемы:

- Датаграмные протоколы, такие как User Datagram Protocol (UDP), отправляют поток медиаинформации как поток отдельных маленьких пакетов. Он прост и эффективен; в то же время, в спецификации протокола нет гарантии доставки данных получателю. Это очень сильно затрудняет поиск и исправление получаемых данных принимающим информацию приложением. При потере данных поток может быть отключен.

- Протоколы RTSP, RTP и RTCP специально разрабатывались для передачи мультимедийной информации по сети. Последние два построены на основе UDP.

- Надежные протоколы, такие как TCP, гарантируют корректность получаемых данных клиентов потокового вещания. Однако при большом количестве ошибок при соединении/подтверждении получаемой информации передаваемая информация может стать неактуальной. Это также может вызвать значительные задержки при передаче информации на время, затраченное на пересылку поврежденной информации. Одним из решений данной проблемы является буферизация информации на стороне клиента.

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

- При широковещательной передаче одна копия данных передается всем клиентам сервера.

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

- Multicast позволяет передавать один поток информации группе клиентов по сети. Одной из проблем при реализации подобной схемы потокового вещания является корректная настройка маршрутизаторов для передачи широковещательных пакетов из одного сегмента сети в другой. Если организация, предоставляющая потоковое вещание, имеет контроль над сетью между сервером и клиентами (например, в образовательной, правительственной или корпоративной сети), то протоколы маршрутизации, такие как IGMP и PIM, могут быть использованы для доставки мультимедиа нескольким клиентам из различных сегментов LAN.

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

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

Компромиссной технологией раздачи медиаконтента является онлайновое вещание по технологии Multicast, обеспечивающей одновременную доставку идентичного контента всем запросившим его пользователям, что существенно разгружает каналы передачи данных. Это также ограничивает свободу пользователей в выборе контента, поскольку если к серверу подключились сто тысяч пользователей и каждый из них выбирает свой файл, то никакого выигрыша владелец сервера не получит. С другой стороны, можно иметь несколько независимых Multicast-каналов, передающих различные файлы, к которым может подключаться кто угодно. Разница между обычным скачиванием файла с сервера в том, что трансляция не позволяет слушателем/зрителям управлять потоком, и они вынуждены слушать/смотреть файл с момента подключения к серверу, который к тому времени мог проиграть половину файла. В некоторых случаях это приемлемо, в некоторых - нет. Как показывает практика, достаточно большой аудитории пользователей совершенно неважно, что именно играет в данный момент - главное, чтобы что-то вообще играло.

К тому же в потоковое аудио/видео намного легче "врезать" рекламу или прочие вставки типа "breaking news", да и квалификация среднестатистического пользователя не позволяет сохранять потоковый контент на диск, что очень нравится держателям авторских прав и прочим медиамагнатам.

С развитием интернет технологий, потоковое вещание мультимедиа вышло на новый уровень. Сегодня с легкостью можно найти тысячи ссылок ведущих на множества потоков музыки или видео. Для организации серверов, с которых ведется потоковое вещание разработано множество программного обеспечения. Большая часть из которого предназначена для вещания аудио данных в форматах mp3 или ogg. Для видео данных набор программного обеспечения ничуть не меньше, но серверов, которые могли бы полностью покрыть потребности медиасервисов довольно немного и основная часть является коммерческими проектами. Наиболее популярными на сегодняшний момент серверами для потокового видео можно назвать TVersity, QuickTime Broadcaster, VideoLAN, Windows Media Services, FFserver (FFmpeg) и т.д. Из них, лишь серверы VideoLAN и FFserver (FFmpeg) являются бесплатными и распространяются с открытым исходным кодом.

FFmpeg -- набор свободных библиотек с открытым исходным кодом, которые позволяют записывать, конвертировать и передавать цифровое аудио и видео в различных форматах. Он включает libavcodec -- библиотеку кодирования и декодирования аудио и видео и libavformat -- библиотеку мультиплексирования и демультиплексирования в медиаконтейнер. Название происходит от названия экспертной группы MPEG и FF, означающего fast forward.

FFmpeg разработан под ОС на основе Linux, однако может быть скомпилирован под многие другие операционные системы. Разработчики не выпускают релизов и рекомендуют использовать последнюю версию из Subversion. Распространяется под лицензиями GNU LGPL или GNU GPL.

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

VideoLAN - многофункциональный комплекс, портированный практически под все операционные системы, поддерживающий множество протоколов, форматов и контейнеров, который можно использовать и как локальный аудио/видеоплеер, и как сервер трансляции (рис. 1).

Клиентская и серверные части исправно работают под Linux, Windows, Mac OS X, BeOS, xBSD, Solaris, Familiar Linux, Yopy/Linupy и QNX, однако их функциональность различна и в зависимости от выбранной платформы варьируется в очень широких пределах (рис. 2).

Рисунок 2. Возможности программы VideoLAN на каждой из поддерживаемых ею платформ.

Поддерживаются следующие входные форматы данных: MPEG-1, MPEG-2, MPEG-4/DivX (считываемые с локального жесткого диска или CD/DVD); "настоящие" DVD и VCD; спутниковые карты, работающие по стандарту (DVB-S); потоковое видео, "упакованное" в MPEG-1, MPEG-2 и MPEG-4 (то есть, VideoLAN может работать не только как сетевой транслятор, но и как ретранслятор чужого контента с возможностью сохранения последнего на жесткий диск).

В настоящий момент реализованы два основных протокола трансляции: Unicast ("узконаправленное" вещание с доставкой контента только одному целевому узлу) и Multicast (групповая трансляция с доставкой одного и того же контента множеству узлов). Также (формально) имеется возможность широковещательной рассылки контента всем узлам локальной сети (для этого достаточно указать в качестве целевого IP-адреса 255.255.255.255), но с высокой степенью вероятности она будет задавлена брандмауэрами и маршрузитаторами, так что без их радикальной перестройки сеанс вещания не состоится даже в рамках локальной сети.

Еще имеется ограниченная поддержка видео-по-требованию (Video-on-Demand или, сокращенно, VoD) с возможностью выбора контента по HTTP или TELNET интерфейсам, однако эта возможность обычно используется исключительно администраторами для удаленного управления сервером трансляции.

Контейнеры, в которые помещается транслируемый поток, зависят от типа трансляции, допустимые комбинации которых перечислены в таблице на рис. 5. Естественно, все это хозяйство работает как с IPv4, так и с IPv6.

Рисунок 5. Допустимые комбинации протоколов трансляции с контейнерами, в которые упаковывается транслируемый медиа-поток.

2. Практическая часть

Рассмотрим подробнее организацию потоковой трансляцию видео на основе сервера VideoLan установленного на систему Ubuntu 10.10.

Для установки сервера, воспользуемся стандартным менеджером пакетов Synaptic и установим требуемые пакеты согласно инструкции установки на систему Ubuntu 10.10. Так же возможна установка, используя терминал. Что пригодится для удаленной установки.

Для нормальной работы сервера VideoLAN обязательным условием является установка и проигрывателя с библиотеками. Поэтому сначала устанавливаем медиапроигрыватель, который при установке автоматически загрузит связанные пакеты.

Для того чтобы появилась возможность потокового вещания заменяем установленные библиотеки libavcodec на libavcodec-extra.

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

После загрузки и установки VideoLAN можно сразу приступать к организации потокового вещания.

Самое простое - это потоковое вещание обычного AVI/MPEG файла на соседний компьютер. В меню программы выбираем пункт Медиа - Потоковое вещание или же воспользовавшись горячими клавишами можно нажать <CTRL-S> (см. рис. 6) и через "Обзор" выбираем один или несколько файлов (не обязательно одного и того же типа).

Для подключения субтитров (если мы хотим их подключать) взводим одноименную галочку и указываем путь к файлу с субтитрами, положение и цвет которых определяется кнопкой "Расширенные настройки". VideoLAN поддерживает множество субтитров различных типов (включая .srt и .sub), что позволяет нам, в частности, накладывать рекламу на видеопоток или различные сведения чисто информационного характера. После всех установок связанных с выбором входного видео и субтитров можно нажимать на кнопку «Поток». В VideoLAN вещание можно осуществлять сразу в нескольких «направлениях», но нам достаточно выбрать протокол UDP. В поле адрес введем адрес компьютера на который будет осуществляться вещание и порт (по-умолчанию 1234). Также на этом этапе можно включить перекодирование входного потока, что в частности пригодится для вещания по протоколу HTTP. В данном случае, использование протокола UDP Unicast подразумевает в качестве среды передачи данных локальную сеть, что обуславливает высокую скорость передачи данных. Поэтому в перекодировании нет особого смысла.

Время жизни пакетов (TTL) зависит от количества узлов, через которые проходит транслируемый контент, и чтобы он не ушел чересчур далеко, это значение можно установить равному трем или даже одному. О строке "MRL выходного потока" можно не заботиться, программа сформирует ее за нас автоматически. После нажатия кнопки «Поток» автоматически начнется вещание на указанный в параметрах адрес.

Проверим трансляцию, запустив любой проигрыватель, поддерживающий потоковую передачу, на компьютере с адресом, указанным в параметрах, и укажем номер udp порта. Запустим VCL проигрыватель на операционной системе windows 7 и увидим осуществляемую трансляцию.

При этом нам вовсе не обязательно знать адрес сервера, достаточно лишь указать порт на который ведется трансляция.

2.3 Организация потокового вещания по протоколу HTTP

Главным недостатком unicast-трансляции является невозможность вещания на произвольные узлы локальной/глобальной сети. Сервер должен иметь список IP-узлов для рассылки пакетов. Получателям знать же IP-адрес транслятора ни к чему. Им достаточно "помнить" назначенный UDP-порт, чтобы ловить трафик. В обычной жизни все наоборот. Передатчик ничего не знает о приемнике (приемниках), а каждый из приемников в любой момент времени может настроиться на волну любого из многочисленных передатчиков и отключиться, если передача ему неинтересна.

Специально для реализации подобного способа общения, VideoLAN поддерживает трансляцию через Web по TCP/IP-протоколу. Возвращаясь к серверной стороне, меняем протокол с UDP на HTTP, в поле адрес можно ничего не указывать, если транслироваться будет только один видео-поток.

Также рекомендуется увеличить и значение TTL, особенно если мы собираемся вещать в Интернет на далекие расстояния.

Обратим внимание, что на этот раз трансляция осуществляется через web и важно выбрать один из доступных контейнеров, для более лучшего сжатия потока и снижения трафика. Если все клиенты используют в качестве приемника программу VideoLAN, то особой разницы нет и лучше оставить контейнер по умолчанию, если же планируется транслировать аудио/видеопоток на компьютеры, где кроме Windows и штатного медиаплеера ничего нет, лучше выбрать ASF, однако в таком случае следует позаботиться о совместимости с кодеками, поставляемыми вместе с Windows и в графе "профиль" выбрать что-то очень хорошо известное и проверенное временем (например, DIV3, WM1, WM2), аналогичным путем поступить и со звуком, в противном случае слушателям придется рыскать в поисках нужных кодеков перед началом воспроизведения контента.

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

Помимо VLC плейера попробуем открыть поток также и в стандартном проигрывателе Windows.

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

<html>

<head><title>Тест</title></head>

<body>

<h2>Тестовое потоковое вещание. Курсовая АИС. <h2>

<embed type="application/x-vlc-plugin"

name="video"

autoplay="yes" loop="yes" width="400" height="300"

target="http://192.168.1.4:8080"/>

<br />

</body>

</html>

Где свойство объекта target будет содержать адрес транслируемого потока.

2.5 Удаленное управление сервером VideoLAN

Для удаленного управления медиасервером установим в системе OpenSSH сервер.

Установим удаленное соединение по SSH используя клиент PuTTY.

После авторизации, получаем приглашение в терминал Ubuntu.

Запуск консольной версии VideoLAN осуществляется путем ввода команды cvlc. Даже в тех случаях когда мы можем не знать какой именно файл стоит транслровать, то VideoLAN поможет просмотреть видео прямо в окне терминала. Для этого используется преобразование графического изображения в символы ASCII.

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

cvlc -vvv /home/alex/video.mp4 --sout '#transcode{vcodec=mp4v,acodec=mpga,vb=800,ab=128}:standard{access=http,mux=ogg,dst=192.168.1.4:8080}'

где /home/alex/video.mp4 имя транслируемого файла, или устройство захвата, или даже ссылка на другой видео поток. В блоке #transcode указываются параметры перекодирования входного потока. Если нет нужды, менять установки по-умолчанию, то достаточно указать только имя контейнера и битрейт. Так же указывается тип точки выхода, в данном случае это http, формат выходного потока, и адрес сервера, в котором можно указать только порт, а сам адрес оставить пустым.

Теперь используя PuTTY запустим веб трансляцию и проверим её на тестовой странице в другой ОС.

cvlc -vvv video.mp4 --sout '#transcode{vcodec=WMV2,vb=800,scale=1,acodec=wma2,ab=96,channels=2,samplerate=44100}:standard{access=http,mux=asf,dst=:8080/}'

Заключение

Структура глобального трафика в интернете меняется. Видео по-прежнему является основным пожирателем емкости сетевых каналов, но изменяется сама структура видео.

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

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

VideoLAN позволяет передавать один поток информации группе клиентов по сети. Одной из проблем при реализации подобной схемы потокового вещания является корректная настройка маршрутизаторов для передачи широковещательных пакетов из одного сегмента сети в другой. Если организация, предоставляющая потоковое вещание, имеет контроль над сетью между сервером и клиентами (например, в образовательной, правительственной или корпоративной сети), то протоколы маршрутизации, такие как IGMP и PIM, могут быть использованы для доставки мультимедиа нескольким клиентам из различных сегментов LAN.