IP-видео: от «битвы протоколов» к мирному сотрудничеству

Если прислушаться к беседам поставщиков контента, вещателей и консультантов на ежегодных отраслевых выставках — от IBC до NAB, можно увидеть, что в их словах все чаще и чаще появляется один термин — «IP-видео». Именно его можно назвать главным текущим трендом в ТВ-индустрии, который «набирает обороты» и не думает терять актуальности.

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

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

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

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

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

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

Вернемся обратно в студию и представим на секунду мультикамерную систему, построенную на базе IP-видео. На картинке ниже представлен пример рабочего процесса, превосходно функционирующего с использованием SDI, при этом все работает стабильно. Так почему же мы вообще задумываемся об IP-видео?

В конце концов, весь разговор сводится к стоимости и гибкости выбранной инфраструктуры. Построение вещательного комплекса на основе стандарта SDI подразумевает использование огромного количества телевизионного кабеля и многопортового SDI-маршрутизатора. Основной задачей такой структуры является доставка видеосигнала из одной точки вещательного центра в другую. В результате такая инфраструктура получается довольно дорогой, а каждая ее цепочка должна поддерживать все разновидности стандартов SDI, начиная с SD, 720, 1080 и заканчивая новыми стандартами, появляющимися год от года. Все это влечет за собой страх перед неминуемым прогрессом — сможем ли мы адаптировать свой комплекс под 4К? Сколько оборудования нам придется заменить?

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

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

Давайте изучим более детально возможности различных игроков мира IP-видео. Здесь, как и в любой другой новой технологии, существует целый ряд мнений по поводу того, как все должно работать. У нас есть два типа предложений: первые базируются на стандартах, воплотивших в себе лучшие наработки последних лет. А вторые — более прагматичные — основаны на том, что уже работает и имеет опыт практического применения.

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

Пока что наибольшего внимания заслужили два протокола IP-видео: SMPTE 2022-6 и ASPEN, каждый из которых работает на скоростях 10 GbE и более. Также существует и другой протокол — NDI (Network Device Interface), предложенный компанией NewTek, который успешно работает в гигабитных сетях Ethernet. Каждый из этих протоколов имеет свои сильные стороны и может применяться в различных практических ситуациях.
 

Протокол SMPTE 2022-6 по природе своей ближе к знакомому нам SDI. Принцип его работы заключается в упаковке несжатого потока SDI и передаче его по протоколу UDP через 10GbE сеть. Передаваемый контент и структура полей SDI-потока в данном случае остаются неизменными.

Для передачи сигнала SDI через UDP-протокол SMPTE 2022-6 использует существующий стандарт протокола реального времени RTP. В этом случае перед передачей SDI-потока в сеть он делится на множество мелких частей и снабжается дополнительными битами служебной информации. В конечном итоге сформированный поток получается гораздо сложнее оригинального SDI-сигнала. Преимущество этого решения заключается в возможности транспортировки потока через высокопроизводительную сетевую инфраструктуру.

Важно понимать, что SMPTE 2022-6 создает очень сложный поток данных, который необходимо упаковать на передающей стороне и распаковать на принимающей. Вы можете представить насколько это непростая задача, если учесть, что сам SDI-поток по природе своей представляет собой достаточно сложную структуру. Поток SDI — это не просто последовательность кадров, следующих друг за другом, это смесь видео, звука и метаданных, рассчитанная на работу с аппаратными приложениями в реальном времени. Для HD-видео скорость потока может достигать 1,5 Гбит/с, для новых стандартов ультравысокой четкости UHD — до 6 или 12 Гбит/с.

Некоторые производители, осознавая всю сложность протокола SMPTE 2022-6, пытаются найти более простой способ передачи видео- и аудиоконтента между устройствами без необходимости дробления потока на составляющие. Так был разработан протокол ASPEN. Этот стандарт во многом повторяет базовую архитектуру SMPTE 2022-6, используя UDP и RTP-пакетизацию потока и работая на скорости 10 Гбит/с.

Основным отличием ASPEN является отсутствие необходимости использования перемежающегося SDI-потока поверх RTP и UDP, поскольку большинству устройств, расположенных на разных концах сети, для работы достаточно иметь просто полные видеокадры. Вместо этого ASPEN использует транспортные потоки MPEG для инкапсуляции медиаданных, которые, в свою очередь, делятся на мелкие составляющие для последующей передачи по проводу. Стоит отметить, что в данном случае такое разбиение является менее интенсивным в сравнении с SMPTE 2022-6, но все так же требует достаточно высокой скорости обработки медиаданных.

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

А мечтали мы о том, чтобы процессор (CPU) одной системы легко и просто взаимодействовал с процессором другой системы в процессе передачи видео по сети. Но на практике из-за сложности и высокой скорости 10-гигабитных протоколов сделать это весьма затруднительно. Впрочем, одному из знакомых нам энтузиастов удалось с некоторым успехом обработать поток SMPTE 2022-6, используя самодельное ПО, установленное на настольном компьютере. Однако процессор ПК был настолько загружен, что никакие другие задачи выполнить было просто невозможно. Вывод из всего этого один — SMPTE 2022-6 должен работать на аппаратном уровне. Такой же вывод, вероятнее всего, можно сделать и в отношении ASPEN.

Ни для кого не секрет, что для того чтобы вместить несколько несжатых потоков в сеть с ограниченной пропускной способностью, необходимо эти потоки компрессировать, поскольку ни SMPTE 2022-6, ни ASPEN не могут передать даже одного HD-потока через гигабитную сеть.

Для этих целей стали рассматривать кодеки JPEG2000 и TICO, однако и здесь обнаружились некоторые трудности — расходы на лицензирование и компрессию. Патенты и лицензирование всегда были камнем преткновения для ряда стандартов, используемых в вещании и интернете. Яркие тому примеры — H.264 и MP3. И именно поэтому нам очень хотелось бы избежать всех этих неприятностей при использовании стандартов IP-видео в будущем.

На практике основная нагрузка в процессе компрессии ложится на процессор. Кодеки, вроде JPEG2000, H.264 и тем более H.265 чрезвычайно требовательны к вычислительным ресурсам процессора, но этот недостаток компенсируется снижением нагрузки на сеть в результате компрессии. Особенно заметно это становится, когда количество каналов увеличивается, и ваши системы обрабатывают несколько потоков IP-видео одновременно.

Два главных «10 гигабитных» стандарта представлены на сегодняшний день различными группами, такими как ASPEN, AIMS, VSF, AMWA и рядом других, у каждой из которых есть свои особенности и разновидности. Большинство производителей оборудования примкнули к той или иной группе и спешно занимаются разработкой новых продуктов IP-видео для телевизионного рынка. Зачастую такие продукты представляют собой простые преобразователи из SDI в IP-видео и обратно, в основе которых лежит их собственное аппаратное обеспечение, работающее с базовой полосой SDI-сигнала.

Наряду с аппаратными средствами существует более простое решение, в котором видеокадры просто доставляются от одного устройства к другому. Это технология Network Device Interface (NDI). Она была разработана с учетом ряда необходимых условий и предлагает практическое решение для передачи IP-видео через существующую 1GbE сетевую инфраструктуру или даже по WiFi без использования специального оборудования.

NDI является нелицензируемой технологией с легко реализуемым API. Инструменты, основанные на базе NDI, уже были продемонстрированы на различных платформах. Она может быть легко встроена в программное обеспечение, не требующее больших вычислительных ресурсов, более того — уже доступна в приложениях для iPhone и iPad, что в принципе недостижимо при использовании SMPTE 2022-6 или ASPEN.

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

В процессе передачи HD-видео через гигабитную сеть важную роль играет компрессия, реализуемая в NDI посредством высококачественного вейвлет-кодека, обеспечивающего битрейт выходного потока в диапазоне от 50 до 100 Мбит/с. В отличие от H.264 кодек NDI не требует затрат на лицензирование и характеризуется очень низкой временной задержкой сигнала.

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

 

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

1) Hardware to Hardware (например, камера к маршрутизатору или маршрутизатор к монитору, доставка SDI-сигнала по оптическому волокну);
2) Hardware to Software (например, камера к соответствующему ПО);
3) Software to Hardware (например, ПО воспроизведения к маршрутизатору);
4) Software to Software (все то, что взаимодействует с программным видеомикшером).

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