Эталонная архитектура OTT: полная картина

Кратко

Боевая OTT-платформа – сервис, который раздаёт видео зрителям по открытому интернету вместо кабельной приставки, – это две системы, а не одна: data plane, несущая видео (приём, кодирование, упаковка, шифрование, origin, CDN, плеер), и control plane, которая решает и записывает (идентификация, права, биллинг, решение по рекламе, метаданные, аналитика). Главный архитектурный факт: data plane строят на открытых стандартах и шифруют один раз – сегменты CMAF (ISO/IEC 23000-19), запечатанные схемой cbcs из Common Encryption (ISO/IEC 23001-7), отдаваемые как HLS (RFC 8216) и MPEG-DASH (ISO/IEC 23009-1) и лицензируемые для Widevine, PlayReady и FairPlay из тех же файлов. Статья стоимости, определяющая маржу, – доставка: egress CDN – регулярный счёт, задающий вашу маржу, поэтому архитектуру рисуют под максимальный offload кэша и переносимую доставку. Это итоговый разбор блока – полная, размеченная эталонная архитектура, к которой отсылает каждый следующий блок курса.

Зачем это нужно

Если вы основатель медиапроекта, продакт-менеджер или впервые строите стриминг как CTO, вам нужна одна ментальная модель, которая держит платформу целиком, – а не девять разрозненных схем. Без неё команды зашивают права в каждый плеер, относятся к аналитике как к довеску и шифруют схемой, отсекающей треть устройств, а ошибки находят в проде, где они дороги. Эта эталонная архитектура даёт вам блоки, стандарт на каждом переходе и границы, которые не должны сдвигаться: где проходит граница защиты, что относится к control plane и какой компонент решает вашу маржу. Прочитайте один раз – и сможете говорить с инженерами, правообладателями и продавцами CDN, не покупая лишнего. Прилагаемый пакет с заметками по компонентам позволяет сверить собственный дизайн с этой картиной.

Полная картина в одном виде

Большинство схем OTT проваливаются, потому что рисуют одну стрелку слева направо и на этом останавливаются. У настоящей платформы два потока, идущих под прямым углом. Data plane – путь, по которому байты видео идут от исходного файла или живой камеры до экрана. Control plane – всё, что решает, можно ли зрителю смотреть, берёт с него плату, выбирает, что показать, и записывает, что произошло, – и видео ни через что из этого не течёт. Представьте аэропорт: data plane – это полоса и самолёты; control plane – билеты, досмотр, назначение гейтов и операционный дашборд. Обе нужны, а путаница между ними – то, как платформы строят неправильно.

Data plane слева направо – это семь блоков: приём (принять источник), кодирование (собрать ABR-рунги), упаковка (завернуть сегменты в CMAF для HLS и DASH), шифрование (применить cbcs Common Encryption), origin (авторитетное хранилище сегментов и манифестов), CDN (edge-кэши, которые реально отдают зрителям) и плеер (расшифровать и проиграть на каждом экране). Control plane стоит рядом: идентификация и авторизация, права (можно ли этому аккаунту смотреть этот тайтл сейчас?), биллинг и монетизация, решение по рекламе для рекламных тарифов, метаданные и рекомендации и аналитика и quality of experience (QoE). Дальше статья проходит каждый блок, называет стандарт на нём и отмечает единственную границу, которая защищает ваш каталог.

Нажмите, чтобы увеличить

Data plane, блок за блоком

Приём – принять источник

Приём – это входная дверь. Для видео по запросу (VOD) он принимает готовый высококачественный мастер-файл, который часто называют мезонином, – чистую, слабо сжатую копию, из которой строится всё дальше. Для live он принимает непрерывный поток по контрибуционному протоколу – RTMP, SRT или более новому WHIP – от кодировщика на площадке. Задача приёма узкая: проверить источник, нормализовать и передать на кодирование. Ошибётесь здесь – примете битый файл, потеряете live-сегмент – и каждый блок ниже унаследует дефект.

Кодирование – собрать рунги

Один файл не может одинаково хорошо обслужить зрителя на гостиничном Wi-Fi и зрителя на оптике, поэтому платформа собирает несколько версий в разных разрешениях и битрейтах. Этот набор – encoding ladder (рунги), и плеер карабкается вверх и вниз по нему по мере изменения сети – приём, называемый адаптивным битрейтом (ABR). Аналогия – классы мест в самолёте: один рейс, разная цена и комфорт, и плеер бронирует класс, который тянет сеть. Кодировщик – затратный блок, потому что вычисления тарифицируются за выходную минуту; типичный управляемый облачный транскодер вроде AWS Elemental MediaConvert берёт около $0,015 за выходную минуту для HD (AWS MediaConvert pricing, 2026), оплачивается один раз на тайтл. Механику кодеков мы выносим в раздел Video Encoding; здесь рунги – продуктовое решение, разобранное в encoding ladder простыми словами.

Упаковка – завернуть сегменты один раз

Упаковка режет каждый рунг на короткие сегменты (обычно 2–6 секунд) и пишет манифест – индексный файл, который плеер читает, чтобы найти сегменты. Современная практика – упаковывать один раз в Common Media Application Format (CMAF, ISO/IEC 23000-19): один набор fragmented-MP4 сегментов, который индексируют и HLS (IETF RFC 8216), и MPEG-DASH (ISO/IEC 23009-1). До CMAF команды упаковывали одно и то же видео дважды – отдельно под HLS Apple и под DASH, – удваивая хранение и нагрузку на кэш. CMAF это прекращает. Один набор сегментов, два манифеста, любое устройство.

Шифрование – запечатать один раз и правильно

Это блок, который большинство команд делают неверно, и ошибка дорогая, потому что может нарушить лицензию студии. Премиальный контент должен быть защищён системой управления цифровыми правами (DRM) – той, что не даёт скопировать расшифрованное видео. Зонтичный стандарт – Common Encryption (CENC, ISO/IEC 23001-7), и он определяет две схемы: cenc (режим AES-CTR) и cbcs (режим AES-CBC). Они не взаимозаменяемы. Apple FairPlay требует cbcs; современная конвергенция – cbcs везде. Зашифруйте сегменты один раз схемой cbcs – и сможете выдавать лицензии всем трём DRM-системам (Google Widevine, Microsoft PlayReady и Apple FairPlay) из тех же файлов. Это истина «зашифровать один раз, выдать лицензии много», и это самая ценная строка статьи. Зашифруете только cenc – и устройства FairPlay (каждый iPhone, iPad, Apple TV и браузер Safari) не смогут проиграть ваш каталог.

Origin – источник истины

Origin – авторитетное хранилище, где лежат все сегменты и манифесты. Это место, куда CDN идёт, когда у него нет запрошенного сегмента в кэше. Origin – не то место, откуда приходят байты большинства зрителей (это работа CDN), но он должен быть корректным и доступным, потому что промах кэша, на который origin не может ответить, – это зависший поток. Объектное хранилище вроде Amazon S3 (около $0,023 за гигабайт в месяц, AWS S3 pricing, 2026) – обычное хранилище origin. Слой под названием origin shielding – единственный назначенный кэш, который поглощает промахи за origin, – защищает его от наплыва на популярной премьере; мы разбираем это в origin и origin shielding.

CDN – где зрители реально получают видео

Сеть доставки контента (CDN) – флот edge-серверов рядом со зрителями, который отдаёт подавляющее большинство сегментов. Edge-кэш CDN – это магазин у дома, забитый тем, что чаще всего просит район, чтобы не ездить на склад – origin – каждый раз. CDN – блок, определяющий стоимость, потому что его egress – плата за гигабайт видео, отданного зрителям, – это регулярный счёт, задающий вашу маржу. Egress ступенчатый, зависит от обязательств и часто тарифицируется по 95-му перцентилю, поэтому единой универсальной цены не бывает; Amazon CloudFront для США начинается с первого 1 ТБ в месяц бесплатно, затем около $0,085/ГБ за следующие 9 ТБ, со снижением до $0,040/ГБ и ниже в старших ступенях, а годовое обязательство экономит до 30% (AWS CloudFront pricing, обновлено 2026-06-08). Поскольку доставка решает маржу, серьёзные платформы используют не один CDN – см. архитектуру multi-CDN – и агрессивно инженерят offload кэша, разобранный в cost engineering для CDN.

Плеер – расшифровать и проиграть на каждом экране

Плеер – это приложение на каждом экране (веб, iOS, Android, смарт-ТВ, стриминговая приставка), которое читает манифест, забирает сегменты, гоняет ABR-алгоритм, получает лицензию, расшифровывает и проигрывает. В вебе воспроизведение использует два стандарта W3C: Media Source Extensions (MSE), чтобы подавать сегменты в элемент video, и Encrypted Media Extensions (EME, рекомендация W3C с 2017 года), чтобы общаться с модулем расшифровки устройства (CDM) для DRM. Каждая платформа говорит на своём нативном DRM – Safari и устройства Apple используют FairPlay, Chrome и Android – Widevine, Edge и Windows – PlayReady, – и именно поэтому важен cbcs: один набор сегментов, три типа лицензий, любой экран. Плеер – ещё и место, где вы измеряете качество, инструментированное слать QoE-биконы обратно в аналитику.

Control plane – решает и записывает

Control plane никогда не касается байтов видео, и всё же именно он решает, работает ли ваш бизнес. Здесь живут шесть сервисов.

Идентификация и авторизация устанавливает, кто зритель, – регистрация, вход и токен сессии, который едет с каждым запросом. Права (entitlement) – это шлагбаум, отвечающий на один вопрос при каждом показе: можно ли этому аккаунту смотреть этот тайтл в этом регионе прямо сейчас? Права должны быть единым полноценным сервисом, а не логикой, скопированной в каждый плеер, иначе правила расходятся и зрители получают противоречивые ответы на разных устройствах. Биллинг и монетизация ведёт подписки, транзакции или рекламные отношения – в зависимости от того, SVOD, TVOD или AVOD тариф; бизнес-модели несут разные требования и разобраны в SVOD, AVOD, TVOD: бизнес-модели.

Для рекламных тарифов решение по рекламе выбирает, какой ролик показать. Доминирующий боевой паттерн – server-side ad insertion (SSAI), который вшивает рекламу в поток, чтобы блокировщики и причуды устройств её не ломали; рекламные возможности размечаются в потоке стандартом SCTE-35 (ANSI/SCTE 35 2023r1), а сам ролик запрашивается через IAB VAST 4.3 (декабрь 2022). Метаданные и рекомендации – нервная система каталога: тайтлы, обложки, жанры и логика дискавери, решающая, что каждый зритель видит первым; внутренности рекомендательных моделей живут в разделе AI for Video Engineering. Наконец, аналитика и QoE – то, как вы видите внутрь платформы: подсчёт просмотров («показ» – определённое событие, а не догадка) и метрики качества вроде времени старта и ребуферинга, определённые в разделе Video Streaming. Стройте права и аналитику отдельными сервисами с первого дня; оба дёшевы в байтах и решающи в исходе.

Граница защиты – единственная линия, которая защищает ваш каталог

Нарисуйте рамку вокруг сегментов от момента, когда их зашифровали, до момента, когда лицензированный плеер их расшифровал. Эта рамка – граница защиты, и это та архитектурная черта, которую аудитит лицензия студии. Внутри неё видео – это cbcs-зашифрованный CMAF; оно остаётся зашифрованным на origin, через CDN и в транзите к плееру. Ключи живут в отдельном хранилище ключей, а серверы лицензий – один логический сервис, выдающий лицензии Widevine, PlayReady и FairPlay, – отдают плееру ключ расшифровки только после «да» от сервиса прав. Чистое расшифрованное видео существует только внутри защищённого конвейера плеера на устройстве.

Будьте точны в том, что это защищает. DRM останавливает копирование расшифрованных байтов; он не останавливает камеру, наведённую на экран, – это отдельная задача, решаемая forensic watermarking. Output protection вроде HDCP (High-bandwidth Digital Content Protection) – ещё один отдельный слой, охраняющий кабель между устройством и дисплеем. Multi-DRM – это один запертый ящик с тремя по-разному нарезанными ключами, по одному на каждую марку замка устройств, а не три отдельных ящика. Механика – в уникальном ядре этого раздела: multi-DRM, один workflow, все устройства и CENC, CTR, CBCS простыми словами.

Нажмите, чтобы увеличить

Live и VOD на одной архитектуре

Платформа обычно обслуживает и записанное видео по запросу, и живые события, и частая ошибка – вообразить две полностью отдельные платформы. Они делят большую часть архитектуры; различаются в начале. Путь VOD принимает готовый файл, кодирует рунги один раз, упаковывает, шифрует и паркует сегменты на origin – часов нет. Путь live принимает непрерывный поток, кодирует в реальном времени и упаковывает сегменты по мере их производства, так что задержка – разрыв между реальным событием и экраном зрителя – становится бюджетом, измеряемым в секундах. Оба пути сходятся на одном выходе упаковщика, одном cbcs-шифровании, одном origin, CDN и плеере. Спроектировать их так, чтобы они сходились, – то, что позволяет одной платформе делать и то, и другое без удвоения стоимости; детали – в live против VOD: два конвейера, а всплеск премьеры разбирается в масштабировании и конкурентности.

Нажмите, чтобы увеличить

Проработанный пример: сайзинг доставки на 50 000 одновременных зрителей

Поскольку доставка решает маржу, число, которое стоит проговорить вслух, – счёт за egress на масштабе. Допустим, живое событие выходит на пик в 50 000 одновременных зрителей, каждый стримит HD-рендишн со средним битрейтом 5 мегабит в секунду (Мбит/с). Арифметика, по строке за раз:

байт на зрителя в час = 5 Мбит/с ÷ 8 бит/байт × 3 600 с = 2 250 МБ ≈ 2,25 ГБ/час
суммарный egress в час = 50 000 зрителей × 2,25 ГБ      = 112 500 ГБ ≈ 112,5 ТБ/час
стоимость egress (смеш.) = 112 500 ГБ × ~$0,05/ГБ        ≈ $5 625 в час

Трёхчасовое событие, таким образом, стоит примерно $16 900 только в egress при смешанной ставке $0,05/ГБ – до кодирования, origin и DRM. Это число сильно двигают два рычага. Первый: более эффективный кодек при том же качестве срезает 5 Мбит/с и линейно масштабирует весь счёт вниз. Второй: смешанная ставка падает со ступенями обязательств и с более высокой долей попаданий в кэш, потому что каждый сегмент, отданный с edge CDN, а не с origin, – это сегмент, за чей origin-egress вы не платите дважды. Вот почему архитектуру рисуют под максимальный offload и почему именно регулярная строка egress, а не разовая стройка, – число, решающее, есть ли у бизнеса маржа. Полная модель на уровне месяца – в модели стоимости OTT.

Архитектура как таблица компонентов

Когда блоки стоят в таблице со стандартом на каждом и колонкой того, чем вы реально владеете, решения по стройке становятся конкретными. Управляемые компоненты быстрее запускать; те, что помечены «владеть», – там, где живут маржа и переносимость.

Таблица 1. Каждый компонент, стандарт на нём, plane, к которому он относится, и стоит ли им владеть. Колонка «владеть» отмечает, где живут маржа (CDN), переносимость (CMAF, cbcs) и контроль над продуктом (права).

Частая ошибка: прикрутить control plane к плееру

Самый частый провал архитектуры, который мы видим, – не в data plane, а в отношении к control plane как к довеску, зашитому в каждый плеер. Когда логика прав продублирована внутри веб-приложения, iOS-приложения и ТВ-приложения, эти три расходятся, и зритель, которому можно смотреть на телефоне, получает отказ на телевизоре. Когда аналитику добавляют поздно, вы выпускаете платформу, в которую не видите, и дебажите ребуферинг вслепую. Исправление структурное: рисуйте права и аналитику отдельными полноценными сервисами рядом с data plane с первого дня, где каждый плеер вызывает один и тот же API прав и шлёт одни и те же QoE-биконы. Вторая частая ошибка – шифрование только cenc, молча ломающее каждое устройство FairPlay, – устраняется единственным уже названным правилом: шифровать один раз схемой cbcs.

Где здесь Фора Софт

Эталонная архитектура полезна только если команда может собрать её правильно на масштабе, который нужен бизнесу, а трудное – именно границы: держать доставку переносимой между CDN, ставить границу защиты в правильное место с cbcs с первого дня и делать права и аналитику полноценными, а не прикрученными. Фора Софт с 2005 года делает софт для видеостриминга, OTT/Internet TV, e-learning, телемедицины и видеонаблюдения – 250+ выпущенных проектов для 400+ клиентов, – и эта работа ровно про задачу сборки: связать управляемое кодирование, multi-CDN-доставку и multi-DRM на стандартах в кастомную платформу, чья юнит-экономика держится по мере роста аудитории от тысячи зрителей до миллиона. Когда медиакомпании нужна архитектура, масштабирующаяся без сдачи маржи на наценку реселлера за egress, – это и есть инженерия, которую мы приносим.

Главное

• OTT-платформа – это две системы: data plane несёт видео, control plane решает и записывает.
• Упаковать один раз в CMAF; зашифровать один раз cbcs; отдать как HLS и DASH; лицензировать Widevine, PlayReady, FairPlay из тех же файлов.
• Граница защиты охватывает сегменты от шифрования до лицензированного показа; DRM защищает байты, не экран.
• Egress CDN – регулярная статья, задающая маржу: проектируйте под offload кэша и переносимую доставку.
• Делайте права и аналитику полноценными сервисами с первого дня, а не логикой, скопированной в каждый плеер.
• Live и VOD делят один бэкенд и различаются только приёмом и таймингом.

Что почитать дальше

• Конвейер стриминга, блок за блоком
• Multi-DRM, один workflow, все устройства
• Масштабирование и конкурентность: от 1 000 до 1 000 000 зрителей