Доклад Алексея Пискунова, инженера технической поддержки Ateme в EMEA North, «Cистемы компрессии и пакетирования видеопотоков для кабельных, спутниковых и ОТТ-операторов» на Online круглом столе «Broadcasting 2021. Системы компрессии видеосигналов» 13 июля 2021 года.
Тимур Кулгарин, технический директор «СТС Медиа»: Передаю слово Алексею Пискунову из компании Ateme, которая занимается компрессией и всеми смежными вопросами.
Алексей Пискунов: Я являюсь инженером технической поддержки Ateme. Сегодня я расскажу, что мы предлагаем в качестве систем компрессии и пакетирования видеопотоков для кабельных, спутниковых и ОТТ-операторов. Вначале скажу пару слов о нас. Мы помогаем контент-провайдерам, сервис-провайдерам по всему миру увеличивать размер своей аудитории за счет повышения качества предлагаемых услуг, а также постоянно разрабатываем новые сервисы, модели и способы их монетизации. Ateme является публичной компанией, ее акции торгуются с 2014 года на бирже Euronext. Она генерит порядка 70 миллионов евро ежегодно и обеспечивает около полутора миллионов евро регулярного месячного дохода с тенденцией на увеличение, что является очень хорошей защитой инвестиций для потенциальных инвесторов. В Ateme работает около 450 человек с офисами в разных странах, в том числе и в России. Надо сказать, что в России за последние несколько месяцев Ateme вырос на 300%. Сегодня нас здесь 3 человека, и еще к нам присоединился четвертый член команды, который базируется в Казахстане и будет развивать бизнес там. Мы имеем более тысячи клиентов по всему земному шару, владеем многочисленными патентами и регулярно завоевываем профессиональные награды.
В Ateme существует отдельный департамент инноваций, который занимается активной деятельностью в сфере исследования, стандартизации, участия в разнообразных организациях с целью разработки новейших стандартов и решений для наших клиентов. Так, например, Ateme является активным участником разработки таких стандартов как VVC или AV-1, а также членом консорциумов и организаций, которые работают над стандартами ATSC 3.0, членом DVB, DASH, CMAF, 5G и других.
Возвращаясь к теме самого доклада, я хотел бы вкратце рассказать про решения компрессии и пакетирования, которые предлагает наша компания. Хорошо представляя структуру современной гибридной головной станции, мы понимаем, что сначала там необходимо принять большое количество сигналов, эффективно их сжать и обработать, получив на выходе необходимые нам стандарты. Для этого у нас существует решение TITAN Live. TITAN Live – это реалтайм-решение для кодирования и транскодирования, применяемое для построения конвергентных головных станций кабельными наземными, спутниковыми и ОТТ-операторами. TITAN Live является 100% программным решением, работает на всех стандартных COTS-серверах. Он может работать как Appliance-решение или решение в облаке.
TITAN Live поддерживает любые стандартные серверные платформы, например, Intel, Dell, HP и другие. В самом продукте TITAN Live практически отсутствует амортизация, так как он является регулярно обновляемым программным обеспечением. Инсталляция TITAN Live не занимает много времени. В зависимости от конфигурации он наделен следующими функциями: может быть приемником, декодером, процессором, кодером, транскодером, пакетайзером и может обеспечивать интеграцию и связь со всеми широко используемыми популярными DRM-системами. Мы поставляем сюда TITAN Live по Capex или Opex-моделям, но могут быть использованы и другие модели. TITAN Live уже работает в общественных облаках, таких как Amazon, Google Cloud и Microsoft Azure. Уникальная модель лицензирования TITAN Live фактически предлагает нашим клиентам пакет «все включено». По факту за один использованный канал становится доступным весь функционал. Возможен прием сигналов SDI, некопрессированного и компрессированного IP с разрешениями до UHD разных форматов и разных кодеков, таких как MPEG-2, H264, HEVC. Поддержка многоканального звука и кодеков Dolby, широкий спектр процессинга и процессинга мета-данных, таких как субтитры, метки и других, дает возможность использования TITAN Live на всей цепочке распространения контента по многофункциональным операторам и контент-провайдерам.
Интерфейс TITAN Live является довольно простым, интуитивным. По факту он имеет четыре раздела: в INPUTS мы конфигурируем входы, в TRACKS мы раскладываем их на составляющие, обрабатываем и кодируем, мультиплексируем в MUXERS, и в OUTPUT выдаем уже систему мультиплексирования, модуляции или распространения.
Если оператор представляет ОТТ-сервисы, ему необходимо решение для пакетирования и доставки контента по интернету. В нашем продуктовом портфеле эти решения называются NEA: NEALive, NEADVR и NEACDN. NEA совмещает в себе функции Packager и Origin. Packager необходим для преобразования контента из одного формата в другой, например, из транспорт-стрим в HLS, DASH, MSS, чтобы контент был доступен в разных устройствах. Origin является отправной точкой для публикации контента, который создается для различных сервисов.
NEALive и NEADVR, по сути, являющиеся одним и тем же продуктом, позволяют операторам ОТТ запускать такие сервисы как Live, Timeshift, Catch-Up, ClaudDVR и VOD. Являясь just-in-time пакетджером, данное решение позволяет иметь до 300 каналов распространения Live, оперирует с очень большим Infinite-буфером, позволяет строить высокопроизводительные кластеры с объемом хранилища до четырех петабайт, в которых могут храниться и обрабатываться миллионы видеоресурсов.
Представьте, что вы хотите распространить свой контент на максимальное количество доступных устройств, будь то сайт или мобильное устройство, но также вы думаете об экономии средств и эффективности своей инфраструктуры. Justintime Packaging в NEA позволяет создавать необходимые форматы по запросу сразу, тем самым существенно экономя затраты на хранение данных. Пакеджер NEA поддерживает большинство популярных стандартов, таких как HLS, DASH, MSS, работает с невидимыми и видимыми субтитрами, поддерживает многоязыковое аудио и динамическую вставку персонализированной рекламы.
Я уже упомянул про Infinite – невидимый буфер. Что такое буфер и зачем он вообще нужен? Буфер и его глубина позволяют ОТТ-провайдеру предоставлять такие сервисы как DVR. Infinite-буфер в NEA способен обеспечить очень большую глубину записи без перерывов в ней, сохраняя только то, что записывает клиент, индексируя и храня эти ресурсы в базе данных, таким образом для многопользовательских систем используя технологию Sharedcopy, которая оптимизирует объем системы хранения данных и траффик для CDN.
Архитектура решений NEA базируется на кластере. В любой момент времени кластер NEA может быть масштабирован исходя из увеличения количества каналов или увеличения объема системы хранения данных или полосы пропускания для стриминга. NOD и их роли могут быть распределены для резервирования или, наоборот, объединены для компактных систем. Все NOD кластера NEA используют общую систему хранения данных EDS. EDS – это очень интересная технология, которая позволяет каждой NODделегировать свой внутренний storage в качестве общей системы хранения данных. Таким образом, кластер NEA создает и использует общий storage, составленный из кусочков внутренних систем хранения данных каждого сервера. Это дает возможность отказаться, например, от использования внешних NAS-систем, обеспечить производительность для стриминга в несколько раз выше и получить более высокую плотность при размещении оборудования в стойках. Один NEA-кластер способен обеспечить объем хранения данных до 4 ПБ, а также выдать суммарно потоковую производительность 50 Гб/с.
Что касается эко-системы ОТТ в целом здесь надо отметить следующее: NEA имеет открытый API для интеграции, с NEA уже проинтегрированы многочисленные DRM-системы и системы SDP, есть совместимость с многочисленными плеерами. Если интеграции не существует, то мы обязуемся ее разработать менее чем через четыре недели благодаря сервисной платформе NEAProxy. Таким образом, решения NEALive или NEADVR могут использоваться ОТТ-провайдерами или операторами для предоставления дополнительных сервисов своим абонентам, таких как VOD, CUTV, cDVR, динамическая вставка рекламы, что в свою очередь является способами их монетизации и извлечения дополнительной прибыли.
Надо сказать, что с точки зрения программных платформ, которые используются, все продукты мы уже практически перевели на контейнерную архитектуру, и это очень важно. Мы все знаем, что такое BareMetal-инсталляция, когда есть операционная система на сервере, и на нее устанавливаются разные приложения. Мы также знаем, что такое виртуальные машины, которые работают от своей операционной системы «Гипервизор», и каждый имеет свою гостевую операционную систему и свои приложения. Но контейнеры – это немного другой метод виртуализации и использования ресурсов. Они работают под единой операционной системой, которая имеет специальную среду Container Runtime. Мы используем контейнеры Docker. Зачем мы перешли на такую технологию? Каждую функцию или процедуру можно заложить в свой контейнер, и уже доступные многочисленные контейнеры под разные задачи все равно, где запускать, где с ними работать: на своем ноутбуке или в облаке. Операционная система для контейнеров – Linux, мы используем ее во всех своих продуктах. Самое главное, что контейнеры просто идеальны для микросервисной архитектуры. Они очень легкие в отличие от виртуальных машин, быстро разворачиваются и быстро сворачиваются, с ними очень просто управлять ресурсами. Эффективность использования ресурсов с контейнерами значительно выше, чем с BareMetal или виртуальной машиной. Так, от монолитного приложения, которое непонятно сколько ресурсов может использовать в каждый момент времени, мы перешли к микросервисной архитектуре, разбив приложения на маленькие сервисы, каждый из которых выполняет свою функцию в зависимости от текущих задач.
Выглядит это, конечно, неплохо, но когда каждое приложение имеет десятки или сотни контейнеров, запущенных на каких-то доступных ресурсах, когда нужно обеспечивать связь между ними, резервирование, то необходимо средство оркестрации и управления контейнерами. В нашем случае используется Kubernetes. Эта программа отвечает за то, где должны быть запущены эти контейнеры, как обеспечить резервирование и связь для них, какой контейнер должен быть перезапущен, если что-то случилось, какие контейнеры должны быть развернуты или остановлены в зависимости от текущих задач. Kubernetes дает необыкновенную гибкость. Он абстрагирует уровень железа. Микросервисы разворачиваются там, где есть доступные ресурсы. Можно использовать абсолютно разные сервера внутри Kubernetes-кластера. Нет необходимости следить за тем, где что развернуто. Контейнеры используют доступные ресурсы. Также Kubernetes обеспечивает резервирование: он запускает микросервисы, если они «упали», планирует и запускает микросервисы на других NOD, если что-то случилось с первой. Еще Kubernetes обеспечивает масштабирование. Можно легко расширить свой кластер, добавив новые NOD. Микросервисы быстро наращиваются исходя из требований к CPU или другим ресурсам. Если текущих задач больше нет, Kubernetes мгновенно сворачивает микросервисы, освобождая ресурсы для других микросервисов. С помощью Kubernetes легко обновлять приложения, это делается без остановки самого приложения. Kubernetes следит за доступностью сервисов в процессе обновления, если возникает какая-то критическая ошибка, выполняет откат.
[pdf id=15767]
Kubernetes занимается оркестрацией контейнеров или подов, в которых есть контейнеры с микросервисами, он обеспечивает масштабируемость, резервирование и прочее, но, к сожалению, не знает, что происходит внутри приложения. Для этого у нас есть собственная система AMS, сейчас она имеет новое название PilotManager. Это как раз гибридная NMS в классическом понимании оператора или контент-провайдера, которая как управляет уровнем приложений, так и дает информацию о том, что происходит в вашем Kubernetes-кластере. AMS является универсальной системой управления и мониторинга. С помощью этой системы можно следить за состоянием кластера, серверов и самих микросервисов. Вещательные ОТТ-сервисы доступны для мониторинга и изменения конфигурации. Пользователи могут планировать задачи и эффективно использовать ресурсы. В любой момент времени доступна вся информация по текущим ошибкам, сигнализациям. Существует возможность графической визуализации трактов прохождения сигналов. Естественно, есть возможность перехода на резерв вручную, если это необходимо, либо самой системой создаются условия для этого перехода.
Режиссер эфира: Вы можете забрать SRT-поток и перекодировать его?
Алексей Пискунов: Да, SRT поддерживается в решении TITAN Live как по входу, так и по выходу.
Режиссер эфира: Если мы отдадим вам два видеосигнала, два звука и две графики, может ли ваш сервис обработать это и выдать множество различных трактов на разные сервисы?
Алексей Пискунов: Да, конечно. Можно это протестировать. У нас в Москве есть демо-сток, где есть любые устройства, в том числе TITAN Live. Тут надо распределить задачи. Есть News case contribution, когда сигнал доставляется В2В, а есть distribution, когда сигнал доставляется до многочисленных абонентов. Если это contribution, то, скорее всего, здесь используется SRT, и мы будем рады дать вам демо-устройство и попытаться вместе его настроить.
Тимур Кулгарин: В TITAN Live упоминалось преобразование частоты кадров. Означает ли это, что есть какой-то встроенный алгоритм предсказания движения для этой конверсии, или это простое преобразование?
Алексей Пискунов: Когда идет речь о преобразовании частоты кадров, существуют разные алгоритмы. Если это динамичная картинка и спорт, то алгоритм нужен продвинутый. Пока я не могу сказать, какой алгоритм у нас используется, это тема для отдельного разговора.
