Николай Милованов, директор «Элекард», выступил с докладом «Адаптивные решения компрессии видеосигналов для ОТТ-сервисов» на Online круглом столе «Broadcasting 2021. Системы компрессии видеосигналов» 13 июля 2021 года.

Тимур Кулгарин, технический директор «СТС Медиа»: Сегодняшнее мероприятие посвящено системам компрессии видеосигналов. Эта тема очень интересная. Мир меняется, и от традиционного телевидения, использующего на данный момент стандартную компрессию DVDT2, мы переходим в ситуацию с многообразными способами доставки нашего контента. Соответственно, системы компрессии все важнее и важнее для телевизионных компаний.

Наш первый участник – директор компании Elecard Николай Милованов – расскажет нам про адаптивные решения компрессии видеосигналов для ОТТ-сервисов.

Николай Милованов: Я являюсь директором компании Elecard, имею громадный опыт разработки, развития, продаж систем видеокодирования. Elecard на данный момент владеет тремя основными офисами. Первый офис находится в Томске, там расположена вся разработка, поддержка, большая часть продажи. Второй офис продаж – в США. И, наконец, калининградский офис также занимается продажами, поддержкой и R&D. Мы находимся на рынке уже 32 года, то есть с 1988 года мы занимаемся именно видеокомпрессией. Большую часть своего времени мы разрабатывали видеокодеры – энкодеры и декодеры – софтовые компоненты, которые затем лицензировали по всему миру. За это длительное время у нас накопилось порядка 10 000 клиентов, которые находятся в 150 странах. Продажи самые разнообразные, например, на рубеже веков мы продавали видеоплеер MPEG-2, очень удобный, очень быстрый и крайне популярный у наших клиентов.

Теперь о продукте, на котором построены наши системы компрессии. Этот продукт называется CodecWorks. Это профессиональный транскодер, который поддерживает все известные MPEG-видеостандарты, начиная от MPEG-2 и заканчивая HEVC/H.265. Также поддерживаются различные системы адаптивного вещания HLS и MPEG-DASH, возможно кодирование 4К, вывод контента с устройств SDI и ASI. На вход мы берем все, что угодно, потому что наше решение софтовое. Мы ставимся под сервера, которые подбираем непосредственно под задачу.

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

Но на самом деле, когда мы стали внедрять решения ОТТ-станций, нам пришлось столкнуться с тем, что нужно адаптировать не только битрейт, но нужно решение под условия непосредственно клиентов, будь то оператор, телеканал или CDN-сеть.

Мы для себя увидели несколько пунктов адаптивности, под которые нам приходится подстраиваться.

Первый пункт адаптивности – это исходные телевизионные потоки и их возможность резервирования. Телевизионные потоки, поступающие на головную станцию, могут быть разнообразными. Это не всегда UDP или SDI, это может быть RTMP, HLS или какое-то файловое хранилище. Поэтому необходимо подделывать свое решение, чтобы оно работало. При использовании резервного источника важно, чтобы сравнение качества этих источников осуществлялось по определенным правилам: либо считать ошибки, либо пропадание IP, либо полностью пропадание сигнала. В зависимости от того, что вы установите, вы должны переключаться между основным и резервным потоком. Также используется пользовательская заставка. Бывают моменты, когда все резервы «отваливаются». Тогда, чтобы контент не прервался, нужно «подложить» какой-то blackout.

Следующий пункт адаптивности – мониторинг качества исходных потоков. Исходные потоки приходят разного качества и очень разные по наполнению и содержанию. Тут важно соблюсти, чтобы мониторинг стал независимой точкой. Мониторинг должен происходить 24/7 на всех каналах, которые к вам поступают. Если к вам поступают 100 каналов, значит, 100 каналов нужно просматривать, потому что какой-то из этих каналов может идти от другого контентообладателя. Если вы вовремя не отследите качество, то могут возникнуть проблемы именно с компрессией.

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

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

Резервирование систем доставки – это так называемый CDN. Тут тоже несколько вопросов: каким путем мы уйдем на CDN, сколько у нас этих CDN, как внутри них распределяется контент. Это накладывает адаптивный отпечаток на всю систему. Используются различные технологии выборки CDN. Существует несколько технологий, например, WebDAV, HTTP, FTP. Иногда вам приходится на одной и той же головной станции использовать все эти пути. Для чего это нужно и как это помогает делать систему устойчивой? Некоторые устройства работают с определенной системой криптования, с определенной системой ОТТ-пакетирования. Чем адаптивнее вы подходите к этой системе, тем более выигрышной будет вся ваша платформа.

Следующий пункт – использование различных версий и технологий пакетирования. Когда вы начинаете строить систему, и ОТТ-вещание работает у вас не только на определенной приставке, но, допустим, на все телевизоры, чтобы закрыть как можно больше устройств, вам приходится использовать различные системы пакетирования, например, DASH и HLS. Но у HLS также существуют разные версии.

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

Далее мониторинг системы компрессии. Сама система компрессии должна о себе постоянно «говорить», и быть управляемой извне не только вебными вещами, но и с помощью неких скриптов либо с помощью API сторонними вещами. Мониторинг возможен двумя основными путями, которые мы знаем: это SNMP и REST API. SNMP используется у операторов и телеканалов, как правило, де-факто. То есть существуют зонтичные системы, которые собирают информацию со всех устройств, свитчей и прочее, и вы как система компрессии тоже должны выдавать всю эту информацию. REST API, как правило, нужен для того, чтобы вы смогли не только получать информацию, но и управлять этим процессом.

Последняя адаптированная подзадача – выбор аппаратного обеспечения. Адаптация аппаратного обеспечения проводится в зависимости от задачи. Существует, допустим, кодирование четырех каналов. Для этого достаточно одного юнитного сервера. Когда речь заходит о кодировании 400 каналов, то тут уже приходится выходить на решения, которые вы будете впихивать в большие сервера. Они должны быть взаимозаменяемые. То есть тут происходит такой же выбор, как выбор «железа».

Тимур Кулгарин: В портфолио ваших решений, кроме кодирования, есть ли системы DRM, мониторинга сигналов, или это все подразумевает сторонние системы и интеграцию с ними?

Николай Милованов: По мониторингу сигналов у нас есть замечательное решение Boro. Оно софтовое, ставится на любые сервера, подстраивается под заказчика и мониторит 24/7 до 400 каналов. Что касается, DRM, то это такая вещь, которая должна иметь некоторую лицензию. Допустим, у платформы «Триколор» есть свой некий DRM, который они могут продавать, и они делают какие-то усилия, чтоб поддерживать его. Мы же просто используем уже существующие связи наших клиентов.

Тимур Кулгарин: Вы упоминали, что поддерживаются интерфейсы SDI на входе, это могут быть FTP-потоки и что-то еще. А такие форматы как SDI over IP, который SMPTE 2022 или 2110, поддерживаются? Может быть, это есть в планах?

Николай Милованов: На данный момент именно эти протоколы не поддерживаются. Мы поддерживаем NDI и ему подобные, но в сторону 2110 мы пока что не шли, потому что это больше рынок тех, кто делает контент. Мы туда смотрим, пока активно не заходим, но где-то в роадмапах это есть. На данный момент этот рынок для нас узок. У нас рынок больших операторов, а здесь ради трех каналов все это делать нам пока сложно. В свое время мы сильно бежали впереди планеты всей, делали все, что только появляется, и лицензировали это по всему миру. На данный момент мы смотрим, кто и что у нас покупает, и либо это внедряем, либо ждем, когда оно подойдет. Например, то же SRT появилось года три назад, но по запросам практически никак не шло, а полтора года назад пошли запросы из Европы, из России. То же самое и с 2110 – мы ждем, когда запрос на него накопится.

Тимур Кулгарин: SRT и RIST уже поддерживаются?

Николай Милованов: Да, поддерживаются. Уже есть реализованные проекты. Как правило, тут всегда идет борьба: внедрять SRT или RIST.

Тимур Кулгарин: Метки SCTE поддерживаются?

Николай Милованов: Да. Есть несколько возможностей прокидывания этих меток. Можно записать плейлисты HLS либо оставить их в TS, если вы остаетесь в транспорт-стриме и выходите в MP4. Вопрос касается субтитров: там есть несколько путей закидывания DASH, HLS, внутри даже есть несколько подстандартов. Мы стараемся практически все из них поддержать. Это происходит потому, что устройства очень разнообразные, где-то нам приходиться телетекст вкладывать в HLS одним способом и тут же иметь вложенные другим способом, чтобы на всех устройствах это можно было увидеть.

Тимур Кулгарин: Есть какая-нибудь централизованная система управления, когда нужно кодировать несколько десятков или сотен каналов, какой-то оркестратор?

Николай Милованов: Да. Это наш менеджер, который управляет серверами. В серверах есть задачи, которые это все распределяют, и можно настроить пул основных серверов и пул резервных серверов. Резервные сервера смотрят за пулом основного, и в случае выхода из строя кого-то из них они тут же все подхватывают, все настройки переливаются с одного места на другое, и получается управление из одного места. На данный момент у нас есть проект, где 25 серверов, это порядка 400 каналов.

Тимур Кулгарин: Видимо, вы никак не привязаны к конкретному оборудованию, работаете на любом «железе».

Николай Милованов: Да.

Тимур Кулгарин: На каких операционных системах это все работает?

Николай Милованов: Сейчас у нас большая часть проектов на Windows, развивается работа на CentOS. К Windows бывает привязка, потому что там есть карты SDI и ASI. Но мир меняется, и уже есть проекты, где мы работаем с картами под CentOS.

Надир Хамзин, коммерческий директор ООО «ПлатформКрафт» (Россия): Вы говорили о резервировании CDN-сети. У вас есть какой-то балансер? Если да, то какие параметры он учитывает?

Николай Милованов: Это самый простой балансер, которому вы задаете несколько выходов CDN, и если у вас основной отвалился, то вы перейдете на второй. Здесь нет выбора, где лучше, где хуже. Как только у вас пошла неудача и за какое-то время вы не выложили данные, то тут же нужно переходить на следующий.

Илья Доронин, Diantis System House, Канада: Я сейчас работаю с несколькими спортивными лигами. Когда идет выбор протоколов, они очень часто диктуются сетями CDN, и заказчик не всегда может выбрать, какое кодирующее устройство использовать. На ваш взгляд, какой стриминговый протокол наиболее перспективный и его стоит учитывать, чтобы брать кодирующее устройство заранее с этим протоколом?

Николай Милованов: У всех протоколов есть свои плюсы и минусы. Если сравнивать SRT и RIST, то они примерно одинаковые, это так называемый RTSP, который мы знали еще на рубеже веков, это FTP с контролом, который позволяет делать предзапросы. Что-то рекомендовать сложно, все зависит от вашей сети и от оборудования. Мы, как правило, берем SRT, RIST и начинаем их тестировать прямо в той области, где находится наш клиент. В какой-то части пойдет SRT, где-то RIST, в какой-то вообще HLS, а иногда достаточно будет UDP, он «пролезет», и клиент никогда не будет знать, что какие-то сложности существуют. Для меня как техника было бы проще работать с HLS либо с любой ОТТ, у которой минимальная нарезка. Но опять же вам важно, чтобы была минимизированная задержка.

Илья Доронин: Переформулирую вопрос. По вашему опыту, какой наиболее распространенный протокол и какой наиболее перспективный?

Тимур Кулгарин: Я по своему опыту могу сказать, что пока придется покупать те протоколы, которые поддерживает ваш провайдер CDN, но с прицелом, чтобы эти устройства поддерживали SRT и RIST, которые наверняка будут дальше применяться, развиваться и которые хорошо подходят для целей контрибуции, то есть сбора сигнала со стадионов через публичный интернет. Что вы думаете, Николай?

Николай Милованов: На самом деле здесь нельзя положиться на какой-то опыт. Некоторые CDN-провайдеры идут строго по определенному протоколу, другие начинают гибко подходить к этому. Из развивающихся протоколов, которые сейчас хорошо идут – это RIST, SRT. Если есть возможность не смотреть на задержку, то это HLS. HLS и DASH – это протоколы, которые постоянно развиваются, у них постоянно новые ревизии. Если бы я был CDN-щиком, я бы положился на протоколы ОТТ, потому что они очень хорошо кладутся именно в CDN, для CDN это просто набор файлов, которые ты перекидываешь. RIST, SRT – это уже посложнее, тут идут запросы и все чуть-чуть нестандартно.

Тимур Кулгарин: Есть еще вопрос от Андрея Мамонтова. Для вашей системы мониторинга нужно ли иметь клиента на разных территориях, где стоят энкодеры? Каким образом собирается информация по мониторингу контента?

Николай Милованов: У нас бывают такие решения, что есть головная станция, у нее есть вход, и есть выход у контентообладателя. То есть мы ставим в какую-то удаленную точку контентообладателя, смотрим, как у него контент выходит и как сюда приходит. Таким образом мы исключаем точку передачи. Поставить систему мониторинга можно куда угодно, она ставится как на виртуальные машины, так и на любые другие. Эта система много от себя не требует, на 50 каналов можно поставить на обычный процессор с четырьмя ядрами 2 ГГц.

Advertisement