Потоковая передача. Что такое потоковое мультимедиа

Основная задача заключается в создании системы для обеспечения работы с видеоподкастами (совокупность видео файлов, которые распространяются через Интернет, используя настройки RSS-потока для воспроизведения на переносимых медиа проигрывателях и персональных компьютерах), записанных пользователями и загруженных на сервер. Доступ к видео должен быть предоставлен по запросу пользователя или через подсоединение пользователя к широковещательному каналу в реальном времени. Ряд пользователей (привилегированных) должны иметь возможность создавать подкасты (например, загружать оцифрованное видео стандартных форматов (AVI, MPEG2), записанные на персональную видеокамеру). Все пользователи должны иметь возможность просматривать подкасты через веб-браузеры как часть веб-страницы.

Способы доступа к видео:

Загрузка

Чтобы воспроизвести видео на вашем компьютере, вам необходимо полностью его загрузить. Используется HTTP протокол.

Прогрессивная загрузка

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

Потоковая передача данных

Данный метод публикации требует дополнительного ПО: необходим сервер потоковой передачи данных. Видео информация подается пользователю в форме потока, для просмотра необходим видео проигрыватель потоковой передачи данных. Несмотря на то, что сервер потоковой передачи данных имеет свой собственный формат для потоковых медиа, некоторые из них поддерживают формат MPEG-4 (Darwin Streaming Server/QuickTime Streaming Server, Helix Server, например).

Потоковая передача данных в режиме реального времени

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

Основные задачи сети потоковой передачи видео

Реализация потоковой передачи видео

На текущий момент существует четыре крупные компании, занимающиеся широковещательной потоковой передачей видео. Это такие компании, как: Apple, Real Networks, Adobe и Microsoft. Apple представлена коммерческим QuickTime Streaming Server и его аналогом с открытым исходным кодом – Darwin Streaming Server. Компания Adobe усовершенствовала Macromedia Flash Communication Server и выпустила его под брендом Flash Media Server. Кроме этого, они имеют FLV сервер Red5 с открытым исходным кодом. Real Networks поддерживает сервер Helix. Пользователи Microsoft Windows Server 2003 могут использовать бесплатный Microsoft Video Server, который может транслировать потоковое видео и аудио в специальном формате Microsoft: Windows Media Format.

Конвертация форматов

Не все видео форматы имеют возможность потоковой передачи. Поэтому необходимы специальные инструменты для конвертации видео файлов из формата пользователя в формат, подходящий для потоковой передачи данных. Существует несколько приложений, которые могут выполнить данную задачу весьма эффективно. Одно из них – это ffmpeg – приложение, которое может конвертировать видео файлы в различные форматы. У данного приложения есть еще одно несомненное преимущество – возможность запуска в режиме пакетной обработки для автоматической конвертации форматов. Основным недостатком приложения является некоторая сложность регулирования, дополнительных преобразований и установки библиотек. Данное приложение также может быть скомпилировано в форме статической или динамической библиотеки для дальнейшего использования в проектах C/C++. Также необходимо упомянуть Windows Media Encoder для систем Windows, т.к. данный продукт принадлежит Windows Media Series и позволяет конвертировать видео в несколько форматов. Существует возможность разрабатывать свои собственные компоненты на базе Microsoft Windows Media 9 Series благодаря возможностям совершенствования Windows Media SDK. Этот пакет программ для Windows 2003 Server абсолютно бесплатен.

Adobe Flash Media Encoder представляет собой другой инструмент для кодирования видео, позволяющий конвертировать файлы в формат FLV (Sorenson or кодеки on2). Он может быть запущен из командной строки или в режиме GUI.

Встраивание видео в веб-страницу

Встраивание видео реализуется с помощью объектов ActiveX (для IE) или плагинов. Для каждого из представленных серверов реализуется отдельный вариант встраивания видео в веб-страницу. Потоковая передача видео с помощью серверов Apple (Darwin/QuickTime Streaming Server), также как и посредством сервера Helix совместимого с Apple формата (RealNetworks) транслируется с помощью встроенной стандартной панели инструментов, которую можно скрыть, и своего рода API, чтобы контролировать воспроизведение и текущее состояние видео. Широчайший спектр различных проигрывателей используется с FLV (Flash Media Server, Red5) из-за легкости разработки Flash приложений для взаимодействия FMS/Red5 и широких возможностей среды разработки Flash (фактически, существует только один Flash FLV проигрыватель, но он «завернут» в различные Flash приложения). Но высокая цена сервера Flash Media является безусловным недостатком (особенно для большого количества соединений). Одной из особенностей формата FLV (Flash Live Video) является возможность постепенной загрузки видео с сервера без использования FMS. В таком случае видео не будет передаваться поточно. Воспроизведение потоковой видео трансляции с сервера Windows Media возможно посредством плагинов ActiveX или Windows Media Player. Другие платформы используют сторонние проигрыватели, такие как, например, Starbak Embedded Streaming для Линукса. Также требуется встроенный компонент VBrick для проигрывания потокового видео в форматах Windows Media. Необходимо также встроить RealPlayer или схожий сторонний проигрыватель в страницу, чтобы проигрывать видео в формате RealVideo с сервера Helix.

Варианты развертывания системы

Система потокового видео, базирующаяся на Apple Darwin Server

Сервер: бесплатный сервер Darwin 5.5.1 с открытым исходным кодом для потокового вещания.

Проигрыватель: QuickTime 6 встроенный в веб-страницу.

Конвертер видео: ffmpeg (реализация для Windows или Linux).

Дополнительные требования:

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодировки подкастов в формат MP4 или HINTED MOV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы.

Преимущества: бесплатный сервер потокового вещания, готовый использовать встроенный в веб-страницу проигрыватель.

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

Система потокового видео, базирующаяся на Flash Media Server 2

Сервер: Flash Media Server 2.

Проигрыватель: Flash-приложение, поддерживающее воспроизведение содержимого файла.

Конвертер видео:

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

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

Просмотр подкастов:

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

Недостатки: цена Flash Media Server.

Система потокового видео, базирующаяся на Red5 Server

Сервер: сервер Red5 с открытым исходным кодом.
Проигрыватель: Flash-приложение, поддерживающее воспроизведение содержимого файлов.

Конвертер видео: ffmpeg (реализация для Windows or Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

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

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы, содержащей Flash-приложение.

Преимущества: бесплатный FLV сервер, возможность использования собственного проигрывателя пользователя, гибкость разработки приложения благодаря Flash-технологии.

Недостатки: небольшое количество одновременных подключений (не более 15 для стабильности работы), требуется Java SDK, возможные изменения спецификации RTMP протокола компанией Adobe.

Система прогрессивной загрузки, базирующаяся на FLV

Сервер: Web сервер. Потоковый сервер не требуется.

Проигрыватель: Flash-приложение, поддерживающее проигрывание файлов.

Конвертер видео: ffmpeg (реализация для Windows или Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодирования подкастов в формат FLV для вещания. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализован в режиме постепенной загрузки внутри определенной веб-страницы, содержащей Flash-приложение.

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

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

Система потокового видео, базирующаяся на Windows Media 9 Series

Сервер: Windows Media Server для потоковой передачи данных.

Проигрыватель: Проигрыватель Windows Media Player 9/10, встроенный в веб-страницу, или в сторонний проигрыватель.

Конвертер видео: Microsoft Video Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно). Операционная система – Windows 2003 Server.

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для декодирования подкастов в формат WMV для потокового широковещания. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализован в потоковом режиме внутри определенной веб-страницы.

Преимущества: бесплатный потоковый сервер, если установлена операционная система Windows 2003 Server, готовая к использованию встроенного проигрывателя в веб-страницу.

Недостатки: отсутствие возможности изменять дизайн проигрывателя, необходимость ресурсоемкого конвертирования формата файлов подкаста после добавления, необходимость установки Microsoft Windows 2003 Server, возможные проблемы с просмотром видео на персональном компьютере с другой операционной системой.

При создании локальной сети довольно часто возникает вопрос: «Как транслировать видео поток на компьютеры в локальной сети?» На самом деле всё достаточно просто.

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

Трансляция потокового видео в локальной сети

Итак, для начала следует убедиться, что программа установлена на всех устройствах, которые будут принимать трансляцию видео по локальной сети.

После этого на раздающим компьютере запустите VLC и настройте следующим образом:

Откройте параметры передачи, нажмите ctrl+s или «Медиа» - «Передавать»;

На вкладке «Устройство захвата» выберите «Режим захвата» - «Экран»;

На вкладке «Файл» выберите файл для трансляции и поставьте галочку на «Показать дополнительные параметры»;

- «Кеширование» оставьте 300 мс;

- «Строка параметров» следующий скрипт:

:screen-left=0:screen-top=0:screen-height=768:screen-width=1360:screen-fps=20.000000:live-caching=300

Теперь в выпадающем списке выберите «HTTP» - «Добавить» (перед этим можно поставить галочку на «Воспроизводить локально»);

Порт можно оставить как есть, а путь к файлу, например, 1.ts;

В разделе «Настройки» можно, если требуется, отключить аудио, оставив только картинку, включить субтитры и т.д;

Нажмите «Поток»: если всё сделано верно, то запустится файл, который был добавлен для трансляции;

Теперь, необходимо , который будет транслировать видео. Легче всего это сделать в «Командной строке» через команду ipconfig /all: в появившейся таблице в пункте IPv4-адрес и будет указан ip.

Как транслировать видео в локальную сеть?

И в завершении настройки для запуска трансляции видео на принимающих компьютерах запустите программу и сделайте следующее:

• - нажмите ctrl+N или «Медиа» - «Открыть URL»;
• - и пропишите путь трансляции, на примере это http://192.168.x.xxx:8080/1.ts

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

Введение

Кажется, компании-производители потребительского сетевого оборудования решительно нацелены на продвижение своих 2,4-ГГц продуктов в качестве решений для трансляции потокового видео по домашней сети. А Голливуд сегодня всеми силами пытается не допустить утечку драгоценных бит куда бы то ни было. Впрочем, DRM-защита ещё не добралась до видеофайлов пользователей, поэтому как насчёт того, чтобы закупиться оборудованием и смотреть по сети потоковое видео?

Ранее мы уже обращались к производителям сетевого "железа" с тем, чтобы они перестали рекламировать WLAN-оборудование для диапазона 2,4 ГГц для трансляции потокового видео. Так как диапазон 2,4 ГГц используется также микроволновыми печами, беспроводными телефонами и другим оборудованием, не говоря о Wi-Fi, то существует огромное количество потенциальных источников помех. Если вам мало проблем от бытового оборудования, то несколько соседних беспроводных сетей смогут причинить настоящую головную боль, заняв весь доступный диапазон частот. В результате многие из тех, кто решается на использование беспроводной сети, вряд ли смогут пользоваться её ресурсами даже для web-серфинга, чтения электронной почты, чатов и игр, не говоря уже о таких требовательных к полосе пропускания приложениях, как потоковое видео.

Мы решили настроить передачу данных по беспроводной сети диапазона 2,4 ГГц для потокового видео, то есть как раз так, как любят вбивать в головы потребителей производители оборудования. Наверное, производителям не стоит быть настолько самоуверенными. Но на этом мы не остановились. Давайте посмотрим, почему же перегруженный диапазон так плох для нашего сценария.

Эффекты перегруженного спектра

Если вы являетесь одним из тех счастливчиков, кто живёт в условиях свободного диапазона 2,4 ГГц, то всё, о чём нужно беспокоиться, - это полоса пропускания оборудования в тех местоположениях, где вы собираетесь смотреть видео. К счастью, над решением этой задачи, то есть над увеличением скорости и расстояния, работает большая часть всей индустрии. Последним шагом увеличения скорости и расстояния является разработка стандарта 802.11n, который в очередной раз повышает теоретическую пиковую скорость работы сети 802.11 до 200 Мбит/с для физического уровня (иногда даже ближе к 300 Мбит/с). Такое увеличение скорости предоставит пользователю полосу порядка 100 Мбит/с, чего вполне достаточно для трансляции любого потокового видео.

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

Мы пришли к выводу, что в большинстве случаев диапазон 2,4 ГГц, используемый оборудованием 802.11b/g, окажется слишком переполненным, чтобы использовать его для приложений потокового видео. Что же такое перегруженность диапазона и чем она отличается от простой нехватки скорости на желаемом расстоянии?

Вот три основных эффекта перегруженности спектра.

• Уменьшение полосы пропускания
  - проще говоря, множество соседних сетей пытаются использовать одни и те же частоты. Это чревато не только снижением скорости работы, но и существенными её колебаниями, поскольку все соседние сети пытаются получить кусок общего канала.
• Большие потери пакетов
  - высокий уровень "шума", создаваемый соседним каналом и источниками, отличными от Wi-Fi (микроволновые печи, телефоны и другое), может стать причиной снижения скорости, поскольку при потере или повреждении пакета происходит его повторная пересылка. В худшем случае, появляются неисправимые ошибки.
• Нестабильное подключение
  - пользователи сетей Wi-Fi в местах их большого количества знакомы с проблемой подключения к чужой сети. Это связано с тем, что сигнал соседней точки доступа или маршрутизатора оказывается сильнее сигнала собственной. Это дополняется оставленными по умолчанию настройками встроенной утилиты конфигурирования беспроводной сети в Windows.

Очевидно, что при выходе за минимальную полосу пропускания, или если соединение будет постоянно пропадать, то приложение не будет работать. Но какие потери пакетов допустимы при трансляции видео-потока без ущерба для просмотра?

Эмуляция ошибок

Компания Apposite Technologies позволила нам воспользоваться её решением Linktropy 4500 WAN Emulator (рис. 1 ), чтобы ответить на возникшие вопросы. Устройство является аппаратным эмулятором, который позволяет выполнять настройки скорости входящего и исходящего потока, задержки и потери. Для настройки используется web-интерфейс, для доступа к которому необходимо подключиться к специальному порту Ethernet (или через клиентский компьютер после задания соответствующей опции в настройке). Если вам более по душе интерфейс командной строки, то можно подключиться через последовательный порт и получить консольный доступ.

Рис. 1. Apposite Technologies Linktropy 4500 WAN Emulator.

Для работы 4500 нужно подключить его между любыми двумя сегментами Ethernet LAN. Для подключения на эмуляторе имеются два порта 10/100/1000: LAN A и B. По умолчанию устройство работает как прозрачный интеллектуальный мост с любым протоколом. Однако, при желании, его можно переключить в режим маршрутизатора для работы с IP, но в этом режиме не поддерживается работа с трафиком multicast-приложений.

При подключении на интерфейсе управления задаются желаемые параметры сети (рис. 2 ). Эмуляцию можно включить или отключить при помощи специальной кнопки на интерфейсе (Emulation On/Off ) без изменения других настроек.

Как уже упоминалось ранее, можно настраивать пропускную способность, задержки и потери для всего трафика, проходящего через 4500 в обоих направлениях. Задержка (delay) - единственный параметр, который может не только быть фиксировано заданным (Constant), но и может динамически меняться с равномерным (Uniform) или нормальным (Normal) статистическим распределением. Вообще, неплохо было бы получить подобное динамическое изменение параметров потерь и, возможно, пропускной способности. Тогда мы смогли бы лучше эмулировать беспроводное соединение. Впрочем, посмотреть на эффект от потери кадров можно и в статическом режиме.

Теперь можно подключать 4500 к сети. В нашем случае мы подключили порт LAN A к порту коммутатора LAN, а порт LAN B - к одному из компьютеров. Мы без проблем разобрались с работой 4500. Хотя, надо сказать, весьма долго искали опцию, которая включает доступ к web-интерфейсу администрирования из локальной сети, а не только через выделенный порт.

Размер потока и кодирование

На самом деле, есть два способа воспроизведения удалённых медиа-файлов. Можно просто взять ПК или другое устройство, способное работать с локальными и сетевыми файлами. Тогда достаточно будет найти в сети и запустить на воспроизведение нужный файл. Он будет воспроизводиться через ту сетевую файловую систему, которую использует ваша ОС. В большинстве случаев это будет SMB (Server Message Block) , работающая на верхних уровнях стека TCP/IP.

Другой способ - использовать для воспроизведения медиа-сервер и протокол потокового вещания , который будет доставлять медиа-поток от сервера к плееру. Для передачи потока используются такие протоколы, как RTP и RTCP, работающие поверх UDP.

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

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

Мы протестировали оба описанных выше способа, используя для этого три тестовых файла:

• DVD VOB, кодек MPEG 2;
• файл DivX с кодеком DX50 в разрешении 640x300 при 24 кадрах в секунду;
• PSP avc1 (MPEG 4), разрешение 368x208 при 30 кадрах в секунду.

Для вещания и воспроизведения потока мы использовали VideoLAN VLC Media player 0.8.5. Выбор пал на плеер VLC, потому что он позволяет работать со всеми перечисленными типами файлов и может как просто открывать медиа-файл, так и воспроизводить поток с другого VLC-плеера, работающего в серверном режиме. Вещание выполнялось в режиме VLC UDP при настройках по умолчанию без перекодировки.

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

Чтобы узнать реальный битрейт воспроизводимого файла, нужно взять утилиту, показывающую поток данных, проходящий через сетевой адаптер. Мы испробовали несколько решений, после чего остановились на Hoo Technologies Net Meter . Утилита позволяет практически всё, что можно ожидать от измерителя скорости (кроме кнопки очистки графика; для этого приходилось перезапускать утилиту). Hoo Technologies Net Meter совместима с Win 98, ME, NT, 2000 и XP, имеет бесплатный тестовый период 30 дней, цена составляет $20.

На рис. 4 и 5 показаны графики, полученные при воспроизведении первых четырёх минут тестового VOB-файла в обоих режимах.

Рис. 4. График для воспроизведения файла VOB (MPEG 2).

Для VOB значение максимальной и средней скорости при воспроизведении потока оказались примерно на 20% ниже, чем при воспроизведении файла. При этом отношение максимальной скорости потока к средней в обоих случаях составило около 1,6.

Рис. 5. График для воспроизведения VOB (MPEG 2) в потоковом режиме.

На рис. 6 и 7 показаны графики, полученные при воспроизведении тестового DivX файла в обоих режимах.

Рис. 6. График для воспроизведения файла DivX.

В этот раз максимальный битрейт при воспроизведении файла DivX оказался примерно на 20% ниже, чем при воспроизведении потока, при этом средние значения практически не отличались. Отношение максимальной скорости к средней при файловом режиме составило 4,3, в потоковом - 4,8, максимум из всех тестов.

Рис. 7. График для воспроизведения DivX в потоковом режиме.

И, наконец, на рис. 8 и 9 показаны графики для PSP/MPEG4.

Рис. 8. График для воспроизведения файла PSP.

И снова средняя скорость для потока и для файла оказалась практически одинаковой, а максимальная для потока оказалась ниже, чем для файла, примерно на 10%. Отношение максимальной скорости к средней составило 2,8 для файла и 2,2 для потока.

Рис. 9. График для воспроизведения потока PSP.

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

Изначально мы также включили в тестирование файлы Quicktime 7 HD, сжатые при помощи H.264, но были вынуждены отказаться от этой затеи. VLC поддерживает H.264 лишь в экспериментальном режиме (), и у нас возникли проблемы при воспроизведении различных файлов с сайта Apple. А от плеера Quicktime нам пришлось отказаться, поскольку он не смог открыть поток с сервера VLC.

Чувствительность к потерям пакетов при потоковой передачи

Мы продолжили наше тестирование, задавая различные значения потерь пакетов при помощи Linktropy 4500. Для начала мы установили потери в 1% для потокового режима, в результате увидели искажения (квадраты). Затем мы запустили серию тестов, результаты которых показаны в таблицах ниже. Просим прощения за субъективность в описании результатов, однако, лучшего способа охарактеризовать их мы не нашли.

Мы также приводим скриншоты артефактов, полученных при воспроизведении, чтобы вы могли судить об увиденном.

На Рис. 12 показан скриншот при потерях 0,05%. То есть даже при незначительных потерях искажения могут быть весьма существенными!

Рис. 12. Поток PSP/MPEG4 с потерями 0,05%.

Тестирование привело нас к следующим заключениям:

• для появления проблем с потоковым видео достаточно очень малых потерь пакетов;
• при потерях пакетов битрейт и способ кодирования практически не влияют на качество воспроизведения.

Чувствительность к потерям пакетов при воспроизведении файлов

После тестирования потокового режима мы решили повторить тесты при файловом воспроизведении и получили совсем другие результаты. Как и следовало ожидать, из-за способности TCP/IP корректировать ошибки передачи, здесь гораздо сложнее добиться проблем с воспроизведением видео. А если проблемы и возникнут, то в виде пауз или пропусков, но не как искажения картинки.

Чтобы видео отказалось воспроизводиться, нам пришлось прибегнуть к задержкам c равномерным распределением и потерям пакетов. При потерях 1% пакетов и задержках между 10 и 500 мс воспроизведение VOB-файла периодически замирало и, в конце концов, через несколько минут остановилось полностью. При тех же настройках и том же ролике, но уже сжатом в формат DivX (качество Home Theater Quality), паузы стали реже, и мы смогли досмотреть ролик до конца.

Здесь мы пришли к следующим выводам:

• если воспроизводить файлы через TCP/IP, то чувствительность к потерям пакетов оказывается меньше, чем с протоколом UDP;
• битрейт и способ кодирования влияют на восприимчивость к ошибкам передачи.

Заключение

Мы были удивлены: даже незначительные потери пакетов приводят к тому, что потоковое видео становится просто невозможно смотреть! Напротив, если использовать протокол TCP/IP, то создать помехи во время просмотра гораздо сложнее. Во второй части нашей статьи мы посмотрим, как работает потоковое видео в беспроводных сетях. И что нужно сделать, чтобы оно работало хорошо.

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

Например, компьютер пользователя находится в удаленном сегменте локальной сети (или даже в другом городе). Данные, в виде серии последовательных пакетов, подготовленных специальным образом, передаются на вход его ПК, где происходит их декодирование. После чего пакеты "собираются" в исходный материал, который и выводится на монитор пользователя в виде исходной последовательности видео или аудио.

Ярким примером этого может служить, набирающий сейчас популярность, Интернет-стриминг, когда оператор в режиме реального времени транслирует изображение со своей камеры в сеть Интернет, а оттуда его уже "подхватывают" пользователи, подключившиеся к трансляции. Можно обеспечить и потоковую передачу материала, уже сохраненного на компьютера (запустить в сеть трансляцию нового фильма ужасов или клипа любимой рок-группы) :) Или организовать прямую трансляцию с веб-камеры, подключенной к USB порту нашего ПК.

Общая схема этого действия при этом выглядит следующим образом:

Но обо всем по порядку! Сегодня мы будем говорить о передаче именно потокового видео. Существуют специальные протоколы передачи потоковых данных: RTMP, PNM, RTSP, MMS, RTSPU, RTSPT, MMS, MMST и т.д. Они "на лету" преобразуют исходные данные таким образом, что они могут быть переданы в сеть, как непрерывная последовательность. Использование передовых технологий сжатия и буферизации позволяет просамтривать потоковый контент с любого места, не дожидаясь его полной загрузки на компьютер пользователя.

Предлагаю на этом покончить с теорией и посмотреть на практике, что же это такое потоковая передача видео? А там уж сами для себя решите, нужна лично Вам эта технология или нет, ок?

Сегодня я хочу рассказать Вам об одном замечательном продукте: «Unreal Media Server». Честно скажу, я просто балдею от этого программного комплекса! :) Не знаю, как обстоят сейчас дела на "фронтах" потоковой передачи мультимедиа, но когда я активно интересовался этим вопросом (перепробовал множество решений), то "адекватного" ПО можно было пересчитать по пальцах одной руки. То сервер принципиально платный (не попробуешь), то - не работает, то работает, но - "криво", видео передается с дикими задержками и "тормозами", какие-то решения откровенно тяжелы в настройке, что и разбираться не охота и т.д.

И вот, случайно натыкаюсь я на это замечательное решение. Размер сервера - всего несколько мегабайт, плеера - 500 килобайт! Все работает, видеопоток проигрывается плавно и без задержек. Лишних (избыточных и малоиспользуемых) функций нет, интуитивно понятный графический интерфейс. Короче говоря, куда ни посмотри - одни сплошные плюсы. Минусов даже не нашел:)

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

После этого я убедился: «Unreal Media Server» достоин отдельной развернутой статьи на нашем сайте! :) Итак, давайте зайдем на сайт разработчиков данного ПО: umediaserver.net В верхнем левом углу мы увидим ссылку «Produkts», нажимаем на нее. В появившемся списке выбираем «Unreal Media Server».

Затем, в правом боковом меню ищем пункт «Download» (загрузить).

Попадаем на страницу, с которой можем скачать себе на компьютер необходимые дистрибутивы и дополнительные компоненты (плагины).

Нас, в первую очередь будут интересовать базовые компоненты, показанные на фото выше:

• Unreal Media Server - сам потоковый медиа-сервер
• Unreal Live Server - компонент для организации прямой трансляции с IP или веб-камер
• Streaming Media Player - плеер, который позволяет просматривать видео

Обратите внимание на размеры дистрибутивов программного комплекса! Итак, загружаем все три компонента себе на компьютер:

Давайте, для начала, установим основной модуль - «UMedia Server». Сам процесс инсталляции я не буду описывать и приводить его скриншоты (просто не хочу раздувать статью). Он сводится к нескольким нажатиям на кнопку «Next» и не представляет ничего сложного.

После завершения установки, нажмем на кнопку "Пуск" в панели задач и выберем "Все программы". Среди прочего, мы увидим новую группу «Unreal Streaming», куда и будут добавляться все устанавливаемые компоненты нашего комплекса.

Media Server Configurator позволяет нам производить основную настройку приложения. Возможно, это покажется шуткой, но наш потоковый видеосервер уже готов к работе и может транслировать видео в сеть! Без всякой дополнительной конфигурации! Вот за это мне он тоже нравится:)

Но мы, я надеюсь, хотим твердой рукой сами управлять всеми процессами и понимать что происходит? Тогда давайте запасемся терпением и рассмотрим основные компоненты всего программного комплекса потокового видео. Запускаем Media Server Configurator и видим его главное окно.

Обратите внимание на секции «File Resources» «Live broadcasts». Первая отвечает за воспроизведение по сети файлов, уже хранящихся в специальной папке сервера и готовых к их потоковой трансляции (видеоклипы, фильмы, презентации), а вторая секция используется при организации "живого" (Live) вещания с IP или веб-камеры.

Сейчас мы рассмотрим первый вариант передачи видео, которое хранится на нашем компьютере. Обратите внимание на папку «MediaRoot», которая по умолчанию уже создана на сервере (скриншот выше). Нажав на нее, в правой части окна мы можем увидеть полный путь к ней.

Можем зайти по этому адресу и увидим там один файл test.avi, показанный на фото выше. Именно в эту папку нам нужно будет "складировать" все наши видеофайлы, которые мы хотим транслировать по сети.

Сейчас, не откладывая в долгий ящик, предлагаю организовать просмотр этого тестового файла test.avi на удаленном компьютере. Для этого настроим сеть между двумя нашими ПК: на том, где мы будем инсталлировать серверные компоненты установлена 32-х разрядная Windows 7, а "клиентом" у нас будет выступать старая-добрая Windows ХР.

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

На компьютер с ХР мы установим Streaming Media Player (установка также очень проста и не требует дополнительных пояснений). Значок плеера, как всегда, ищем под кнопкой "Пуск".

Запускаем его и пробуем проиграть на нем файл test.avi, расположенный на первом нашем компьютере. Для этого нажимаем в верхнем меню на надпись «Play» и из появившегося списка выбираем команду «Play file» (проиграть файл).

В появившемся окне нам надо будет указать базовые настройки подключения. Это - логично, ведь плеер "не знает", где у нас расположен сервер потокового видео и какой именно файл нужно с него проиграть? Вот это нам и нужно ему "объяснить".

В поле «Media Server IP address» указываем сетевой адрес сервера (зависит от того, какой IP мы присвоили компьютеру на этапе настройки сети), в поле «Port» - значение порта, по которому будет осуществляться взаимодействие (обычно он прописан здесь про умолчанию, но, на всякий случай, запомните его номер: 5119).

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

Продолжим! Опции «Protocol» нужны для выбора типа сетевого протокола, который будет использоваться для передачи данных. Можете оставить по умолчанию - TCP (Transmission Control Protocol - протокол управления передачей данных).

Поле «File name including virtual folder» служит для указания виртуальной папки хранения наших файлов потокового видео. Как мы помним, это папка «MediaRoot», рассмотренная нами на одном из предыдущих скриншотов. Через слэш указываем имя и расширение файла, который мы хотим получить (воспроизвести) с сервера и нажимаем кнопку «ОК».

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

Как видите, все на самом деле очень просто:)

Примечание : При тестировании данного программного комплекса можете располагать все его компоненты на одном компьютере. Сеть между двумя ПК мы создавали здесь только для того чтобы продемонстрировать, как это все работает в условиях, приближенных к "боевым".

Вы можете задать очевидный вопрос: а какие форматы (расширения) видеофайлов поддерживаются данным сервером потокового видео? Отвечу скриншотом, который можно найти на официальном сайте проекта:

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

Давайте рассмотрим некоторые настройки, которые мы, при желании, можем изменить в нашем сервере. Что мы можем сделать? Можем, к примеру, изменить виртуальную директорию для хранения и распространения нашего контента. Это делается в главном окне сервера с помощью меню «File» и опции «Nev virtual folder» (новая виртуальная папка).

Откроется окно с настройками. В нем нас (в рамках данной задачи) будут интересовать только первые при поля:

1. Folder name - имя новой виртуальной папки (задаем произвольно)
2. Browse - выбираем папку для привязки виртуальной директории (можете создать любую). Можете указать полный путь к уже существующей -
   C:\\Program Files\UnrealStreaming\UMediaServer\MediaRoot
3. Description - описание папки (задается по желанию)

Для сохранения настроек нажимаем «ОК» и видим, что в "дереве" каталогов у нас появилось новое виртуальное "хранилище" для наших видеофайлов.

Таким образом, можно создать несколько тематических хранилищ и распределить по ним видеоконтент. В любой момент можно просто удалить или временно отключить любую папку, нажав на ней правой кнопкой мыши и выбрать из появившегося списка команду «Delete virtual folder» (удалить виртуальную папку) или «Disable virtual folder» (отключить виртуальную папку).

Теперь, при подключении к серверу потокового видео вместо папки MediaRoot (используемой по умолчанию), мы должны будем в поле «File name including virtual folder» вручную указать новое название: в моем случае - my_video (запрашиваемый файл test.avi остается без изменений).

Надеюсь, сама концепция передачи потокового видео стала более понятна тем нашим читателям, которые раньше с ней не сталкивались? Для людей же, имеющих опыт в этом деле, - знакомство с новым ПО, что само по себе тоже неплохо:)

Продолжим! Сейчас давайте запаролим доступ к воспроизведению файлов. Зачем? Не знаю, но можно при случае воспользоваться:) Опять обратимся к меню «File» - опция «Properties» (свойства).

Появится вот такое серьезное окно:

Примечание : в любом "серьезном" окне главное найти и сконцентрироваться на той его части, которая отвечает за нужную нам на данный момент функцию. Остальное нужно игнорировать! :)

На скриншоте выше я хочу обратить Ваше внимание на места, отмеченные красным. Прежде всего, - это два информационных поля, где записаны номера портов по которым осуществляется передача видеопотока. Рекомендую их запомнить или просто вспомнить в нужный момент, где их можно подсмотреть? :) Порт 5119 - для Unreal плеера и 5130 - для сервера живой (Live) трансляции с камеры (об этом мы поговорим отдельно).

Итак, все что нам нужно от этого окна для организации доступа к видео по паролю, так это кнопка «Add User» и переключатель «Internal Authentication» (Внешняя аутентификация). Переключаем, нажимаем на «Add User» и видим вот такое окно:

На фото выше указываем произвольное имя пользователя для доступа к видеопотоку и придумываем пароль, подтверждая его дважды. Можем больше ничего не менять и сразу нажать «ОК».

Теперь снова запустим на удаленном компьютере Unreal плеер и попробуем "поймать" потоковое видео с сервера. Увидим вот такое приглашение на ввод логина и пароля:

Можем поставить "галочку" рядом с надписью «remember my credentials locally» (запомнить мои учетные данные локально), тогда пользователю, подключающегося повторно с этого компьютера, не нужно будет вводить пароль заново. После заполнения полей нажимаем «ОК» и наше видео успешно отображается!

Для того, чтобы удалить пользователя с сервера и отменить саму аутентификацию по паролю, нам нужно вернуться в "серьезное" окно с настройками, выделить учетную запись пользователя и нажать кнопку «Remove user» (удалить пользователя). Не забудьте вернуть переключатель в положение «Anonymous access» - анонимный доступ! Нажимаем кнопку «ОК», сохраняя настройки.

Думаю, придется разбить нашу статью на две части, а то и так уже слишком длинная "простыня" текста получается. Так и поступим! Тем более, что это будет логичным: в данной (первой) ее части мы рассмотрим организацию трансляции потокового видео из заранее подготовленных файлов, а вторую часть статьи посвятим живой трансляции с камеры и работе с Unreal Live Server.

Перед тем как мы прервемся, давайте во взаимодействии с сервером потокового видео попробуем обойтись без проприетарного (фирменного) плеера Unreal, а задействовать стандартный медиаплеер Windows. Да, он такое умеет! :) Запускаем наш плеер: «Пуск» - «Все программы» - «Проигрыватель Windows Media». Выбираем меню «Файл» (если такового нет, нажимаем клавишу «Alt» на клавиатуре) и из появившегося списка - «Открыть URL-адрес».

Примечание : Windows медиаплеер умеет открывать (подключаться) к потокам видео, распространяемым через сеть. Вот этой его функцией мы и воспользуемся!

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

Присмотревшись внимательно, мы обнаружим, что почти все составляющие адреса нам уже знакомы (мы так или иначе сталкивались с ними по ходу данной статьи). Явное исключение составляет здесь "новый" протокол передачи MMS (Microsoft Media Server протокол). Это алгоритм передачи медийного контента компании Microsoft. Сейчас на смену ему пришел более прогрессивный RTSP (Real Time Stream Protocol), но mms оставлен для обеспечения обратной совместимости.

Вот этим мы и воспользуемся! Итак, указываем протокол подключения к серверу (mms), его IP адрес (в нашем случае это 192.168.1.2), порт сервера, на котором он "ждет" подключения (5119, обратите внимание, что после IP адреса порт указывается через двоеточие), дальше прописываем виртуальную папку с видеофайлами (помните, что мы изменили ее на my_video) и в завершении - запрашиваемый нами файл с указанием поддерживаемого сервером расширения (test.avi).

Примечание : если в Windows Mediaplayer не настроены типы (привязки) файлов, может появиться соответствующий запрос. Все что от нас требуется, это несколько раз нажать на кнопку «Далее». Все остальное медиаплеер сделает сам:)

Нажимаем кнопку «ОК». Если мы все сделали правильно (о, эта сакраментальная фраза!), то запустится окно Windows медиаплеера, в котором вверху мы увидим процент буферизации (предварительной загрузки) запрашиваемого нами видео.

Когда это значение достигнет 100% (это произойдет достаточно быстро), видео начнет проигрываться.

А теперь, как и договаривались, переходим ко второй части нашей статьи, посвященной живой трансляции с использованием программного обеспечения Unreal Media Server. Нажимайте на надпись "продолжение" внизу статьи.

Звуковые и видеофайлы имеют большой информационный объем.
Для передачи таких файлов по компьютерным сетям в стандартных цифровых форматах требуются линии связи с высокой пропускной способностью. Цифровой стереозвук высокого качества требует скорости передачи данных, равной 1,5 Мбит/с.
Цифровое видео телевизионного стандарта требует для передачи изображения скорости передачи данных около 240 Мбит/с.
Для уменьшения объемов звуковых и видеофайлов без ощущаемой потери качества используются специальные методы сжатия, основанные на удалении не воспринимаемой человеком звуковой или видеоинформации.

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

Существует достаточно много радио- и телевизионных станций, которые осуществляют вещание через Интернет. Широкой популярностью пользуются Web-камеры, установленные в самых разных уголках мира (на улицах городов, в музеях, в заповедниках и т. д.) и непрерывно передающие изображение.