Конвейер стриминга OTT, блок за блоком

Коротко

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

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

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

Что на самом деле значит «конвейер»

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

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

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

Полезное разделение перед стартом: у большинства конвейеров две половины. Data plane (плоскость данных) – путь, по которому реально движутся видеобайты: приём, транскод, упаковка, origin, CDN, плеер. Control plane (плоскость управления) – набор сервисов, которые решают и записывают, при этом тяжёлое видео через них не проходит: сервис прав, говорящий «да, этот зритель может смотреть», и приёмник аналитики, записывающий «вот что произошло». Путаница между ними – самая частая архитектурная ошибка, которую мы видим, поэтому будем держать их явно раздельно.

Блок 1 – Точка приёма: куда приходит видео

Приём (ingest) – это действие по получению исходного видео на платформу, а точка приёма – дверь, через которую оно входит. Дверей две, и устроены они по-разному.

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

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

• RTMP (Real-Time Messaging Protocol) – старый, поверх TCP, поддержан каждым энкодером и софтом вроде OBS и vMix. Восстанавливается после потерь пакетов повторной передачей всего TCP-потока, что даёт всплески задержки на загруженном канале. Всё ещё самый частый студийный путь.
• SRT (Secure Reliable Transport) – современный вещательный выбор. Работает поверх UDP, восстанавливается выборочной повторной передачей, держит примерно 25% потерь при буфере в одну секунду и несёт встроенное шифрование AES-256. SRT – стандарт 2026 для полевой контрибуции через публичный интернет и сотовые каналы.
• WHIP (WebRTC-HTTP Ingestion Protocol) – дверь с наименьшей задержкой, 200–500 миллисекунд, идеален для браузерного входа и интерактивных форматов.

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

Типичный сбой: зрительскую копию принимают за мастер, а потом не могут перекодировать под новое устройство годы спустя – или на стороне live: одна точка приёма без резервного фида, и один оборванный канал контрибуции обрывает эфир. Строить или купить: файловый приём тривиально строится на объектном хранилище (Amazon S3 и аналоги). Live-приём – там, где большинство арендует: медиасервер или стриминговая платформа, терминирующая RTMP/SRT/WHIP и отдающая чистый фид, обычно дешевле, чем держать свою. Затраты: низкие. Хранение мезонинов дёшево за гигабайт и растёт медленно; входящий трафик мелок рядом с исходящим трафиком доставки.

Блок 2 – Транскодинг-ферма: из одного источника – лестница

Фид с камеры или файл-мезонин слишком велики, чтобы стримить как есть. Транскодинг преобразует их с помощью кодека – алгоритма-кодировщика, отбрасывающего визуальные детали, которые глаз не заметит, – в сжатые версии, которые плеер может стримить. Компонент, делающий это в объёме, – транскодинг-ферма: парк машин, часто с GPU-ускорением, перемалывающий минуты видео. Это самый вычислительно тяжёлый блок линии и один из трёх, решающих вашу маржу.

Транскодируют не один раз. Транскодируют в лестницу.

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

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

Выбор кодека задаёт качество-на-бит и охват устройств. H.264 (AVC) – универсальный пол, его декодирует любое устройство; HEVC (H.265) на 40–50% эффективнее и силён на ТВ и технике Apple; AV1 – без роялти и самый эффективный из массовых; VVC (H.266) – новейший и наименее распространённый. Внутренности кодеков – тема раздела Video Encoding; см. как выбрать кодек в 2026. Продуктовый факт для этого блока: более глубокая лестница и более новый кодек оба повышают стоимость транскода, снижая стоимость доставки, так что нагрузка фермы – рычаг, который вы настраиваете, а не константа.

Арифметика счёта за транскод

Транскодинг биллится за минуту вывода, за каждый рунг. Пройдём раз. Допустим, облачный транскодер берёт около $0,015 за минуту вывода HD-рунга (репрезентативная ставка-2026 по прайсу; per-title и резервные цены ниже). Для лестницы из четырёх рунгов на каталоге в 100 часов:

минут вывода = 100 ч × 60 мин × 4 рунга = 24 000 минут вывода
стоимость = 24 000 × $0,015 = $360 за разовое кодирование каталога

Это разовая стоимость на версию титула – дёшево рядом с доставкой, пока вы не умножите её на перекодирования под новые кодеки и каталог в тысячи часов. Рычаг, который ей управляет, – лестница: фиксированная лестница на каждый титул тратит compute на простой контент, поэтому per-title encoding заслуживает отдельной статьи в Блоке 2.

Типичный сбой: фиксированная лестница на каждый титул – кодирование статичного ток-шоу тем же высоким битрейтом, что и быстрый спортивный клип, тратит compute на входе и egress на выходе. Строить или купить: для большинства команд это самое ясное решение «купить» в конвейере. Облачные транскодеры (AWS Elemental MediaConvert, Google Transcoder, Bitmovin) берут за минуту, без фермы. Своя ферма ffmpeg или GPU выигрывает только на очень большом стабильном объёме, где ставка за минуту бьёт амортизацию железа. Компромисс по ферме – отдельная статья Блока 2. Затраты: вычислительно тяжёлый. Оплата за минуту за рунг; управляется дизайном лестницы и выбором кодека.

Блок 3 – Упаковщик: упаковка видео к отправке

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

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

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

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

Упаковщик – также место, где применяется шифрование защищённого контента. Common Encryption (CENC, ISO/IEC 23001-7) позволяет зашифровать сегменты один раз схемой cbcs, а затем выдавать лицензии Widevine, PlayReady и FairPlay из тех же файлов – «зашифруй один раз, лицензируй многим». Полный multi-DRM-воркфлоу – уникальное ядро этого раздела; см. multi-DRM: один воркфлоу, все устройства. Здесь важно, что шифрование – шаг на этапе упаковки, а не отдельное кодирование.

Типичный сбой: упаковка отдельных файлов HLS и DASH там, где CMAF обслужил бы оба, удваивая хранение и кэш; или плохо выбранная длительность сегмента, бьющая по задержке (слишком длинные) или по кэшу (слишком короткие). Строить или купить: упаковка – лёгкий compute, поэтому open-source упаковщики (Shaka Packager, ffmpeg) реально держать самому, но большинство берёт её в связке с сервисом транскода (AWS MediaPackage, Bitmovin), так как шаги тесно связаны. Затраты: умеренный compute; реальный рычаг – один набор файлов на все устройства, что снижает хранение и улучшает кэш ниже по течению.

Блок 4 – Origin: источник истины, из которого тянет edge

Вот первый блок, который верхнеуровневая карта спрятала. Origin – авторитетный сервер, хранящий упакованный, сегментированный, проиндексированный манифестами контент и отвечающий на запросы, которые не может обслужить краевой кэш CDN. Думайте о нём как о центральном складе: краевые кэши – это магазины у дома с популярными товарами, а origin – склад, с которого они пополняются, когда покупатель просит то, чего нет на полке.

Почему origin заслуживает отдельного блока, а не «хранения»? Потому что на масштабе это компонент, который вероятнее всего расплавится. Каждый запрос, который edge не может отдать из кэша – промах кэша (cache miss) – едет назад к origin. Для популярного VOD-титула с высоким попаданием в кэш это ручеёк. Для живой премьеры, где сто тысяч зрителей запрашивают новейший сегмент в одни и те же две секунды, это потоп – «громовое стадо» (thundering herd). Незащищённый origin под ним проседает, а когда origin проседает, буферят сразу все зрители.

Защита – origin shielding (экранирование): назначенный кэш среднего уровня стоит между edge и origin, так что промах гасится шилдом, а не бьёт по origin напрямую. Тысяча одновременных промахов edge за один и тот же сегмент превращается в один запрос к origin. Дизайн origin и шилдинг получают отдельную статью в Блоке 3; всплеск live-премьеры – ещё одну. Держите мысль: origin – туда, куда падают промахи кэша, а промах на масштабе – это DoS-атака, которую вы запустили на себя сами.

Типичный сбой: незащищённый origin за одним CDN, расплавленный live-премьерой или внезапным хитом, кладёт весь сервис без резервного origin. Строить или купить: VOD-origin может быть просто бакетом объектного хранилища, из которого тянет CDN, – дёшево «построить». Live- или высоконагруженный origin с шилдингом и резервом – это реальная инженерия, и managed-сервисы (AWS MediaPackage origin, origin shield от CDN) обычно стоит арендовать, пока у вас нет трафика, чтобы оправдать свой. Затраты: низкие по хранению, но архитектурное решение (с шилдом или без, один регион или несколько) защищает от куда большей стоимости CDN и надёжности позже.

Блок 5 – CDN: доставить байты зрителю на масштабе

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

Метрика, решающая, экономит CDN деньги или просто ретранслирует ваш origin, – процент попаданий в кэш (cache-hit ratio), он же offload ratio: доля запросов, которые edge отдаёт из своего кэша, не беспокоя origin. 95% попаданий – origin видит один запрос из двадцати; 50% – один из двух, и страдают и origin, и счёт за egress.

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

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

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

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

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

Типичный сбой: привязка к одному CDN без резерва, и региональный сбой одного провайдера кладёт весь сервис – и нет второго вендора, против которого торговаться; или плохой дизайн ключа кэша роняет попадания и раздувает и нагрузку origin, и egress. Строить или купить: CDN никто не строит. Этот блок всегда арендуют; решения – какие провайдеры и как оркестрировать между ними. Затраты: обычно самая большая постоянная строка. Защищается дисциплиной кэша, дисциплиной битрейта и переговорами по коммиту.

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

Всё до сих пор невидимо зрителю. Плеер – то, чего он касается: приложение на телефоне, веб-страница, канал на смарт-ТВ – и делает он куда больше, чем показывает пиксели. Он тянет манифест, крутит ABR-логику по лестнице, запрашивает 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 и свой процесс сертификации. Поскольку подключённые ТВ теперь несут большую часть времени просмотра, ТВ-приложения – это там, где аудитория, а не опциональная полировка.

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

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

Блок 7 – Сервис прав: кому разрешено смотреть

Теперь мы переходим из data plane в control plane. Сервис прав (entitlement) – компонент, отвечающий на один вопрос для каждого запроса на воспроизведение: разрешено ли этому зрителю смотреть этот контент прямо сейчас? Это не paywall-интерфейс, который видит зритель, и не биллинг, который списывает с карты, – это авторитет, которому оба доверяют. Он стоит рядом с путём медиа, а не внутри: тяжёлое видео через права не течёт; течёт только маленькое «да или нет».

Этот блок мал в байтах и огромен в последствиях, потому что в нём сходятся в один ответ четыре разных предмета:

• Статус подписки – оплатил ли аккаунт и актуален ли платёж? (Из биллинга.)
• Права на контент – есть ли у платформы право показывать этот титул, на этой территории, в этом окне? (Из метаданных прав.)
• Правила доступа – лимиты одновременных потоков, геоблок, родительский контроль, лимиты устройств.
• Выдача токена – когда ответ «да», сервис прав выдаёт короткоживущий токен, который плеер предъявляет CDN и DRM-лицензионному серверу, чтобы те не перепроверяли бизнес-правила.

Глубокая механика биллинга подписок и движка прав – отдельная статья Блока 5; см. биллинг подписок и права. Причина, по которой права заслуживают отдельного блока, а не графы «монетизация», в том, что почти каждый запутанный зрительский баг – «я заплатил, а пишет „нельзя смотреть“», «играет в одной стране и не играет в другой», «третье устройство блокируется» – это баг прав, а не биллинга или доставки. Рисование прав отдельным блоком – то, что позволяет находить такое быстро.

Типичный сбой: логику прав запекают в плеер или paywall-интерфейс вместо центрального сервиса, и правила расходятся по платформам – веб говорит «да», а ТВ «нет» для одного аккаунта. Строить или купить: права обычно строят, потому что они кодируют ваши конкретные бизнес-правила и права, но строят на купленных частях – провайдер идентичности для аккаунтов, биллинг для статуса подписки, библиотека токенов/JWT для подписи. Оркестрация ваша; примитивы арендованы. Затраты: низкие в инфраструктуре, высокие в риске корректности. Цена ошибки – отток и нагрузка на поддержку, а не счёт из облака.

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

Последний блок замыкает петлю и, как права, живёт в control plane. Приёмник аналитики (analytics sink) – туда, куда падает каждое событие конвейера, чтобы быть посчитанным: воспроизведения, паузы, завершения и QoE-биконы плеера – время старта, доля ребуферинга, отданный битрейт, доля сбоев воспроизведения. «Приёмник» – инженерное слово для назначения, в которое стекаются все эти потоки событий; оттуда они кормят дашборды, сверку биллинга, контентные решения и рекомендации.

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

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

Типичный сбой: считать автоплеи воспроизведениями и принимать программные решения по раздутому вовлечению; или собирать события, но не замыкать петлю, и данные лежат в хранилище, ничего не меняя. Строить или купить: QoE-слой на стороне плеера обычно покупают (Mux Data, Conviva, Datazoom), потому что SDK и бенчмарки зрелые; бизнес-хранилище аналитики обычно строят на облачных дата-инструментах, потому что оно специфично вашим вопросам. Затраты: низкие рядом с транскодом и egress, но данные, которые он даёт, говорят вам, куда тратить остальные бюджеты.

Как один запрос проходит все восемь блоков

Чтобы блоки стали конкретными, проследим один тап «играть» по защищённому титулу по запросу:

1. Плеер спрашивает сервис прав: можно ли этому зрителю смотреть этот титул? Права проверяют подписку, права на контент и правила доступа, затем выдают подписанный токен.
2. Плеер тянет манифест – созданный ранее упаковщиком, лежащий на origin, доставленный через edge CDN.
3. Плеер читает лестницу, выбирает стартовый рунг и запрашивает первые сегменты – транскодированные транскодинг-фермой, отданные с edge (попадание) или вытянутые с origin (промах).
4. Для защищённых сегментов плеер предъявляет токен DRM-лицензионному серверу и получает ключ расшифровки – шифрование применено на этапе упаковки.
5. Воспроизведение стартует; ABR ходит вверх-вниз по лестнице по мере смены сети.
6. Всё это время плеер шлёт QoE-биконы в приёмник аналитики, который записывает сеанс для дашбордов, биллинга и рекомендаций.

Восемь блоков, две плоскости, один тап. Когда сеанс идёт не так, модель «блок за блоком» говорит, куда смотреть: ошибка лицензии – DRM, долгий старт – CDN или origin, сообщение «нельзя» – права, отсутствующее число – аналитика.

Частая ошибка: схлопывание control plane в data plane

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

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

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

Главное

• Конвейер стриминга – это восемь компонентов: приём, транскод, упаковка, origin, CDN, плеер, права, аналитика.
• Делите конвейер на data plane (видеобайты) и control plane (права, аналитика).
• Origin – туда, куда падают промахи кэша; незащищённый origin плавится на live-премьере.
• Транскод – самое ясное «купить»; CDN всегда арендуют; права строят на купленных частях.
• Большинство зрительских багов – это баги прав, а не биллинга или доставки.
• Определите «воспроизведение» прежде, чем считать его; автоплей и боты раздувают наивные метрики.

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

• Что такое OTT-платформа, от и до
• Стоимость OTT-платформы: что она реально стоит
• Масштаб и одновременность: от 1000 до 1 000 000 зрителей