Передача потокового видео в сетях: руководство THG. Часть I – THG.RU

Введение

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

Рис. 2. Экран эмуляции соединения Link Emulation. Нажмите на картинку для увеличения.

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

Рис. 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 в разрешении 640×300 при 24 кадрах в секунду;
• PSP avc1 (MPEG 4), разрешение 368×208 при 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% для потокового режима, в результате увидели искажения (квадраты). Затем мы запустили серию тестов, результаты которых показаны в таблицах ниже. Просим прощения за субъективность в описании результатов, однако, лучшего способа охарактеризовать их мы не нашли.

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

Рис. 10. Поток VOB при потерях 5%. Нажмите на картинку для увеличения.

Рис. 11. Поток DivX с 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, то создать помехи во время просмотра гораздо сложнее. Во второй части нашей статьи мы посмотрим, как работает потоковое видео в беспроводных сетях. И что нужно сделать, чтобы оно работало хорошо.

Обсудить статью в форуме THG.ru