В ноябре 2019 года консорциум DVB Project принял две спецификации, регламентирующие компоненты новой технологии DVB-I. Она разрабатывается для стандартизации передачи видеоуслуг с применением IP-протокола и может использоваться как в открытом интернете, так и в операторских сетях.
Технология поддерживает передачу линейного ТВ, видео по запросу, а в качестве приемников могут быть любые устройства, подключенные к интернету и способные воспроизводить медиаконтент. Статья написана для раздела «ТВ-технологии».
ЗАЧЕМ НУЖЕН DVB-I?
Первый вопрос, который может возникнуть в связи с появлением новой технологии: какое место разработчики отводят ей на рынке? Во-первых, в индустрии утвердились два стандарта адаптивного медиастриминга — HLS и MPEG-DASH. Во-вторых, доставка видео через интернет во всех средах и на все мыслимые приемные устройства активно развивается и без участия DVB Project. А для координации работы вещательных и IP-сетей служит стандарт HbbTV, интегрированный в телевизоры всех ведущих производителей. Тем не менее в консорциуме увидели необходимость в еще одном стандарте, оптимизированном для вещателей.
Одна из основных задач нового стандарта — позволить вещателям уйти от системы приложений, которые им сейчас приходится использовать в интернет-среде для доставки услуг потребителям. Крупные медиаплатформы, такие как Netflix или YouTube, такая схема вполне устраивает. Они работают через свои приложения или сайты, поддерживая выбранный ими набор протоколов и реализуя собственную логику пользовательского интерфейса. Что же касается вещателей, то они привыкли использовать единые стандартизированные протоколы доставки и приемники, формирующие список вещательных услуг и обеспечивающие к ним доступ через единый пользовательский интерфейс. Сейчас же вещателям приходится поддерживать десятки приложений для разных приемных устройств. Более всего их напрягает обилие распространенных платформ смарт ТВ и их модификаций, для каждой из которых нужно либо создать новое приложение, либо протестировать имеющиеся. Кроме того, их программы теряются в магазинах среди сотен других. И наконец, у каждого приложения своя логика интерфейса, в которой пользователи не всегда могут разобраться. Поэтому одна из задач DVB-I — регламентировать требования к приемнику, который среди прочего позволит формировать единый список доступных услуг.
В плане возможностей медиастриминга DVB-I, в отличие от стандартов передачи по эфирным, кабельным и спутниковым каналам, не предлагает принципиально новых протоколов, а основывается на имеющихся разработках, оптимизируя их под требования вещателей.
Что касается отличия HbbTV от DVB-I, то первый стандарт ориентирован на предоставление гибридных услуг, в которых линейное ТВ передается по вещательному каналу, а нелинейные сервисы и интерактивные приложения — по IP-сети. HbbTV не используется в отрыве от вещательной сети, и в стандарте много внимания отводится синхронизации услуг, передаваемых по вещательному и IP-каналам.
КОММЕРЧЕСКИЕ ТРЕБОВАНИЯ К DVB-I
Разработка стандартов в рамках DVB всегда начинается с обобщения требований членов консорциума, заинтересованных в появлении стандарта. Перечислим основные требования к стандарту DVB-I:
- может использоваться как поверх интернета, так и в операторских сетях;
- должен работать в беспроводных сетях передачи данных, таких как Wi-Fi, 4G или 5G;
- в качестве приемников могут выступать любые устройства с подключением к интернету, при этом приемник может иметь или не иметь тюнер для приема из вещательной сети;
- услуги могут приниматься на стандартный встроенный тюнер DVB-I или на загружаемое приложение;
- время задержки линейных услуг и скорость переключения с канала на канал должны соответствовать этим параметрам в вещательных сетях;
- поддержка открытых и платных вещательных услуг со всеми присущими им функциями типа родительского контроля, электронного гида, субтитров, а также ассоциированных HbbTV-приложений;
- поддержка нелинейных услуг, таких как видео по запросу, отложенный просмотр, персонализированная реклама;
- списки услуг и электронный гид могут составляться отдельно для DVB-I либо включать также услуги, получаемые из вещательной сети;
- наличие механизма верификации источника услуги.
РАБОТА СО СПИСКОМ УСЛУГ
Это может показаться странным, но большинство вопросов в отношении реализации DVB-I связано c формированием списка услуг. В открытой вещательной сети приемник для поиска услуг сканирует частоты спутникового, эфирного или кабельного диапазона. А в операторские приемники обычно загружается частота, на которой можно получить актуальные параметры каналов с коммерческими услугами.
Аналогичная схема возможна для формирования списка операторских услуг, передаваемых по IP-сети, если вместо частот использовать URL. Но когда речь идет о получении услуг из открытого интернета, то сканировать десятки тысяч IP-адресов приемник заведомо не способен. Кто-то должен составить для него список услуг. Кроме того, услуги должны быть проверены на безопасность, на легальность в соответствии с законодательством региона, в котором находится приемник, а также на наличие возрастных меток.
Разработчики DVB-I предложили следующую процедуру. Сначала приемник запрашивает реестр услуг, который будет формироваться с учетом географического положения и интересов пользователя. Со своей стороны он должен верифицировать источник реестра и дополнительно убедиться, что предлагаемые услуги соответствуют требованиям местного законодательства. Вопрос о том, кто составит реестр и как услуги будут проверяться на легальность, разработчики стандарта оставляют открытым, так как он является организационно-правовым и зависит от конкретной схемы применения стандарта. Это может быть, например, мультисервисный оператор или местная администрация, к примеру, стремящаяся уровнять в условиях местные телеканалы, имеющие эфирные частоты, и те, которые доступны пользователям только через интернет.
Для составления списков услуг, электронного гида и обработки метаданных с некоторыми дополнениями используются механизмы, разработанные для вещательных и IPTV-сетей. Все перечисленное сведено в спецификацию Service Discovery and Programme Metadata for DVB-I, опубликованную в ноябре 2019 года.
В стандарт DVB-I включены также две транспортные технологии, которые могут применяться независимо от стандарта. Первая — DVB-DASH, изначально разработанная в качестве транспортного формата для HbbTV, вторая — Multicast ABR.
DVB-DASH ПРОТИВ MPEG-DASH
DVB-DASH представляет собой подмножество стандарта адаптивной передачи данных MPEG-DASH с некоторыми дополнениями. Первая версия MPEG-DASH была принята в 2012 году, но несколько лет стандарт практически не использовался из-за обилия включенных в него опций и наличия параметров, оставленных на усмотрение разработчикам. В результате в разные разработки включались разные наборы опций и решения были несовместимы между собой. Поэтому и появился DVB-DASH. В этом стандарте сокращено количество форматов описания медиапотока (Media Presentation Description, MPD). MPD содержат информацию о размере сегментов, об URL источника, служебные сообщения и характеристики медиа, такие как разрешение и скорость потока. Для некоторых параметров, включенных в MPD, сократили количество опций. Кроме того, стандарт дополнили списком допустимых для применения видео- и аудиокодеков. Для видео это AVC и HEVC, для аудио — AC-3, AC-4, модификации AAC, MPEG-H и ряд других форматов. Также регламентировали способы скремблирования потока и передачи субтитров. Последняя версия стандарта была принята в 2017 году, но летом 2019-го в нее добавили поддержку медиаконтейнера MPEG-CMAF с функционалом Low Latency Chunk (LLC). В системах адаптивного стриминга с поддержкой LLC медиапотоки разделяются на сегменты длительность 6—10 секунд, которые последовательно отправляются в сеть. При добавлении LLC эти сегменты перед оправкой дополнительно делятся на мелкие части (chunks) продолжительностью 200—1000 мс. В отличие от вещательной сети тракт, прокладываемый в интернете между источником и приемником сигнала, имеет множество звеньев, каждое из которых вносит свой вклад в задержку, которая напрямую зависит от размера передаваемой порции сигнала. Дополнительное дробление потока позволяет значительно сократить ее, сделав сопоставимой с задержкой в вещательной сети. Одновременно увеличивается и скорость переключения между каналами. И это как раз то, что требуется вещателям от стандарта DVB-I.
Более подробно возможности MPEG CMAF LLC описаны в материале «Ключевые причины реализации низкой задержки потокового видео».
MULTICAST ABR
Вторая технология, включенная в состав DVB-I, — Multicast ABR. Она была принята в марте этого года. Общепринятые форматы стримингового вещания построены на базе unicast (точка-точка). Эта схема заточена под доставку услуг по требованию и неплохо масштабируется за счет использования кэширующих серверов, устанавливаемых на границе сетей доставки контента (CDN). Однако для доставки линейных услуг она совершенно не оправдана. Поэтому в DVB Project посчитали нужным дополнить DVB-DASH LLC функционалом multicast (точка-многоточка).
Суть технологии заключается в добавлении в цепочку доставки multicast-сервера и multicast-шлюза. Сервер устанавливается на границе CDN и получает из этой сети контент по тем же протоколам, что и устройство воспроизведения (плеер). Multicast-шлюз устанавливается на абонентской стороне и может быть внешним или встроенным, например, в домашний медиашлюз. Он раздает полученный сигнал на домашние устройства в понятном им unicast-формате и в медиаконтейнерах CMAF. Multicast-сеть между сервером и шлюзом может работать по любой технологии, допускающей UDP/Multicast. Это может быть сеть Ethernet, HFC/DOCSIS, XDSL, PON или даже спутниковая. К открытому интернету технология пока не применима, потому что нет гарантии, что все маршрутизаторы на пути сигнала будут поддерживать multicast и понимать IGMP-запросы. Для решения этой проблемы компания Cisco разработала механизм туннелирования multicast-трафика. Кроме того, есть инструменты, повышающие надежность передачи multicast-трафика через открытый интернет, но пока они не включены в стандарт. В нынешнем виде технология применима только для операторских сетей.
Для реализации Multicast ABR рассматриваются два основных варианта. Первый — с HTTP-каналом, по которому multicast-шлюз может связываться с CDN и получать оттуда сегменты, потерянные в сети multicast, как это делает плеер. Второй вариант — однонаправленная сеть без HTTP-канала. Этот вариант наиболее вероятно может быть развернут на базе спутниковой сети, не предусматривающей наземного канала.
Таким образом, MPEG CMAF LLC в сочетании с Multicast ABR позволяют создать транспортную систему, сопоставимую с вещательными системами по показателю задержки сигнала и эффективности использования транспортной сети.
ОТЛАДКА И ПЛАНЫ
В настоящее время технология находится на этапе тестирования и отладки. Создаются образцы DASH-LLC-потоков и пакетов метаданных для формирования EPG и списка услуг. Эти образцы используются для отладки программных клиентов DVB-I, в задачи которых входит поиск и фильтрация услуг, формирование EPG и воспроизведение принятых потоков.
Кроме того, совместно с DASH-IF ведется адаптация открытых кодеков из библиотек FFmpeg для их применения совместно с DASH LLC. Задача заключается в том, чтобы адаптировать работу кодеров к передаче сигналов короткими порциями. Это сводится к ограничению размеров групп совместно кодируемых кадров, а также к исключению опоры на более поздние кадры для начала декодирования.
В ближайших планах разработчиков значится добавление персонализированной рекламы и упомянутых механизмов передачи multicast-трафика через открытый интернет. Из списка коммерческих требований пока остается неотработанной реализация DVB-I в беспроводных сетях передачи данных, включая 4G и 5G.
