Что такое OTT-платформа: конвейер от и до

Автор: Николай СапуновОбновлено: август 202621 мин чтения
Содержание статьи +

Коротко

OTT-платформа – это софт, который превращает видеофайл или живой эфир в поток, доступный миллионам зрителей на телефоне, ноутбуке или телевизоре без кабельной подписки. Работа идёт по цепочке из восьми блоков: ingest, кодирование, упаковка, защита, доставка, воспроизведение, монетизация и аналитика. Каждый блок делает одну задачу, опирается на известный набор технологий и концентрирует затраты в предсказуемом месте – вычисления на кодирование, egress CDN и лицензии DRM решают вашу маржу. Эта статья – карта, к которой возвращается весь курс: прочтите её один раз, и любая следующая тема найдёт своё место.

Кому и зачем это нужно

Если вы основатель, продакт-менеджер или впервые строите стриминг как CTO, слово «OTT» прячет десяток движущихся частей, тайну которых вендоры охотно поддерживают. Нельзя принять решение «строить или купить», говорить с инженерами на равных и читать счёт из облака, пока вы не можете назвать каждую часть и сказать, что она делает. Эта статья даёт вам этот словарь и эту ментальную модель простым языком, с отметками затрат на карте. К концу вы сможете посмотреть на любой стриминговый продукт и указать на блок, который ломается, – или на блок, который тихо съедает бюджет.

Что на самом деле значит «OTT»

Начнём с названия. OTT – это over-the-top, «поверх», и то, «поверх» чего идёт сигнал, – это традиционное платное ТВ: кабельная приставка, спутниковая тарелка, управляемая сеть оператора. OTT-платформа доставляет видео «поверх» обычного публичного интернета – сразу в приложение, без кабельной подписки между ними. Netflix, Disney+, YouTube и региональное спортивное приложение – всё это OTT. И корпоративный портал обучающих видео для сотрудников – тоже.

Сопутствующий термин – VOD, video on demand, видео по запросу: контент в библиотеке, который зритель запускает когда захочет, в отличие от живого эфира, который смотрят все одновременно. Большинство OTT-платформ обслуживают и то, и другое: каталог по запросу и иногда живые события сверху. Отдельная статья курса подробно разводит словарь – OTT, VOD, live, linear и FAST. Пока держите одну мысль: OTT – это способ доставки, а VOD – один из видов контента, который он доставляет.

Почему OTT стоит строить – из-за размера приза. Мировая выручка OTT-видео в 2026 году оценивается примерно в $353 млрд, при среднем доходе на пользователя около $81 в год (Statista, 2026). И аудитория переехала в гостиную: подключённые телевизоры (connected TV) дают теперь около 58% времени просмотра стриминга, опережая мобильные, а в домах США две платформы – Roku с 28% и Samsung с 23% – контролируют большую часть «входа» на CTV (Parks Associates, апрель 2026). То, где смотрят ваши зрители, определяет, какие блоки конвейера пропустить нельзя.

Конвейер в одном предложении

Вот вся платформа в одну строку – порядок, в котором контент путешествует:

Ingest → Кодирование → Упаковка → Защита (DRM) → Доставка (CDN) → Плеер → Монетизация → Аналитика.

Думайте об этом как о фабрике. Сырьё прибывает с одного конца (ingest), нарезается на продаваемые размеры (кодирование), пакуется к отгрузке (упаковка), пломбируется (DRM), развозится по региональным складам ближе к покупателю (CDN), распаковывается и потребляется (плеер), пробивается на кассе (монетизация) и считается для следующего планирования (аналитика). Каждый блок ниже – одна станция этой линии. Пройдём по каждой: что делает, какая типовая технология, частая ошибка и где концентрируется стоимость.

Рисунок 1. Сквозной конвейер OTT. Три оранжевых этапа – кодирование, доставка через CDN и DRM – концентрируют постоянные затраты.

Блок 1 – Ingest: как видео попадает внутрь

Ingest – это просто приём исходного видео в платформу. Форм две, и выглядят они почти по-разному.

Для контента по запросу ingest – это загрузка файла. Студия или контент-команда отдаёт вам высококачественный исходник – так называемый mezzanine, чистый «негатив», который вы храните и из которого всегда перекодируете, но никогда не показываете зрителю напрямую. Mezzanine большой (полнометражный фильм – десятки или сотни гигабайт), и вы храните его, потому что каждое будущее устройство, кодек или повышение качества перекодируются из него.

Для живого контента ingest – это поток в реальном времени по протоколу контрибуции, то есть каналу, который несёт видео в вашу платформу, в отличие от дистрибуции, несущей его дальше к зрителям. Типовые контрибуционные протоколы – RTMP (старый, но повсюду), SRT (современный broadcast-grade выбор) и WHIP (WebRTC-HTTP Ingestion Protocol, для задержки менее секунды). Их механика разбирается в разделе Video Streaming; здесь важно одно: живое видео должно прибыть, прежде чем что-либо ещё произойдёт, и нет второго шанса перетянуть кадр, потерянный по дороге.

Типовая технология: объектное хранилище (Amazon S3 и аналоги) для mezzanine; ingest-эндпойнт или медиасервер для живых потоков. Частая ошибка: считать зрительскую версию мастером, а потом не суметь перекодировать под новое устройство спустя годы. О затратах: хранение mezzanine реально, но редко ломает бюджет – гигабайт дёшев, объём растёт медленно.

Блок 2 – Кодирование: делаем видео пригодным для стриминга

Видео с камеры или mezzanine-файл слишком велики, чтобы стримить как есть. Кодирование (или транскодирование, когда вы конвертируете из одного сжатого вида в другой) уменьшает видео с помощью кодека – алгоритма coder-decoder, который выбрасывает зрительную информацию, незаметную глазу. Это самая вычислительно тяжёлая станция линии и одна из трёх, что решают маржу.

Но кодируете вы не один раз. Вы кодируете много раз – в лестницу.

Лестница кодирования (encoding ladder)

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

СтупеньРазрешениеБитрейтКого обслуживает
11920×1080 (1080p)5 000 kbpsБыстрый домашний Wi-Fi, большой экран
21280×720 (720p)3 000 kbpsУверенный широкополосный доступ
3854×480 (480p)1 200 kbpsМобильный при хорошем сигнале
4640×360 (360p)600 kbpsСлабое или загруженное соединение

Плеер измеряет сеть и прыгает вверх-вниз по лестнице в реальном времени. Эта техника – переключение ступеней, чтобы избежать «крутящегося колёсика», – называется адаптивный битрейт (ABR, adaptive bitrate streaming); её внутренности разобраны в нашем руководстве по ABR. Для этой карты держите мысль: одно видео становится множеством файлов, и вы платите за вычисления, чтобы сделать каждую ступень.

Какой кодек

Выбор кодека задаёт и качество-на-бит, и охват устройств. В 2026 важны четыре:

  • H.264 (AVC) – универсальный пол. Любое устройство за последние пятнадцать лет его декодирует. Наименее эффективный из четырёх, но почти всегда включается как запасная ступень.
  • HEVC (H.265) – примерно на 40–50% эффективнее H.264, силён на ТВ и устройствах Apple, с запутанной историей лицензирования.
  • AV1 – royalty-free кодек от Alliance for Open Media; лучшая эффективность из массовой четвёрки, быстро растёт на новом «железе».
  • VVC (H.266) – самый новый и эффективный, наименее распространённый; пока за ним наблюдают, а не возят на нём грузы.

Внутренности кодеков – как именно каждый сжимает биты – относятся к разделу Video Encoding; см. как выбрать кодек в 2026. Здесь продуктовый факт – компромисс: новые кодеки режут счёт за доставку, но достигают меньшего числа устройств, поэтому большинство платформ возят микс.

Типовая технология: облачные транскодеры (AWS Elemental MediaConvert, Bitmovin) или открытые инструменты (ffmpeg, Shaka Packager). Частая ошибка: фиксированная лестница для всех тайтлов – кодировать простой мультфильм тем же высоким битрейтом, что и динамичный боевик, тратя вычисления на входе и egress на выходе. Лекарство – per-title encoding – получает отдельную статью в Блоке 2. О затратах: кодирование затратно. Вы платите за минуту видео на каждую ступень, и глубокая лестница по большому каталогу набегает быстро.

Блок 3 – Упаковка: «коробим» видео к отгрузке

Кодирование даёт сжатое видео. Упаковка оборачивает его в формат-контейнер и небольшие скачиваемые куски, понятные стриминговому плееру. Стриминг не шлёт один гигантский файл; он режет видео на сегменты – короткие куски, обычно по 2–6 секунд, – плюс манифест, текстовый индекс, перечисляющий каждый сегмент и каждую ступень лестницы, чтобы плеер знал, что запросить дальше.

Доминируют два формата упаковки, и им соответствуют два типа манифеста:

  • HLS (HTTP Live Streaming) – формат Apple, описанный в IETF RFC 8216 (август 2017), сейчас готовится второе издание. Его манифест – плейлист .m3u8. HLS обязателен для нормального воспроизведения на устройствах Apple.
  • MPEG-DASH (Dynamic Adaptive Streaming over HTTP) – стандарт ISO, ISO/IEC 23009-1. Его манифест – файл .mpd. Распространён на Android, смарт-ТВ и в открытом вебе.

Годами поддержка обоих означала упаковывать видео дважды – два набора сегментов, двойное хранение. CMAF (Common Media Application Format), стандартизированный как ISO/IEC 23000-19, это прекратил. CMAF задаёт единый формат сегментов на базе fragmented-MP4 (fmp4), на который может ссылаться и .m3u8 HLS, и .mpd DASH. Вы упаковываете один набор сегментов и обслуживаете все устройства. Глубокая механика – в нашем разборе CMAF и сравнении HLS и DASH; продуктовый вывод: упакуйте один раз через CMAF, адресуйте из двух манифестов.

Типовая технология: Shaka Packager, AWS MediaPackage, Bitmovin. Частая ошибка: паковать отдельные файлы HLS и DASH там, где CMAF обслужил бы оба, удваивая хранение и кэш без всякой выгоды. О затратах: умеренно. Упаковка – лёгкие вычисления; её реальный рычаг – дать одному набору файлов обслуживать все устройства, что снижает хранение и улучшает кэширование дальше по линии.

Блок 4 – Защита: запираем премиальный контент

Если в каталоге есть лицензионные фильмы, спорт или любой контент, который студия ждёт защищённым, нужен DRM (digital rights management) – технология, не дающая скопировать расшифрованное видео с устройства. Пропустите её – и нарушите ту самую лицензию, что позволила вам нести контент. DRM – третий из трёх решающих маржу блоков и чаще всего понимаемый неверно.

Сначала важное различие: DRM защищает поток и ключи, а не экран. Он не даёт сохранить расшифрованный файл, но не остановит камеру, направленную на дисплей. Отдельный слой – HDCP (High-bandwidth Digital Content Protection) – стережёт кабель между устройством и внешним монитором. Будьте точны с этой моделью угроз – это самое частое заблуждение про DRM.

Три системы, один процесс

В мире три системы DRM, разделённые по экосистемам:

  • Widevine – у Google, на Android, в Chrome и большинстве смарт-ТВ.
  • PlayReady – у Microsoft, на Windows, Xbox и многих ТВ.
  • FairPlay – у Apple, на iPhone, iPad, Mac и Apple TV.

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

Девиз – «encrypt once, license many», «зашифруй раз, лицензируй многим». Представьте один запертый ящик с тремя по-разному выточенными ключами – по одному на каждый бренд замка устройств. Вы запираете ящик один раз; раздаёте три формы ключа. Глубже о Common Encryption – в нашей статье про CENC; процесс multi-DRM получит отдельный разбор далее в курсе.

Типовая технология: multi-DRM сервисы (Axinom, EZDRM, PallyCon, Verimatrix), брокеры всех трёх лицензий. Частая ошибка: шифровать только через cenc, что молча ломает FairPlay и закрывает доступ всем зрителям Apple. О затратах: DRM – постоянная статья – multi-DRM сервисы берут за выданную лицензию или активный поток. Закладывайте с первого дня для любого лицензионного каталога.

Блок 5 – Доставка: довозим байты до зрителя

Теперь сегменты существуют – упакованные и защищённые. Доставка – задача переместить их из вашего хранилища к зрителю, который может быть где угодно на Земле, и система, которая это делает, – CDN (content delivery network). Это крупнейшая постоянная строка в большинстве стриминговых счетов и первый из трёх затратных блоков в порядке, который ощущает зритель.

CDN – это сеть граничных (edge) серверов по всему миру, хранящих копии ваших популярных сегментов ближе к зрителям. Думайте об edge-кэше как о магазине у дома, где лежит то, что район спрашивает чаще всего, чтобы не ехать на центральный склад – ваш origin-сервер – за каждым запросом. Когда зритель в Берлине жмёт play, сегменты приходят с немецкого edge, а не из вашего хранилища в Вирджинии. Это режет задержку и, что важнее, счёт: каждый запрос, отданный edge из кэша, – это запрос, который не пришлось обслуживать origin.

Почему egress решает маржу

Постоянная плата, которая важна, – это egress – то, что CDN берёт за отправку байтов наружу, зрителям. Egress тарифицируется ступенчато (цена за гигабайт падает с ростом объёма), зависит от обязательств (более низкие ставки выторговываются обещанием объёма) и часто считается по перцентилю пиковой нагрузки, а не плоской ставкой за гигабайт. Поэтому одна названная цена – никогда не вся правда; всегда указывайте модель и дату.

Пройдём арифметику один раз, потому что число удивляет. Возьмём публичную прайс-ставку для примера: AWS CloudFront берёт примерно $0,085 за гигабайт для первых 10 ТБ в месяц в США и Европе, со снижением к $0,06 на больших объёмах (AWS, Q2 2026). Пусть 10 000 зрителей смотрят по одному часу на ступени 3 000 kbps:

байт на зрителя-час = 3 000 kbps ÷ 8 × 3 600 с = 1 350 000 КБ ≈ 1,35 ГБ
итого = 1,35 ГБ × 10 000 зрителей ≈ 13 500 ГБ ≈ 13,5 ТБ
стоимость ≈ 10 000 ГБ × $0,085 + 3 500 ГБ × $0,080 ≈ $850 + $280 = $1 130

Один обычный час для скромной аудитории – больше тысячи долларов только на egress, и это повторяется при каждом просмотре. Поэтому инженерии стоимости CDN (multi-CDN, разгрузка кэша, счёт по 95-му перцентилю) посвящён целый блок далее, и поэтому важен per-title encoding: срезав битрейт без потери качества, вы срезаете этот счёт на каждом просмотре.

Типовая технология: Akamai, Amazon CloudFront, Cloudflare, Fastly; часто два и больше в схеме multi-CDN ради устойчивости и рычага по цене – см. нашу статью про multi-CDN. Частая ошибка: привязка к одному CDN без failover, когда региональный сбой одного провайдера кладёт весь сервис – и нет второго вендора, против которого торговаться по цене. О затратах: egress – обычно крупнейшая постоянная статья. Защищайте её кэшированием и дисциплиной битрейта.

Блок 6 – Плеер: приложение на каждом экране

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

Сложность плеера в том, что он живёт на многих экранах сразу, и они не делят код. Серьёзная OTT-платформа поддерживает некий микс: веб (HTML5-видео через браузерные Media Source Extensions и Encrypted Media Extensions – стандарты W3C, причём EME – Рекомендация 2017 года), приложения iOS и Android и ценные «гостиные» цели – Roku, Samsung Tizen, LG webOS, Apple tvOS и Amazon Fire TV. У каждой платформы свой плеерный фреймворк, свои причуды DRM и свой процесс сертификации. Поскольку connected TV несут теперь большую часть просмотра, ТВ-приложения – не опциональный лоск, а место, где находится аудитория.

Типовая технология: hls.js и Shaka Player (веб), AVPlayer (Apple), ExoPlayer/Media3 (Android) плюс нативные SDK под каждую ТВ-платформу. Частая ошибка: выпустить отличный веб- и мобильный плеер и слабое ТВ-приложение – ровно там, где сейчас идёт большинство просмотров. О затратах: разработка клиентов – затраты на постройку, не постоянные, но они растут с числом поддерживаемых платформ; каждый новый экран – новая кодовая база на поддержку.

Блок 7 – Монетизация: превращаем просмотры в выручку

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

  • SVOD (subscription VOD) – зрители платят регулярную подписку за доступ. Архетип – Netflix. Нужны биллинг, entitlement (кому что разрешено смотреть) и обычно сильный DRM.
  • AVOD (advertising VOD) – бесплатно для зрителя, окупается рекламой. Нужны стек вставки рекламы и серверы решений по рекламе.
  • TVOD (transactional VOD) – оплата за тайтл, аренда или покупка. Нужны витрина и транзакционный биллинг.
  • FAST (free ad-supported streaming TV) – рекламные линейные каналы, стриминговый родственник эфирного ТВ.

Большинство реальных платформ возят гибрид – скажем, подписку с рекламным тарифом. Выбор бизнес-модели достаточно весом, чтобы получить отдельную статью (SVOD/AVOD/TVOD), как и машинерия вставки рекламы, использующая стандарты вроде SCTE-35 для разметки мест под рекламу и VAST для её показа. Один факт с этой карты: модель монетизации – не фича, которую прикручивают в конце, она определяет ваш paywall, рекламный стек, уровень DRM и аналитику. Выбирайте до постройки, а не после.

Типовая технология: платформы подписочного биллинга, server-side ad insertion (Google DAI, AWS MediaTailor), сервисы paywall и entitlement. Частая ошибка: строить сначала конвейер, потом бизнес-модель, и обнаружить, что рекламный стек или правила entitlement требуют переархитектуры. О затратах: смешанные – комиссии за биллинг и показ рекламы постоянны и зависят от модели; стоимость живёт в стеке, которого модель требует.

Блок 8 – Аналитика: знать, что произошло

Последний блок замыкает петлю. Аналитика – то, как вы узнаёте, работает ли платформа, – и бизнес-вопросы (сколько людей смотрели, как долго, ушли ли в отток), и качество, собранное под зонтиком QoE (quality of experience): сколько секунд шёл старт воспроизведения, как часто оно подвисало на ребуферинг, какое качество видео зрители реально получили.

QoE важна, потому что напрямую отражается на выручке. Медленный старт или ребуферинг посреди показа – самая частая причина бросить поток, а брошенный поток – потерянное время просмотра и, для рекламных моделей, потерянный доход. Дисциплина измерения времени старта и ребуферинга разобрана в нашей статье про метрики QoE; OTT-специфичная карта аналитики получает здесь отдельный блок.

Одна точность, потому что она кусает всех: «просмотр» – это определённое событие, а не догадка. Автоплей, боты и разница между «видеоэлемент загрузился» и «зритель реально посмотрел 30 секунд» могут раздуть числа в два-три раза, если не определить метрику заранее. Решите, что считается просмотром, прежде чем о нём отчитываться.

Типовая технология: Mux Data, Conviva, Datazoom плюс ваш собственный data-пайплайн. Частая ошибка: считать автоплеи просмотрами, а потом принимать программные решения на раздутой вовлечённости. О затратах: низкие на фоне кодирования и egress, но данные, которые она даёт, и говорят, куда тратить остальные бюджеты.

Где на самом деле концентрируется стоимость

Отойдите от линии, и три блока загораются оранжевым: кодирование, доставка и защита. Кодирование – вычисления, оплачиваемые за минуту на ступень. Доставка (egress CDN) – постоянный счёт, растущий с каждым зрителем-часом. Лицензирование DRM – плата за поток или за лицензию на защищённый контент. Хранение, упаковка и аналитика реальны, но вторичны. Разработка клиентов – затраты на постройку, растущие с числом экранов, а не зрителей.

Практический вывод: два крупнейших рычага маржи – это лестница кодирования (умнее лестница – меньше и вычислений, и egress) и стратегия CDN (кэширование, multi-CDN и переговоры по объёму режут крупнейшую постоянную строку). Почти любая история оптимизации затрат в OTT сводится к одному из этих двух. Подробная модель стоимости OTT проходит всю арифметику с рабочим примером.

Рисунок 2. Где концентрируются постоянные затраты. Egress, вычисления кодирования и лицензии DRM доминируют; хранение, упаковка и аналитика отстают.

Строить, купить или собрать

Знание восьми блоков позволяет ответить на первое реальное решение: строить каждый блок, купить готовую платформу или собрать из облачных частей? Готовый OTT-продукт (Brightcove, JW Player, Vimeo OTT, Muvi) отдаёт каждый блок предварительно связанным – быстро, с наименьшим контролем и самой тонкой маржой. Сборка из облачных примитивов (AWS MediaConvert и MediaLive для кодирования, MediaPackage для упаковки, CloudFront для доставки, multi-DRM брокер для защиты) даёт больше контроля за большую работу по интеграции. Полностью кастомное решение даёт максимум контроля и лучшую маржу вдолгую за самую большую стартовую цену.

Универсально правильного ответа нет – есть лишь тот, что подходит вашему масштабу, каталогу, модели монетизации и тому, сколько маржи вам нужно удержать. Статья «строить или купить» проходит компромиссы в деньгах, времени и контроле. И да – отвечая на вопрос каждого основателя – вы можете построить «клон Netflix» в смысле сборки этих восьми блоков; трудна не архитектура, которая хорошо понятна, а её эксплуатация в масштабе и по стоимости, чему и посвящён остаток курса. За более коротким коммерческим обзором – наш гид по OTT-платформам.

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

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

Главное

  • OTT доставляет видео по открытому интернету на любой экран; VOD – один из видов контента, который он несёт.
  • Конвейер – восемь блоков: ingest, кодирование, упаковка, защита, доставка, плеер, монетизация, аналитика.
  • Вычисления кодирования, egress CDN и лицензии DRM – три постоянные статьи, решающие маржу.
  • Упакуйте один раз через CMAF; зашифруйте один раз через cbcs и лицензируйте Widevine, PlayReady, FairPlay.
  • Connected TV несут теперь большую часть просмотра, поэтому ТВ-приложения обязательны, а не опциональны.
  • Выбирайте модель монетизации до постройки – она формирует каждый предыдущий блок.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.