Всем привет! Друзья, в этой статье поговорим о том, как можно смотреть потоковое видео на телевизоре с помощью девайса на Андроид. Тема эта очень даже интересная и вроде простая в своей реализации.

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

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

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

  • Отправка видео из страницы браузера
  • Отправка видео из многих приложений
  • Поддержка плейлистов с каналами HLS
  • Отправка ссылок на видео из ВКонтакте

И это далеко не полный перечень всех доступных опций. Но давайте обо всем по порядку. Первым делом нужно установить VEGA Cast на платформу с Андроид из официального магазина по этой ссылке :

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

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

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

Теперь давайте рассмотрим всю схему на реальном примере. Для этого открываем мобильную версию онлайн-кинотеатра Kinopub и выбираем любой понравившийся фильм.

Затем при помощи уже знакомого нам меню выбираем качество и нажимаем «Отправить»:

На следующем шаге будет предложено указать нужный формат, что не столь важно, после чего появится дополнительное меню, в котором следует выбрать опцию «VEGA Cast — смотреть через Chromecast»:

После этого запустится процесс обнаружения устройства:

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

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

Ведь если прочитать полное название данного приложения, то звучит оно так: VEGA Cast (для Chromecast). И вот этот самый Chromecast есть не что иное, как отдельное устройство, которое втыкается в HDMI-порт телика. Выглядит оно так:

И, естественно, применять его для передачи потокового видео есть смысл только в том случае, когда телевизор не поддерживает технологии Smart TV либо DLNA. То есть по-другому к нему никак нельзя достучаться.

Получается, что в нашей ситуации использование данной программы вообще нецелесообразно, поскольку для «умных» ТВ должны существовать бесплатные передачи изображения.

Хотя, конечно, может кому-то и приглянется такой способ смотреть потоковое видео на телевизоре через Андроид, потому что устройство Chromecast довольно популярное, хоть и не совсем дешевое.

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

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

Для решения проблемы быстрого доступа к медиа-файлам через Интернет используется сочетание агрессивной компрессии с потоковой передачей данных. Сетевые протоколы пересылают файлы "пакетами" - фрагментами данных, непригодными для непрерывного проигрывания. Для обеспечения работоспособности технологии приложения для приёма-передачи данных реализуют по, при которой сервер собирает поток и, при получении запроса от клиента, отправляет этот поток ему. Клиент же получает данные, обрабатывает их и преобразовывает в звук и изображение. Если клиент получает данные недостаточно быстро, их воспроизведение не будет гладким, то есть будет обрываться или замирать. Возможна и обратная ситуация, когда приложение получает данные быстрее, чем воспроизводит. Для преодоления этой проблемы приложения, осуществляющие потоковую передачу медиа-данных, сохраняют полученные пакеты данных в памяти ("буферизируют"), вследствие чего обеспечивается проигрывание файла с постоянной скоростью. Компрессия данных является компромиссом между качеством передаваемых данных и скоростью самого компьютера, а также скоростью доступа в интернет.

Изначально потоковая передача данных применялась для передачи аудио (интернет-радио и т.п.) Первая аудио-трансляция в интернете была произведена в США в августе 1994 г. Пионером в этой области стала компания RealNetworks (носившая тогда название Progressive Networks) основанная в 1995 г., а их формат постепенно завоевал популярность и превратился в общепринятый стандарт, наравне с такими популярными сегодня форматами, как Flash или MP3. В последних версиях RealAudio предусматриваются динамическая компрессия, которая может переключаться в зависимости от качества соединения, а также обработка аудиоданных в реальном времени на стороне клиента (например, очистка и восстановление полученного звука). Компанией RealNetworks был также разработан формат RealVideo (1997 г.), однако в Российском сегменте интернета он не получил сильного распространения.

У аудиоверсий форматов QuickTime (первый релиз 2 декабря 1991 г.) и Windows Media имеются особенности, связанные с потоковой передачей данных. Так, при кодировании файлов в формат Windows Media Audio (WMA) используется непосредственно операционная система, вследствие чего, при желании, файлы можно закодировать так, что открыть их смогут только определенные пользователи. Технология DRM (Digital Rights Management, или система управления правами на цифровые данные) позволяет поставщикам данных различного содержания шифровать файлы таким образом, чтобы открыть их можно было лишь при наличии специального ключа (вполне естественно, что эту технологию особенно пылко приветствуют представители музыкальной индустрии). Помимо Windows Media DRM существует и другая, немного отличная от нее система шифрования и дистрибуции под названием Liquid Audio, которая поддерживается и программой Windows Media Player, и программой RealPlayer.

С увеличением скорости доступа в интернет у пользователей появилась возможность организовать не только аудио, но и видео-трансляции. Однако первая трансляция была произведена американским телеканалом ABC ещё в 1994 г. Для приёма передач использовался клиент CU-SeeMe, разработанный в 1992 г. Однако клиент CU-SeeMe не стал популярным. По способу организации потока различают протоколы "последовательные" (Progressive Streaming) и "в реальном времени" (Real-time Streaming). Передачу последовательным способом организовать проще, поскольку видео загружается на жёсткий диск пользователя и воспроизводится уже с него. Для его передачи достаточно воспользоваться обычным вэб-сервером. При организации передачи данных в реальном времени необходим специальный потоковый сервер (Unreal Media Server, Adobe Flash Media Server и тп.). Для воспроизведения потокового видео сейчас наиболее популярны протоколы RTSP, Multicast, RTMP, а также P2P и ещё несколько менее популярных реализаций:

  1. Дейтаграммные протоколы, такие как UDP (User Datagram Protocol), отправляют поток медиаинформации как поток отдельных маленьких пакетов. Протокол прост и эффективен, но в спецификации протокола нет гарантии доставки данных получателю. Это сильно затрудняет поиск и исправление получаемых данных принимающим информацию приложением. При потере данных поток может быть отключен.
  2. Протоколы RTSP (Real-Time Streaming Protocol), RTP (Real-time transport protocol) и RTCP (Real-Time Control Protocol) специально разрабатывались для передачи мультимедийной информации по сети. В протоколах предусмотрена возможность контролируемой передачи видеопотока. Последние два построены на основе UDP.
  3. Надежные протоколы, такие как TCP, гарантируют корректность получаемых данных клиентами потокового вещания. Однако передаваемая информация может стать неактуальной при большом количестве ошибок в пакете данных, что также может вызвать значительные задержки на время, затраченное на пересылку поврежденной информации.
  4. Протоколы Unicast отправляют отдельную копию данных каждому клиенту. Unicast подходит для большинства пользователей сети Интернет, но сильно затрудняет масштабирование сервера для бо́льшего количества клиентов. При широковещательной передаче одна копия данных передается всем клиентам сервера.
  5. Протоколы Multicast разработаны для снижения нагрузки с серверов при получении потокового мультимедиа большим количеством клиентов. Эти протоколы отсылают одну порцию данных целой группе клиентов. Одним из потенциальных недостатков групповой передачи данных является отсутствие возможности реализовать функцию "видео по запросу", а также невозможность управлять воспроизведением со стороны пользователя. Однако эта проблема может быть решена внедрением в сеть передачи данных кэширующих серверов и буферизирующего принимаемый поток программного обеспечения.
  6. Протокол RTMP (Real Time Messaging Protocol) разработан компанией Adobe и реализован в Adobe Flash Media Server. На данный момент это наиболее распространённый протокол. Он массово используется во встраиваемых в веб-страницы flash-плеерах.
  7. Протоколы P2P (Peer-to-peer) могут использоваться при распространении предварительно сохраненного мультимедиа контента между компьютерами. Это снимает нагрузку с сервера, однако сеть передачи данных между сервером и одним из клиентов становится узким местом данного варианта реализации потокового вещания информации.
Для организации потокового вещания необходим сервер. Наиболее популярными реализациями являются: Adobe Flash Media Server, Icecast и Red5.
Воспроизводить потоковое вещание могут практически все, однако наиболее часто используются и программа, позволяющая организовать передачу данных по протоколу P2P. Популярные программы QuickTime и Windows Media также имеют возможность воспроизведения потокового видео, но редко используются для этого. Также распространена универсальная программа с открытым исходным кодом VideoLAN, которая позволяет не только получать, но и создавать свои потоки данных.

Используемые источники:

Для транслирования видео, необходимо выбрать команду меню программы Медиа -> Потоковое вещание. Выбираем файлы, которые необходимо вещать. Смотрите рисунок ниже:

Потом нажимаем кнопку "Поток". В появившемся окне открываем закладку "Destinations" и выбираем HTTP. Смотрите картинку ниже:

На закладке HTTP, вводим IP адрес 127.0.0.1 и порт 8080. Настройки перекодирования необходимо оставить по умолчанию. Или вы можете его поменять, это на ваше усмотрение, но возможно, что с другим кодеком видео не будет транслироваться. Также в настройках перекодировки можно накладывать субтитры на видео.

На закладке "Options" можно найти пример командной строки.

После всех настроек нажимаем кнопку "Поток". Теперь вещание должно пойти, чтобы его проверить, можете открыть этот поток другим VLC или любым другим плеером, открыв адрес http://127.0.0.1:8080.

Стоит отметь, если вы хотите, чтобы трансляция видеофайлов шла непрерывно, то вам необходимо установить непрерывное проигрывание в настройках Playlist-а. Это можно сделать, выбрав пункт меню View->Playlist. В появившемся диалоге установить непрерывную версию.

Как просматривать поток вещания VLC?

Для просмотра потока вещания в VLC необходимо выбрать пункт меню Медиа -> Открыть URL. Выбираем нужный протокол, предположим HTTP, и вводим адрес. Адрес вводится, исходя из следующего формата адрес:порт. То есть, для адреса 127.0.0.1 и порта 8080 адрес будет выглядеть как 127.0.0.1:8080. После нажимаем клавишу "Воспроизвести". Теперь, если всё сделано правильно, можете наслаждаться фильмом.

Стоит помянуть, что адрес может быть и другой, например videohost.ru/my.wmv.

Протестировано на версии VLC 1.0.0

Как сохранить поток вещания с помощью VLC?

С помощью VLC можно не только принимать видео, но и сохранять его, если вы захотите его просмотреть позже. Для этого необходимо открыть меню сохранения, выбираем меню VLC плеера Медиа -> Конвертировать/Сохранить:

После откроется меню открытия файла. В этом окне перейдите на вкладку "Сеть", смотрите картинку выше. После нажатия кнопки "Конвертировать/Сохранить" появится окно:

В этом окне выберите имя файла для сохранения. Установив галочку "Отображать Вывод", вы будите видеть то, что сохраняете. После нажимайте кнопку "Начать"

Протестировано на версии VLC 1.0.0

Как вещать один файл, а затем другой с помощью VLC?

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

Протестировано на версии VLC 1.0.3

Видео трансляция постоянно отключается, невозможно записывать и просматривать?

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

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

Разъем для подключения базовой станции, а также возможность вызова через сеть видео, изображений и музыки это одни из самых важных свойств приемников Smart TV .

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

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

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

Небольшой плеер EM7285 справляется даже с материалом в формате Full HD. С помощью кабельной сети Gigabit Ethernet или беспроводной сети WLAN, вызывает мультимедийные файлы, а затем воспроизводит их с помощью телевизора и / или группы Hi-Fi.

Воспроизведение медиа-контента через телевизор

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

Для этого следует подключить такой проигрыватель к телевизору и / или оборудованию Hi-Fi. Подключение к локальной сети вы можете реализовать с помощью кабеля для передачи данных или по беспроводной сети (WLAN).

Плееры для воспроизведения фильмов, фотографий и музыки оснащены разъемом HDMI, с помощью которого общаются с телевизором. Кроме видео в стандартном разрешении PAL принимают контент высокой четкости, включая материал в формате Full HD (1080p и 1080i).

Лучше оснащенные модели имеют встроенный жесткий диск и порт USB, к которому можно подключать внешние USB-накопители, чтобы записывать на них и считывать с них мультимедийное содержание. Внешние жесткие диски также могут выполнять роль клиента в трансляции потокового содержания . Стоит отметить, что даже такие устройства, как игровые консоли Sony PlayStation 3 и Microsoft Xbox 360 можно использовать в качестве сетевого приемника материалов, переданных для телевизора.

Большинство медиа-плееров предлагает возможность подключения оборудования Hi-Fi, чтобы воспроизводить музыку (или получения лучшего звучания во время сеансов кино). Тем не менее, в большинстве из них не предусмотрено дисплея, который будет способствовать выбору звуковых дорожек. Поэтому приходиться включать телевизор даже тогда, когда вы просто хотите послушать музыку.

Как осуществляется передача от компьютера к телевизору

Для пользователей, которые хотят регулярно воспроизводить с помощью телевизора контент, собранный в компьютере, удобное решение оказывается сетевой плеер, поддерживающий стандарт DLNA (Digital Living Network Alliance ), предлагаемый многими производителями.

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

Технология совместного использования мультимедиа в сети

Условием предоставления мультимедийного контента в сети – подключение устройств к той же локальной сети . Тип соединения (wi-fi (WLAN) или кабельный Ethernet) не играет никакой роли. Управление берет на себя протокол UPnP AV (Universal Plug-and-Play Audio Video ), который должен поддерживаться всеми устройствами.

Эта технология позволяет обнаруживать все устройства в сети и взаимодействовать им между собой. Устройство, поддерживающее протокол UPnP AV ищет в локальной сети сервер, который обеспечивают соответствующую службу обмена мультимедийным контентом. Затем отображает список найденных устройств.

Преимуществом протокола UPnP AV это факт, который не требует входа в систему на сервере, и не позволяет управлять правами доступа. Каждое устройство может поэтому без проблем обращаться к общим ресурсам.

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

Производительность сети

Во время передачи потокового видео высокой четкости очень много зависит от скорости передачи данных в локальной сети. В противном случае, при просмотре фильмов или музыки через телевизор, они могут «заикаться».

Однако, даже в кабельной сети с портами Fast Ethernet, который позволяет достигать производительности до 100 Мбит/с, вы можете плавно воспроизводить видео высокого разрешения в режиме 1080p.

Сети WLAN и PowerLine

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

Однако, при сохранении оптимальных условий вариант 802.11n в случае WLAN, и вариант HomePlug AV в случае сети PowerLine, достаточен для качественного воспроизведения фильмов в формате HD.

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

Мультимедийный сервер для домашней сети

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

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

Более экономичным решением оказывается например, маршрутизатор с интерфейсом USB или NAC.

Обмен фото и видео через DLNA

Желая предоставлять фильмы, фотографии и музыку в своей локальной сети Windows, не обойтись без программного обеспечения сервера, например, share-ware Tversity (www.tversity.com) или бесплатные VLC Media Player (www.videolan.org), Serviio (www.serviio.org) и PS3 Media Server (www.ps3mediaserver.org).

Tversity дает не только доступ к информации через UPnP и DLNA , но кроме того позволяет проецировать мультимедийные файлов с помощью веб-браузера. Преимущества этого инструмента, а также программы PS3 Media Server в функции преобразования файлов, сохраненных в экзотических форматах на широко используемые (это действие мы называем перекодировкой), чтобы они могли быть переданы на устройство, которые не поддерживают мало известный видео-кодеков. Кроме того, вы можете использовать в качестве альтернативы серверное по, предлагаемое некоторыми производителями телевизионных приемников, например, утилита PC Share компании Samsung.

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

Одной из причин является тот факт, что DLNA навязывает производителям только три формата – JPEG (фото), MP3 (музыка) и MPEG-2 (видео). Даже если телевизор поддерживает форматы, такие как DivX, MKV или H.264, это не означает, что вам удастся воспроизводить контент, сохраненный в этих форматах через интерфейс DLNA .

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

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

Android управляет устройствами

Android работает не только как операционная система для планшетных пк и смартфонов. Эта платформа все чаще находит применение также в современных медиа-плеерах. Ниже приведены некоторые из многочисленных примеров.

Медиа-плеер с поддержкой DVB-T2

Компания iconBIT (www.iconbit.com) имеет в предложении модель XDS1003D T2. Оснащенную хорошим программным обеспечением. Помимо популярных видео файлов, включая ISO, содержащими образы дисков Blu-ray даже поддерживает форматы 3D-фильмов. Воспроизведение осуществляется с помощью дополнительного жесткого диска, который можно установить внутри корпуса (должен быть в формате 3,5 дюйма) или из общих папок в локальной сети.

Плеер имеет не только разъемом Gigabit Ethernet, а также порт USB 3.0 для подключения внешних жестких дисков. Кроме того, имеются два разъема USB 2.0 и карт-ридер, поддерживающий форматы SD, SDHC и MC. Для передачи сигналов изображения и звука предусмотрены интерфейсы HDMI 1.4 (максимальное разрешение изображения составляет 1080p) и S/PDIF. Плеер поддерживает, в частности, стандарты Dolby Digital и DTS Surround.

Подключение к интернету позволяет использование (через телевизор) онлайн-услуг, таких как YouTube, Flickr и Picasa. Дополнением является встроенный DVB-T тюнер с функцией записи и отложенного просмотра (timeshift). Аппарат успешно зарекомендовал себя в качестве мультимедийного пкп TV.

Медиа-плеер

Аналогичной траектории следует Eminent (www.eminent-online.com), но отказывается от тюнера DVB-T. EM 7385 оснащен легко доступным снаружи отсеком для жесткого диска, в которой можно поставить жесткий диск SATA формата 3,5 дюйма. Кроме того, располагает мощным портом USB 3.0 и встроенным модулем WLAN, которая позволяет подключаться по беспроводной сети к другим устройствам в пределах домашней сети.

Чуть более скромная модель EM 7380 только воспроизводит мультимедийные файлы из общих папок в сети, внешних жестких дисков, USB-ключи и карты памяти SD.

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

Введение

Кажется, компании-производители потребительского сетевого оборудования решительно нацелены на продвижение своих 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) статистическим распределением. Вообще, неплохо было бы получить подобное динамическое изменение параметров потерь и, возможно, пропускной способности. Тогда мы смогли бы лучше эмулировать беспроводное соединение. Впрочем, посмотреть на эффект от потери кадров можно и в статическом режиме.


Рис. 3. Экран статистики соединения Link Statistics. Нажмите на картинку для увеличения.

Теперь можно подключать 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% для потокового режима, в результате увидели искажения (квадраты). Затем мы запустили серию тестов, результаты которых показаны в таблицах ниже. Просим прощения за субъективность в описании результатов, однако, лучшего способа охарактеризовать их мы не нашли.

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

Таблица 1. Результаты для потока VOB
Потери пакетов Результат
5% Невозможно смотреть
1% Невозможно смотреть
0,5% Смотреть можно, заметны квадраты
0,25%
0,1%
0,05%

Рис. 10. Поток VOB при потерях 5%. Нажмите на картинку для увеличения.
Таблица 2. Результаты для потока DivX
Потери пакетов Результат
5% Невозможно смотреть, видео и звук прерываются
1% Невозможно смотреть, постоянно проскакивают квадраты
0,5% Смотреть можно, но сложно, квадраты
0,25% Смотреть можно, часто проскакивают небольшие квадраты
0,1% Смотреть можно, квадраты проскакивают реже
0,05% Смотреть можно, квадраты проскакивают очень редко

Рис. 11. Поток DivX с 1% потерь. Нажмите на картинку для увеличения.
Таблица 3. Результаты для потока PSP / MPEG4
Потери пакетов Результат
5% Невозможно смотреть, плеер не работает
1% Невозможно смотреть, но плеер работает
0,5% Смотреть можно, но сложно
0,25% Смотреть можно, периодически проскакивают квадраты
0,1% Смотреть можно, иногда проскакивают квадраты
0,05% Смотреть можно, искажения появляются редко

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


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

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

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

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

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

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

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

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

Заключение

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