Азбука AVoIP. Часть 1
В это трудно поверить, но уже почти четверть века прошло с тех пор, как АВ-индустрия (наряду с вещанием и теле- и кинопроизводством) начала задумываться о маршрутизации аудио-, видео- и управляющих сигналов через Интернет. На выставке NAB 1999 года в конференц-центре Лас-Вегаса даже была целая секция, посвященная "потоковым медиа".
Хотя эти "детские шаги" - вспомните "танцующие почтовые марки" - так и не воплотились во что-то практичное и полезное, они показали, куда движутся эти отрасли. Сегодня распределение аудиовизуальных сигналов по быстрым ИТ-сетям стало реальностью. Многочисленные усовершенствования видеокодеков, скорости широкополосного доступа и повсеместное распространение потокового видео в домашних условиях также способствовали этому переходу.
Словосочетание "AV-over-IP" стало повсеместным, но оно не совсем точно. Правильнее было бы сказать "AV-over-IT", поскольку "IP" означает протокол, а "IT" - тип сети. На самом деле, многие люди до сих пор не совсем понимают, как работает передача аудио- и видеосигнала по сети и почему нужно использовать именно такой способ распределения сигнала, а не более традиционный, например HDMI или HDBaseT.
Чтобы прояснить ситуацию, мы с гордостью представляем этот учебник по AVoIP. В первой части мы расскажем о том, как работает AVoIP, чем он отличается от традиционных методов распределения сигнала и что такое кодеки. Мы даже включили полезную порцию аббревиатур, чтобы помочь вам разобраться в терминологии. Читайте дальше!
Не совсем реальное время
Первое, что необходимо понять об ИТ-сетях, - это то, что по своей сути они не являются транспортными системами реального времени. Данные, передаваемые по ИТ-сетям, разбиваются на небольшие пакеты, которые могут проходить через множество серверов, прежде чем они прибудут в пункт назначения и будут вновь собраны в документы, электронные таблицы, фотографии и электронные письма.
Этого нельзя сказать о видео- и аудиопотоках, которые должны передаваться последовательными пакетами и прибывать в том же порядке, в котором они начались (и синхронизироваться). Эта нелинейность создавала всевозможные проблемы в тех грубых попытках потоковой передачи, которые мы наблюдали в конце 1990-х годов. Именно поэтому производители аудио- и видеооборудования избегали использования ИТ-транспорта, предпочитая использовать жесткие проводные соединения для передачи аудио- и видеосигналов.
Такие решения, как коммутаторы NETGEAR (на фото), помогают упростить передачу AV-over-IP.
Второе, что необходимо понять, - это то, что ИТ-сети представляют собой структуры с общей пропускной способностью. Пропускная способность сети фиксирована - например, 10 гигабит в секунду (Гбит/с) - и не может быть увеличена. Если в сети работает всего несколько пользователей, то это не проблема. Но если все больше и больше пользователей входят в систему и отправляют/передают большие файлы, они могут замедлить работу сети.
Представьте себе гостиницу с 200 номерами и одной системой горячего водоснабжения. Если несколько человек принимают душ, то горячей воды хватит на всех. Но если все 200 постояльцев одновременно пойдут в душ, горячая вода закончится очень быстро!
Как же мы можем рассчитывать на передачу видео- и аудиопакетов из точки А в точку Б и гарантировать, что они придут в целости и сохранности и будут синхронизированы? Для этого мы используем два инструмента: набор протоколов, привязанных к каждому пакету, и (в основном) метод сжатия и распаковки сигналов без потерь, позволяющий минимизировать их пропускную способность и ускорить прохождение по сети.
Протоколы Интернета
Интернет-трафик передается в виде пакетов (можно сказать, конвертов), имеющих заголовки, называемые протоколами, которые определяют тип пакетов и порядок их обработки. Наиболее широко используются два протокола: Transport Control Protocol (TCP) и Internet Protocol (IP). Все, что передается через Интернет, имеет эти два заголовка (TCP/IP).
Интернет-пакеты имеют единый размер в 1500 байт, основанный на стандартах IEEE. Они имеют адрес назначения, или IP-адрес, записанный в октетах (например, 192.168.1.1). Все эти элементы обеспечивают прохождение пакетов через сеть или сети и их прибытие (не всегда по порядку) к месту назначения. Если пакет был потерян, принимающий сервер может запросить его повторную отправку до тех пор, пока все пакеты не будут получены и исходный файл не будет собран заново.
Для большинства файлов, пересылаемых по ИТ-сетям, такая система работает достаточно хорошо, если не требуется прием в реальном времени. Но для работы с видео и аудио необходимо добавить еще несколько протоколов (инструкций на конвертах), которые определяют точный порядок следования пакетов и то, что с ними делать.
Общепринятым протоколом для мультимедиа является User Datagram Protocol (UDP). Можно добавить еще один протокол для более подробных инструкций на этих конвертах, например Real Time Messaging Protocol (RTMP) или Real Time Streaming Protocol (RTSP). Еще один протокол, Integrated Group Management Protocol (IGMP), используется для серверов, генерирующих индивидуальные видеопотоки для каждого зрителя, вошедшего в систему на этом сервере. Без этих протоколов наши видео- и аудиофайлы представляли бы собой бесполезное нагромождение кусочков паззла без инструкций по их сборке.
Выбор кодека
Откуда берутся все эти заголовки пакетов? Они генерируются в кодеке - программно-аппаратном комплексе, который анализирует видео и аудио и разбивает их на сжатые пакеты меньшего размера. Этот процесс чрезвычайно быстр и требует огромной вычислительной мощности и скорости (к счастью, и то, и другое стоит недорого и в изобилии).
Мы просто подключаем источник видеосигнала - например, через HDMI-разъем - и воспроизводим файл. Кодек захватывает видео и звук, выполняет массу математических вычислений, и на выходе получается поток пакетов. Звучит просто, правда? Конечно, это описание несколько упрощенное. Существует несколько доступных нам кодеков, но выбор правильного кодека зависит от вашего приложения и качества обслуживания (QoS), которое необходимо выбрать на начальном этапе.
Кодеки для видео можно разделить на две категории. Первый тип кодеков очень эффективен при передаче по сетям, но вносит латентность - задержку между моментом воспроизведения видеокадра и моментом его просмотра на принимающей стороне. Второй тип кодеков не так эффективно использует доступную полосу пропускания, но имеет очень низкую задержку.
Решение о QoS определяет, что важнее: эффективная транспортировка по сетям для экономии полосы пропускания или доставка высококачественного видео и аудио в режиме, близком к реальному времени, независимо от полосы пропускания. Во второй части мы обсудим оба типа кодеков, а также усовершенствования кодеков, потоковую передачу по Wi-Fi и многое другое.
Написать комментарий