Илья Доронин: Компания Diantis System House была создана в 2002 году для представления интересов телеканалов «Первый канал — Всемирная сеть» и «РТР-Планета» в Канаде и для организации вещания ТВ-каналов на русском языке в Канаде. В 2004 году мы успешно построили телекомпанию в Торонто, которая начала вещание русских и украинских каналов, а сейчас осуществляет вещание практически на всех языках, включая английский и французский. Первоначально мы также были нацелены на поставки вещательного оборудования и решений канадских фирм на рынок Восточной Европы, СНГ, Средней Азии, и содействовали выводу на этот рынок таких производителей как Leitch, Miranda, RossVideo и Evertz.

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

В общем, кодирующее устройство пришлось вернуть — а это 60 стадионов в Канаде и США, то есть провал оказался достаточно серьезный. Нашей задачей было подобрать кодирующее устройство по техническим параметрам и по тем протоколам, которые поддерживал партнер этой лиге – компания Verizon Digital Media Services, сейчас эта платформа называется Yahoo Edgecast. В результате этого проекта нам удалось найти очень интересные решения и модели.

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

Во-первых, это входы HDSDI и HDMI. Должно было поддерживаться больше двух каналов звука, потому что на данный момент трансляции ведутся в монорежиме, то есть один канал ведут комментаторы одной команды, второй – комментаторы другой, или два языка: английский и французский.

Планировалось поддерживать компрессию H.264 и H.265. Применялись протоколы стриминга RTRP и RTP, которые уже использовались, с возможностью перехода на SRT, к которому Verizon Digital Media была еще не готова в тот момент.

Главным требованием лиги стало то, чтобы кодирующие устройства стоили не более $2 500.00 за каждое. Из-за этого на рассмотрение не попало очень много компаний, которые не проходили по цене.

Мне удалось найти на рынке всего четыре устройства с многоканальным звуком.

Первое — это кодирующее устройство EdgeCaster американской компании VideonLabs.

Два устройства XPSEDGE и ScorpionSLKE от Evertz тестировались, но не прошли. Там очень сложный интерфейс, и операторам на стадионах было бы тяжело с ним разобраться, это — вещательный уровень. Также они не поддерживали часть нужных нам протоколов. Да и по цене они были выше бюджета.

Еще одно устройство — это Caton Live Mini от сингапурской компании Caton Technology. Но, к сожалению, нам не удалось его протестировать, мы просто не успели по времени.

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

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

Первая модель – это XVVVDO2IP монреальской фирмы Theatrixx. Это очень мощное кодирующее устройство с точки зрения механического дизайна. Оно защищено со всех сторон резиновыми окантовками и имеет магнит на обеих сторонах. Также здесь используется разъем питания Neutrik, который защелкивается, то есть кабель питания невозможно вырвать. Это было бы очень интересное решение, если бы возникла необходимость поместить устройство на штатив видеокамеры или использовать его на переносном устройстве.

Вторая модель – кодирующее устройство NV-34 фирмы DataVideo, которое позволяет передавать от одного до четырех потоков.

Третья модель – Pearl Nano от фирмы Epiphan Video. Это устройство при достаточно низкой цене имеет проходные входы HDMI, выход HDMI для монитора, профессиональные XLR и бытовые RCA входные разъемы для аналогового звука, то есть то, что для стадионов очень важно.

Последняя модель – Monarch HDX от Matrix Video. Это решение не прошло по протоколам и оказалось не очень интересным из-за высокой цены.

Благодаря круглым столам ТКТ я также познакомился с фирмой Elecard, которая имеет очень интересное программное обеспечение для объективного сравнения кодирующих устройств. В результате работы с ним оказалось, что NV-34от Data Video при цене в два раза меньше, чем Epiphan Pearl Nano, обладает более высоким качеством. Возможно, в дальнейшем мы будем его рассматривать как запасное кодирующее устройство, потому что пока никакого резервирования нет, а используется только один кодер для стриминга EdgeCaster.

Для контроля трансляции в ОТТ у Elecard также есть решение BORO, которое позволяет отслеживать сразу все потоки, когда идет одновременно 20 матчей по стране.

Мы рассматривали кодирующие устройства от Caton Technology, которые попали в четверку многоканального звука. Эта фирма также предлагает очень интересное решение Caton Publisher, благодаря которому можно превратить iPhone в устройство ТЖК. Это бесплатная программа, она есть в AppStore. Ее можно поставить и передавать репортажи сразу с места событий. Можно с телефона передавать видео на AppleTV, а с него брать HDMI-сигнал и выдавать в эфир. Даже если на стадионе нет никакой камеры, все равно можно вести прямые трансляции с телефона. Здесь есть функция «картинка в картинке», когда используется одна из трех задних камер на смартфоне, которые можно выбрать, и передняя камера.

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

Компания Caton Technology использует протокол F2TP, который может восстанавливать до 50% потерянных пакетов.

После того, как спортивные мероприятия прошли, нужно записать игру и сохранить ее где-то. Мы начали искать подходящий облачный архив. Так как мы работаем с Amazon Web Services, то это был наш первый выбор. Однако на одном из вебинаров я увидел ArkHub – это интересное совместное решение HP, Caton Technology и Mediahub Australia.

У этого облачного архива гораздо больше функций и прозрачные цены. Многие вещи включены бесплатно, тогда как у Amazon я столкнулся с тем, что кодирующими устройствами нужно было управлять с файлов XML. Amazon предоставляет 5 Гб бесплатно, но после 20000 раз, когда каждое кодирующее устройство загрузило этот файл, включается счетчик. На сайте ArkHub есть калькулятор, куда можно ввести свои параметры и посмотреть стоимость.

Тимур Кулгарин, технический директор «СТС Медиа»: Выбранные вами устройства передают потоки в протоколах RTMP, RTP или уже в SRT?

Илья Доронин: практически все устройства, которые мы выбирали, поддерживают почти все протоколы, вплоть до Facebook Live, YouTube и так далее, и могут в принципе оставить компанию Yahoo и Verizon не у дел. Что делает Verizon? В данный момент они принимают поток RTMP и транскодируют его в HLS и MPEG-DASH, чтобы доставлять конечным пользователям. Выбранное нами устройство может посылать сразу три потока RTMP и SRT, и HLS, и MPEG-DASH. В принципе, мы можем обойти компанию Verizon и напрямую посылать сигналы к той платформе, которая доставляет их до подписчиков. К сожалению, с компанией Verizon контракт продлится еще три года, так что пока мы можем об этом только мечтать.

Сообщение Илья Доронин: Онлайн-вещание спортивных матчей, мониторинг и измерения параметров потоков появились сначала на TKT 1957 | Техника Кино и Телевидения.

Тимур Кулгарин, технический директор «СТС Медиа»: Сегодняшнее мероприятие посвящено системам компрессии видеосигналов. Эта тема очень интересная. Мир меняется, и от традиционного телевидения, использующего на данный момент стандартную компрессию 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 ГГц.

Сообщение Николай Милованов: Адаптивные решения компрессии видеосигналов для ОТТ-сервисов появились сначала на TKT 1957 | Техника Кино и Телевидения.