Клиентская матрица OTT: веб, мобильные, смарт-ТВ

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

Кратко

OTT-сервис (over-the-top – доставка видео через открытый интернет, а не через кабельную приставку) должен работать на множестве экранов: в веб-браузерах, на iPhone и Android-смартфонах, на Smart TV от Samsung и LG, на стриминговых устройствах вроде Roku, Amazon Fire TV и Apple TV. Каждая платформа – это отдельное приложение со своим языком программирования, своим видеоплеером и своей системой защиты контента (DRM), поэтому «сделать OTT-приложение» на деле означает «сделать шесть–десять приложений, которые должны вести себя одинаково». Статья разбирает всю матрицу устройств, показывает, какой движок плеера и какой DRM навязывает каждая платформа, ранжирует экраны по охвату аудитории против трудозатрат на разработку и поддержку и даёт обоснованный порядок запуска. Главный вывод – scalability-first: выбирайте платформы запуска по тому, где реально смотрит ваша аудитория и сколько стоит поддержка каждой, а не по тому, что проще показать на демо.

Почему это важно

Если вы планируете OTT-платформу, именно на клиентской матрице бюджет тихо удваивается. Основатели закладывают стоимость «приложения» и уже после запуска обнаруживают, что сборка под Smart TV – это отдельный проект от сборки под iOS, что Roku использует язык программирования, который почти нигде больше не встречается, и что у каждой платформы своя очередь сертификации. Статья – для медиаоснователя, продакт-менеджера или впервые строящего стриминг CTO, которому нужно решить, какие экраны поддерживать, в каком порядке и какая для этого нужна команда. Это якорная статья блока клиентских приложений: разборы по платформам (веб-воспроизведение, iOS и Android, Smart TV, Roku) опираются на нарисованную здесь карту.

Одна идея: каждый экран – это отдельное приложение

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

Телевизор на операционной системе Samsung Tizen (ПО, на котором работает телевизор) не запустит приложение, написанное для телевизора LG на webOS. Ни тот ни другой не запустят ваше приложение для Roku, потому что у Roku собственный язык программирования. Ваше приложение для iPhone не установится на Android-смартфон. Поэтому сервис, желающий быть «на всех экранах», берёт на себя портфель приложений – обычно шесть–десять отдельных сборок, – у которых общий бэкенд, но почти ничего общего на фронтенде.

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

Рисунок 1. Клиентская матрица OTT. Шесть семейств платформ – веб, iOS, Android, Smart TV, стриминговые устройства и консоли – каждое отдельное приложение со своим языком, видеоплеером и DRM, обслуживаемое одним общим бэкендом.

Шесть семейств платформ простыми словами

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

Веб-браузер. Самая открытая платформа и обычно самая дешёвая. Сервис работает как веб-страница, которая воспроизводит видео двумя браузерными стандартами: Media Source Extensions (MSE), позволяющий JavaScript передавать видео плееру по частям, и Encrypted Media Extensions (EME), позволяющий браузеру общаться с DRM. Браузерный стек разбираем в веб-воспроизведении, а сам механизм MSE/EME – в разделе про видеостриминг.

Мобильные: iOS и Android. Две платформы для телефонов и планшетов – два отдельных нативных приложения. На iOS от Apple вы пишете на Swift и воспроизводите через AVPlayer, встроенный плеер Apple; на Android от Google – на Kotlin и через ExoPlayer (теперь поставляется как Media3), встроенный плеер Google. Они же навязывают правила биллинга магазинов приложений, формирующие монетизацию.

Smart TV. Телевизоры со встроенным стриминговым ПО. Два крупнейших – Samsung Tizen и LG webOS, оба запускают приложения, написанные в основном на веб-технологиях (HTML, CSS, JavaScript), но со своими плеерами и особенностями. Это семейство несёт самый тяжёлый налог фрагментации – см. приложения для Smart TV.

Стриминговые устройства (свистки и приставки). Подключаемые устройства, добавляющие стриминг любому телевизору: Roku, Amazon Fire TV, Apple TV и Android TV / Google TV от Google. Roku – отдельный мир на языке BrightScript с UI-фреймворком SceneGraph; Fire TV внутри – это Android; Apple TV работает на tvOS, близком к iOS. См. разработку под Roku и Apple TV и Fire TV.

Игровые консоли. PlayStation и Xbox умеют запускать стриминговые приложения, но это специализированная, дорогая цель с малой долей времени просмотра. Большинство сервисов добираются до них поздно или никогда.

Авто, операторские приставки и длинный хвост. Операторские STB, автомобильные экраны и встроенные устройства существуют, но почти для любой новой платформы это забота третьей фазы, а не платформа запуска.

Три вещи, которые различаются на каждом экране: язык, плеер, DRM

Внутри каждого семейства меняются три технических факта, и вместе они объясняют, почему каждое приложение – отдельный проект.

Первое – язык программирования и UI-фреймворк. Веб – JavaScript. iOS – Swift. Android и Fire TV – Kotlin/Java. Samsung Tizen и LG webOS – веб-технологии со своими моделями приложений. Roku – BrightScript, язык, который вы не используете больше нигде в стеке. Без осознанной кросс-платформенной стратегии повторно использовать код между ними почти нельзя – к этому мы вернёмся ниже.

Второе – видеоплеер. Плеер скачивает видео, подстраивает качество под сеть (адаптивный битрейт, ABR – см. адаптивный битрейт-стриминг), управляет буфером и восстанавливается после ошибок. Одни платформы дают вам мощный нативный плеер (AVPlayer на Apple, ExoPlayer/Media3 на Android); другим нужен open-source плеер, например Shaka Player или hls.js, поверх браузерных MSE/EME. Внутреннюю механику разбираем в инженерии видеоплеера.

Третье – система DRM. DRM – технология, не дающая копировать премиальный контент – это не одна система, а три, и какую вы обязаны использовать, решает устройство, а не вы. Widevine от Google работает на Android, в Chrome, на Android TV и Fire TV. PlayReady от Microsoft – на Windows, Xbox, на большинстве Smart TV (Tizen, webOS) и на Roku. FairPlay от Apple – в Safari, на iOS и tvOS. Чтобы покрыть все экраны, нужны все три – именно для этого существует multi-DRM. Хорошая новость, разобранная в той статье: видео шифруется один раз, а лицензии выдаются для всех трёх; плохая – клиентские приложения должны каждое интегрировать тот DRM, который требует их платформа.

Вот матрица, которую в итоге рисует каждый OTT-архитектор. Столбец «DRM» – это столбец покрытия: он показывает, какую систему защиты навязывает устройство.

ПлатформаЯзык / фреймворкТипичный плеерТребуемый DRMОтносительные трудозатраты
Веб-браузерJavaScript (HTML/CSS)Shaka Player, hls.js, dash.jsWidevine + PlayReady (FairPlay в Safari)Низкие
iOS / iPadOSSwift / SwiftUIAVPlayerFairPlayСредние
Android телефон/планшетKotlin / JavaExoPlayer (Media3)WidevineСредние
Samsung Smart TVВеб-приложение (Tizen)AVPlay / ShakaPlayReady (Widevine)Высокие
LG Smart TVВеб-приложение (webOS)нативный / ShakaPlayReady (Widevine)Высокие
RokuBrightScript / SceneGraphНативный плеер RokuPlayReadyВысокие
Amazon Fire TVKotlin / Java (Android)ExoPlayer (Media3)WidevineСредние
Apple TV (tvOS)Swift / SwiftUIAVPlayerFairPlayСредние
Android TV / Google TVKotlin / JavaExoPlayer (Media3)WidevineСредние
Игровые консолиSDK платформыплеер платформыPlayReady (зависит)Очень высокие

Таблица 1. Клиентская матрица OTT. Каждая платформа навязывает язык, плеер и DRM. Ни одна кодовая база не покрывает столбец; раскол DRM (Widevine / PlayReady / FairPlay) решает устройство. Данные о плеерах и DRM актуальны на 2026 год – перепроверяйте по платформам.

Смысл таблицы тот же, что и вывод о стоимости: столбцы не схлопываются. Нет языка, плеера или DRM, покрывающего все строки. Это неустранимая сложность матрицы.

Где на самом деле аудитория: сторона охвата

Scalability-first означает: вы выбираете платформы по тому, где смотрит аудитория, затем – по стоимости каждой. Начнём с охвата. Цифры ниже – США, 2026; они различаются по странам, так что пересчитайте под свой рынок.

Гостиная доминирует. Более 90% домохозяйств США используют подключённый телевизор (connected TV – телевизор с интернетом, Smart TV или стриминговое устройство) хотя бы раз в месяц, и около 82% телесмотрящих домохозяйств владеют Smart TV (Hub Entertainment Research, 2025). Стриминг – это около 44% всего времени телесмотрения, и примерно 70% взрослых в США первым делом тянутся к стримингу (Nielsen и отраслевые данные, 2025–2026). Если ваш контент смотрят как телевизор – долгими сессиями, откинувшись назад, – экран телевизора не опционален.

Внутри гостиной рынок платформ концентрирован. На апрель 2026 Roku OS занимала около 28%, а Samsung Tizen – около 23% использования платформ connected TV в США; Amazon Fire TV, LG webOS и Vizio SmartCast – в среднем эшелоне, а Apple tvOS, игровые консоли и Android TV – меньшие доли (Parks Associates, Streaming Video Tracker, апрель 2026). Две платформы – Roku и Samsung – это примерно половина аудитории гостиной. Эта концентрация – подарок для планирования: Roku, Samsung плюс Fire TV и LG дают вам бо́льшую часть охвата гостиной в четырёх сборках.

Мобильные и веб остаются необходимыми для регистрации, поиска контента и просмотра в дороге, даже когда основное время просмотра приходится на телевизор. На телефонах подписываются, ищут и кастуют; в вебе оказываются по маркетинговой ссылке и обходят комиссию магазина. Поэтому реалистичный набор запуска для потребительского сервиса в США редко «только ТВ» или «только мобайл» – это небольшой охватывающий набор по обоим.

Рисунок 2. Охват против трудозатрат. Каждая платформа – по охвату аудитории (вертикаль) против трудозатрат на разработку и поддержку (горизонталь). Высокий охват при меньших затратах (веб, iOS, Android) – обычный эшелон запуска; высокий охват при высоких затратах (Roku, Samsung, Fire TV, LG) – следом; консоли в хвосте.
Рисунок 3. Доля платформ connected TV в США, 2026. Roku (28%) и Samsung Tizen (23%) лидируют; Fire TV, LG webOS и Vizio – в среднем эшелоне, tvOS, Android TV и консоли меньше (Parks Associates, апрель 2026). Покрытие топ-4 захватывает бо́льшую часть охвата гостиной.

Сторона трудозатрат: почему ТВ-платформы дороже

Охват говорит, где быть; трудозатраты – сколько это стоит. Три силы делают ТВ-платформы дороже мобайла и веба.

Фрагментация внутри платформы. «Приложение для Samsung» – это не одна цель. Samsung каждый год выпускает новые модели на новых тулчейнах, а старые модели живут в домах десятилетие. Конкретный пример 2026 года: модели Samsung 2026 перешли на новый компиляторный тулчейн (GCC 14.2.0 вместо 9.2.0), поэтому бинарники, собранные для старых телевизоров, нужно пересобирать и перетестировать под новое поколение (документация Samsung Developer, 2026 – перепроверяйте по году модели). Вы поддерживаете не одно приложение Samsung, а его на нескольких годах железа.

Сертификация и проверка в сторе. У каждой ТВ-платформы своя очередь публикации и сертификации – Roku, Samsung, LG, Amazon, Apple – со своими правилами, тестами и сроками. Багфикс, выходящий в веб за час, может проходить ТВ-сертификацию днями. Умножьте на число платформ – и сертификация становится постоянным налогом на каждый релиз.

DRM и особенности устройств. Один и тот же зашифрованный поток может вести себя по-разному на разных версиях Tizen, потому что реализации Widevine и PlayReady различаются по прошивке (Bitmovin, анализ DRM на Tizen, 2025). Изменение PlayReady на Samsung 2026 – канонический пример датированной, специфичной для устройств миграции DRM, которую нужно отслеживать; ей посвящена отдельная статья. Поэтому QA для Smart TV – это задача с лабораторией реальных устройств, а не только с симулятором: нужно живое железо разных годов.

Пройдём арифметику стоимости один раз, чтобы компромисс стал конкретным. Допустим, одна платформа стоит, очень грубо, 1 единицу труда на разработку и 0,3 единицы в год на поддержку (сертификация, обновления ОС, тестирование устройств). Запуск на шести платформах (веб, iOS, Android, Roku, Samsung, Fire TV) – это около 6 единиц на разработку и 6 × 0,3 = 1,8 единицы в год только чтобы держать всё работающим, ещё до единственной новой функции. Добавьте LG, Apple TV и Android TV – и вы около 9 единиц разработки и 2,7 единицы поддержки в год. Удивляет команды именно строка поддержки, а не разработки: матрица – это повторяющиеся расходы, как egress CDN, а не разовый проект. Закладывайте это в модель стоимости OTT с первого дня.

Стратегия, укрощающая матрицу: общее ядро плеера

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

Что входит в общее ядро: политика переключения ABR (какое качество выбирать), управление буфером, аналитические маяки, питающие ваши дашборды QoE, правила восстановления после ошибок, оркестрация запросов лицензий DRM и вызовы бэкенда за каталогом, правами доступа и рекомендациями. Что остаётся нативным на платформе: сама поверхность декодирования видео (AVPlayer, ExoPlayer, плеер Roku), экранный UI и обработка пульта или касаний.

Паттерн – «один мозг, много тел». Несколько коммерческих плеерных SDK (например, THEOplayer и Bitmovin) продают именно это – одно ядро плеера, лицензируемое на веб, мобайл и Smart TV, – меняя лицензионную плату на куда меньший объём кода по платформам. Open-source путь (Shaka Player в вебе и на ТВ плюс нативные плееры на мобайле) не стоит лицензии, но требует больше интеграционной инженерии. В любом случае цель проектирования одна: написать стриминговый интеллект один раз.

Поэтому матрица устройств – это не одиннадцать равных проектов. С общим ядром предельная стоимость ещё одной платформы – это в основном UI-оболочка, её DRM и сертификация, а не стриминговый движок. Архитектуру детально разбирает статья про единую стратегию плеера; здесь вывод – решить «ядро против оболочки» до первого приложения, потому что внедрять это позже значит переписать все.

Рисунок 4. Один мозг, много тел. Общее ядро плеера (ABR, буфер, оркестрация DRM, аналитика) питает тонкие нативные оболочки по платформам, заменяя одиннадцать независимых кодовых баз и снижая предельную стоимость каждой новой платформы до её UI и DRM.

Частая ошибка: строить под демо, а не под аудиторию

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

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

Обоснованный порядок запуска

Совместив охват и трудозатраты, получаем последовательность, подходящую большинству новых потребительских OTT-сервисов в 2026. Считайте её настройкой по умолчанию, а не законом.

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

Эшелон гостиной, по доле: сначала Roku и Samsung (вместе около половины аудитории connected TV в США), затем Amazon Fire TV (на базе Android, переиспользует вашу работу по Android) и LG webOS. Apple TV (tvOS) переиспользует значительную часть инвестиций в iOS и встаёт естественно, если аудитория смещена к Apple. Android TV / Google TV переиспользует Android.

Специализированный эшелон, только если того требуют данные: игровые консоли, операторские приставки, авто. Они дороги, малодольны и редко оправданы на запуске.

Если ваш сервис – B2B, корпоративный или e-learning, а не массовое развлечение, порядок смещается к вебу и мобайлу и может вовсе пропустить гостиную – именно поэтому порядок следует за вашей аудиторией, а не за шаблоном.

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

Клиентская матрица – это задача масштаба и поддержки прежде, чем задача кода: вопрос не «сможем ли мы сделать приложение для Roku», а «сможем ли держать десять приложений одинаковыми на годах устройств, не дав строке поддержки съесть дорожную карту». Фора Софт с 2005 года строит приложения для видеостриминга, OTT/интернет-ТВ, e-learning, телемедицины и видеоконференций – 250+ проектов для 400+ клиентов за 20+ лет – на вебе, iOS, Android, Smart TV и стриминговых устройствах, с общими ядрами плеера, питающими нативные оболочки, так что новая платформа стоит своего UI и DRM, а не нового стримингового движка. Мы вендор-нейтральны: помогаем выбрать платформы запуска по вашей аудитории и бюджету и проектируем матрицу устройств под ту конкурентность и регионы, которые вы реально обслуживаете, а не продаём фиксированный стек.

Ключевые выводы

  • Каждый экран – отдельное приложение; «сделать OTT-приложение» = шесть–десять сборок.
  • На платформе различаются три вещи: язык, видеоплеер и требуемый DRM.
  • DRM решает устройство – Widevine, PlayReady или FairPlay; покройте все три.
  • Гостиная доминирует: Roku (28%) и Samsung (23%) – ~половина connected TV в США.
  • Smart TV дороже всех: фрагментация, сертификация и особенности DRM повторяются.
  • Стройте общее ядро плеера с тонкими нативными оболочками – решите это до первого приложения.

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

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

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