Разработка кроссплатформенных приложений для аудио- и видеостриминга в 2026 году

Почему этот гайд написала Фора Софт

Кроссплатформенный видеостриминг — это задача «выпусти отдельно под каждую платформу», которая маскируется под обещание «сделай один раз». Фора Софт выпустила BrainCert на вебе, iOS, Android и tvOS — это более 100 тысяч клиентов, свыше 500 млн минут просмотра и практика стриминговых решений, накопленная за 21 год доставки мультимедиа. Каждый баг кодека, каждая особенность DRM и каждое подвисание кадра в плеере из этого гайда когда-то стоили нам сдвига сроков релиза или тихого оттока пользователей, который приходилось вылавливать и чинить.

Ловушка в том, чтобы считать, будто «кроссплатформенный SDK» решает задачу кроссплатформенного стриминга. Это не так. iOS не декодирует H.265 аппаратно на устройствах старше iPhone 8; устройства Android ниже Pie не заявляют поддержку Widevine L1; hls.js в вебе не умеет работать с DRM-контентом без дополнительного кода; у смарт-ТВ нет единого стандарта для субтитров IMSC. Единое воспроизведение требует понимать, на какой платформе вы находитесь, и выстраивать условную логику — для каждой функции.

Этот гайд охватывает пять слоёв кроссплатформенного стриминга: поддержку кодеков по устройствам, плееры и их особенности, DRM по платформам, системные интеграции (фоновое воспроизведение/PiP/AirPlay) и выбор между нативной разработкой, Flutter, React Native и KMP. Мы опираемся на платформы, под которые вы реально выпускаете продукт: iOS 13+, Android 8+, веб (Chrome/Safari), tvOS и Tizen.

Кроссплатформенная реальность — что на самом деле поддерживает каждая платформа

Нет двух платформ, которые декодируют видео одинаково. Вот как выглядит базовый уровень 2026 года для iOS, Android, веба и ТВ:

Плееры — какой использовать на каждой платформе

Универсального SDK видеоплеера не существует. У каждой платформы есть нативный движок или популярная open-source-альтернатива, и у них разная логика ABR, настройка буфера и обработка ошибок.

AVPlayer (iOS / tvOS)

Что это. Нативный HLS-движок Apple. Доступен автоматически на iOS 8+. Отличное аппаратное декодирование H.264/H.265; DRM FairPlay встроен; задержка старта 2–3 секунды на хороших сетях.

Слабые места. Зависает на повреждённых сегментах (без восстановления); не отдаёт состояние ABR (рендицию приходится угадывать по логам битрейта); нет поддержки DASH без кастомного парсинга; разброс длительности сегментов ломает синхронизацию.

ExoPlayer (Android)

Что это. Open-source-плеер Google для DASH/HLS/SmoothStreaming. Нативная поддержка DASH; встроенная поддержка Widevine L1/L3; старт примерно за 1,5 секунды на 4G; экономичный по CPU ABR.

Что важно знать. Widevine L3 на бюджетных устройствах означает, что без отдельного DRM-лицензирования офлайн-загрузки невозможны; разброс длительности сегментов может вызывать дрейф синхронизации; отчёты о пропущенных кадрах «шумят» на слабом железе; для 3G нужна тщательная настройка буфера.

hls.js (веб)

Что это. Чистый JavaScript-парсер HLS и плеер на MSE. Без внешних зависимостей; работает в любом браузере с поддержкой Media Source Extensions; ABR подключается модульно.

Подводные камни. Нет нативной поддержки DRM; для Widevine нужна обёртка вроде dash.js или кастомная EME-прослойка. Поддержка Safari слабая (там лучше использовать нативный HLS). Высокое потребление памяти на 4-часовых потоках.

Shaka Player (веб / нативный DASH)

Что это. Open-source-плеер Google для DASH в вебе. Встроенный DRM Widevine; офлайн-воспроизведение через IndexedDB; старт 1,5–2 секунды на широкополосном подключении.

Компромисс. Поддержка HLS второстепенна (нужен отдельный плагин); Safari не поддерживается (используйте нативный плеер); DRM по HTTP требует кастомной HTTPS-прослойки.

Поддержка кодеков по устройствам и годам — собираем лестницу рендиций

Правило 1: всегда отдавайте H.264. Он есть в каждом устройстве, выпущенном после 2010 года, и к 2026-му у него нет патентных троллей. Запасная рендиция, тихая гавань.

Правило 2: H.265 зависит от устройства. iPhone 6s+ (2015) и современные Android (Snapdragon 835+, 2017) декодируют H.265 аппаратно. Среднебюджетные Android не умеют (например, Snapdragon 665). Браузеры не поставляют H.265 из-за патентного лицензирования. Не считайте, что H.265 экономит трафик у всех зрителей.

Правило 3: AV1 — это 2026 год, но с оговорками. iOS 17+ декодирует AV1 программно (расход батареи); Android 13+ (Pixel 6+, Samsung S24) декодируют аппаратно. В вебе Chrome/Firefox имеют аппаратный AV1 на новых GPU. AV1 экономит 20–30% трафика по сравнению с H.264 при том же качестве, но нагрузка на CPU старых устройств съедает эту экономию.

Рекомендуемая лестница на 2026 год. 240p, 360p, 480p, 720p, 1080p в H.264 (обязательно). Добавьте 720p, 1080p, 2160p в H.265 для iOS 10+ и Android 8+ (опционально, в зависимости от экономии). Добавьте 480p, 720p в AV1 для Chrome 90+ и iOS 17+ (опционально, проверьте влияние на батарею).

DRM по платформам — FairPlay, Widevine, PlayReady и пробелы между ними

FairPlay (iOS / tvOS / Safari). Проприетарный DRM Apple. Требует выданного Apple сертификата FairPlay (бесплатно, но процесс ручной). Стандарта лицензионного сервера нет; токен-аутентификацию вы строите сами. Лимиты сессий жёсткие (6 одновременных сессий воспроизведения на устройство). Офлайн-загрузки невозможны без кастомной обработки.

Widevine (Android / Chrome / Firefox). DRM от Google. Три уровня защиты: L3 (программное дешифрование, все Android-устройства), L2 (частично аппаратный, встречается редко), L1 (полностью аппаратный, флагманы). L3 на старых устройствах означает, что потоки не помечаются watermark и их можно записать. Лицензионный сервер должен быть лицензирован для Widevine (Axinom, EZDRM, BuyDRM, Azure Media Services). Офлайн-загрузки работают только на L1.

PlayReady (Tizen / Roku / Xbox). DRM от Microsoft, в первую очередь для ТВ. Охватывает около 5% зрителей мира, но обязателен для лицензионного контента на ТВ. Развёртывание лицензионного сервера сложное; большинство платформ предоставляют референсный сервер (Tizen.PlayReady, приватный API Roku). Браузерный PlayReady существует, но встречается нечасто.

CMAF-CBCS как объединяющий слой. Шифрование на уровне сегментов по CBCS (Cipher Block Chaining с зашифрованными границами сэмплов) позволяет зашифровать один раз и отдавать FairPlay + Widevine + PlayReady из одних и тех же сегментов. Это избавляет от двойной перекодировки и вдвое сокращает объём хранения по сравнению с устаревшим подходом (отдельный AES-128 CBC для HLS и отдельный DASH cenc для DASH).

WebRTC на разных платформах — пробелы libwebrtc и особенности платформ

libwebrtc — это единая кодовая база, но не единое поведение. Google публикует исходники WebRTC; каждая платформа оборачивает и дорабатывает их. iOS использует пайплайн кодеков AVFoundation; Android — MediaCodec; Chrome — кодек-стек уровня ОС; у Safari нет libwebrtc (используется нативный WebRTC API). Это значит, что баг кодека на Android незаметен на iOS.

WebRTC в Safari (состояние на 2026 год). Нет шеринга экрана на iOS (ограничение Safari); нет Insertable Streams (для E2EE нужен кастомный SFU); синтаксис SDP unified-plan не полностью поддерживается до Safari 16+; видеоограничения частично игнорируются (разрешение камеры выбирает ОС).

Конфликты Android camera2 API. Некоторые ODM-производители устройств открывают сразу два API — Camera (устаревший) и Camera2. libwebrtc по умолчанию использует Camera2, но на устройствах с багами camera2 (например, у некоторых OEM Xiaomi) приходится откатываться на Camera. Автоматического определения нет; нужен allowlist под конкретные устройства или логика отката в рантайме.

Ограничения фонового режима в iOS. Аудио WebRTC остановится, если приложение уходит в фон без entitlement на фоновое аудио. Entitlement требует ревью Apple и обоснования; «фоновые видеозвонки» одобряют, «фоновый музыкальный стриминг» нередко отклоняют.

ABR и буферизация — настройка под каждый плеер и платформу

ABR в AVPlayer непрозрачен. Он переключает рендиции по внутренним эвристикам, которые вы не можете полностью контролировать. Переопределяйте через preferredPeakBitRate, но плеер может вас проигнорировать, если решит, что буферизация вот-вот начнётся. Следите через KVO за currentItem.accessLog.events и логируйте паттерн смены рендиций; он вас удивит.

ABR в ExoPlayer настраиваемый. DefaultLoadControl позволяет задать минимальный/максимальный порог буфера, минимальный битрейт для буферизации, параметры оценки полосы пропускания. Для 3G установите целевой буфер на 8–15 секунд (вместо стандартных 30+); для оптоволокна — 45–60 секунд. Тестируйте на реальных устройствах; в эмуляторе полоса пропускания ненастоящая.

ABR в hls.js детектирует джиттер сети. Он считает потери пакетов и RTT, чтобы определить нижнюю границу рендиции. На нестабильном Wi-Fi (потери > 2%) он фиксируется на 480p, пока сеть не стабилизируется. Для UX это хорошо, но пользователям может казаться, что картинка «застряла». Дайте в настройках ручную фиксацию битрейта.

Правила буферизации по платформам. Уход iOS в фон сбрасывает буфер (закладывайте задержку повторного старта < 3 с). Android может удерживать буфер при паузе приложения, но лицензии Widevine L3 истекают, если устройство спит > 3 минут. Готовьтесь перестраивать буфер при возобновлении.

Нативная разработка vs Flutter vs React Native vs KMP — когда что подходит для стриминга

Нативная разработка (Swift / Kotlin). Плюсы: полный доступ к AVPlayer, ExoPlayer, настройке ABR на платформе, DRM API, фоновому аудио, PiP, AirPlay/Cast. Минусы: выпускать приходится дважды; время сборки примерно на 30% больше. Стриминговые приложения с высоким оттоком — лайв-шопинг, спорт, репетиторство — выпускают нативно, потому что баги QoE стоят выручки в реальном времени.

Flutter. Плюсы: единая кодовая база; hot reload. Минусы: воспроизведение HLS/DASH требует platform channel к ExoPlayer/AVPlayer (связующий слой на вас). Аудиофокус, работа в фоне, инициализация DRM — всё это требует кастомных мостов на Kotlin/Swift. На масштабе BrainCert мы обнаружили, что баги видеомоста Flutter стоят 2–3 недель QA на каждый релиз; выпускайте нативно.

React Native. Плюсы: переиспользование JS-логики из веба. Минусы: видеобиблиотеки RN (react-native-video, react-native-exoplayer) отстают по паритету функций от платформ на 6–12 месяцев. DRM, субтитры, кастинг — всё это платформенные дополнения. Если вы выбираете RN, закладывайте 4–6 месяцев только на видеоинфраструктуру.

Kotlin Multiplatform (KMP). Развивающийся вариант: общая бизнес-логика, нативный UI. Для стриминга это значит общий парсинг манифестов, состояние ABR, логику DRM-токенов, но плееры остаются нативными. Инструментарий пока ранний; на масштабе ещё не закалён в продакшене.

Apple TV, Android TV, Tizen, Roku и стриминг на консолях

tvOS (Apple TV). Использует тот же AVPlayer, что и iOS; нативный HLS. Нужны отдельная иконка приложения под ТВ (1920x1080 @ 32 бита) и удобный для пульта focus engine. Нет поддержки Bluetooth-наушников для фонового аудио. Поддержка HDR (если кодек позволяет) включается автоматически.

Android TV / Google TV. Использует ExoPlayer. Интеграция с протоколом Cast (Chromecast) опциональна, но пользователи её ждут. Тайминговые метаданные (реклама, главы) передаются через EMSG-боксы в HLS или EventStream в DASH. Приложение должно пройти сертификацию для ТВ (безопасные для ТВ шрифты, навигация пультом) до одобрения в Google Play.

Tizen (Samsung TV). Проприетарная ОС. Использует Tizen Player или кастомный HLS/DASH через AVPlay API. Предпочтителен DASH (поддержка PlayReady); HLS как запасной вариант обязателен. Поддержка субтитров зависит от SDK; парсинг WebVTT не гарантирован. Тестируйте на реальных устройствах Tizen; эмулятор неполный.

Roku. Закрытая платформа. Кастомный нативный SDK или веб-плеер (SceneGraph). По умолчанию DASH + PlayReady; HLS как запасной вариант ожидаем. Управление пультом основано на жестах (мыши нет). Монетизация (реклама, биллинг) только через Roku; встроенные покупки Apple использовать нельзя.

Приложения на консолях (Xbox, PlayStation). PlayStation использует Orbis OS; Xbox — систему на базе Windows. Обе ждут нативных SDK или Electron-обёрток. DRM зависит от платформы (PlayReady на Xbox, проприетарный на PS5). Рынок небольшой (1–2% зрителей), но с высокой вовлечённостью (геймеры смотрят дольше).

Фоновое аудио, «картинка в картинке», AirPlay и интеграции с Cast

Фоновое аудио (iOS). Требует категории AVAudioSession .playAndRecord или .playback + entitlement. AVPlayer это учитывает; потоки продолжаются, когда приложение в фоне. Нужны явная запись в plist и обоснование для App Store (видеозвонки, аудиостриминг, подкасты одобряют; «разблокировку музыки» отклоняют).

«Картинка в картинке» (PiP). iOS 13+: используйте AVPlayerViewController с canStartPictureInPictureAutomatically = true. Android: ExoPlayer 2.16+ имеет нативный PiP через PictureInPictureParams. Веб: Fullscreen API не включает настоящий PiP (на некоторых плеерах есть кнопка от браузера, например в hls.js 1.4+).

AirPlay (экосистема Apple). AVPlayer автоматически обнаруживает приёмники с поддержкой AirPlay (Apple TV, HomePod, AirPods). Дополнительный код не нужен; просто покажите кнопку маршрута AVPlayerViewController. Кастинг работает по локальной сети; на iOS 14+ требуется entitlement Local Network.

Chromecast (экосистема Google). Требует Google Cast Framework (на Android) или Cast Sender SDK (в вебе). ExoPlayer 2.17+ имеет встроенную интеграцию с Cast; hls.js требует кастомной обёртки cast.js. Кастинг ставит локальное воспроизведение на паузу и переключает поток на приёмник Chromecast (отдельное приложение); синхронизация не гарантируется.

Доступность и субтитры — WebVTT, CEA-608 и IMSC1

WebVTT (стандарт HLS + веб). Текстовый формат субтитров; sidecar-файл в HLS-манифесте. Работает в AVPlayer (iOS), ExoPlayer (Android с плагином) и нативном <video> (веб). Без стилизации сверх базового выравнивания. Безопасный универсальный выбор.

CEA-608 (наследие вещания, встроено в видео). Скрытые субтитры в видеопотоке. Обязательны для эфирного вещания в США (требование FCC). AVPlayer разбирает CEA-608 автоматически; ExoPlayer требует плагин subriploader. Поддержка sidecar в tvOS слабая; на Apple TV планируйте субтитры вручную.

IMSC1 (DASH + стилизация для вещания). Богатая разметка (жирный, курсив, цвет, позиционирование). Соответствует спецификации DASH. У ExoPlayer ограниченная поддержка IMSC; AVPlayer не разбирает IMSC нативно. У браузеров нет стандартного парсера IMSC; нужна кастомная JavaScript-библиотека (ttml.js, niels-in-xsd). У Tizen/Roku есть свои вендорные парсеры.

Доступность за пределами субтитров. WCAG 2.1 уровня AA требует навигации с клавиатуры (веб), метаданных для экранных дикторов (VoiceOver на iOS, TalkBack на Android) и контраста цвета 4,5:1 для текста субтитров. Большинство стриминговых плееров не отдают состояние медиа вспомогательным технологиям (assistive technology); тестируйте с VoiceOver и TalkBack до релиза.

Тестирование и QA для кроссплатформенных стриминговых приложений

Лаборатории устройств. Кроссплатформенное видео невозможно протестировать без реальных устройств. Сервисы вроде BrowserStack, Sauce Labs и AWS Device Farm дают время на физических устройствах с реальными сетевыми условиями. Заложите 2–3 недели на подготовку тест-плана (сетевые профили для 4G, 3G, нестабильного Wi-Fi, 5G-домашнего интернета) и прогон каждой комбинации кодек/DRM/плеер.

Критичные сценарии для тестов. Переключение ABR (понижение битрейта при потере пакетов), ротация DRM-лицензий (каждые 60 минут на Widevine L3), восстановление после повреждения сегмента, вход/выход из PiP, подключение/отключение AirPlay/Cast, включение/выключение субтитров, уход в фон/возобновление и смена ориентации (с портретной на альбомную во время воспроизведения).

Что можно автоматизировать. Эмулируйте медленные сети (NetCat на iOS, tc qdisc на Android, Charles Proxy в вебе). Внедряйте ошибки сегментов (возвращайте 404 или 500 для сегмента N) и измеряйте время восстановления. Отслеживайте утечки памяти на 4-часовом воспроизведении (Instruments на iOS, Android Profiler на Android, Chrome DevTools в вебе).

Мини-кейс — BrainCert работает на масштабе на вебе, iOS, Android и tvOS

Задача. BrainCert нужно было приложение виртуального класса для репетиторства (видеозвонки 1:1, доска, запись), которое работало бы и на iPad в лекционных залах (100 пассивных зрителей на HLS), и на iPhone в дороге (плохой Wi-Fi, критичный заряд батареи). То же приложение на Android должно было справляться с Widevine L3 и китайскими устройствами с нестандартными реализациями mediacodec. В вебе всё должно было работать в Chrome и Safari без паритета кодеков.

Что мы сделали. Нативные iOS и Android; выделенная команда на каждую платформу. AVPlayer + CMAF-CBCS для iOS (рендиции H.264 + H.265); ExoPlayer + Widevine + запасная рендиция только в H.264 для бюджетных Android-телефонов. Веб: hls.js для Chrome (HLS через CMAF), нативный <video> + hls.js для Safari. Субтитры через sidecar WebVTT (универсальный запасной вариант). Фоновое аудио включено для сессий репетиторства.

Результат. Более 100 тысяч клиентов, свыше 500 млн минут занятий, TTFF в 95-м перцентиле < 2,5 с на всех платформах. Хотите похожую оценку для своего стека? Позвоните нам или напишите — разберём вашу стратегию по платформам.

Схема принятия решения — пять вопросов, чтобы оценить кроссплатформенный проект

В1. Вам нужен лайв-интерактив (WebRTC) или вещание (HLS/DASH)? Интерактив → нативный Swift/Kotlin, закладывайте бюджет на платформенные особенности libwebrtc. Вещание → нативные плееры (AVPlayer, ExoPlayer), паритет между платформами достигается проще.

В2. Нужен ли DRM для лицензионного контента? Да → мульти-DRM с первого дня (FairPlay + Widevine + PlayReady, если есть ТВ); упаковка в CMAF-CBCS. Нет → отдавайте только запасную рендицию H.264, без DRM-инфраструктуры.

В3. Какая у вас минимальная версия iOS/Android? iOS 13–16 → только H.264; поддержка H.265 опциональна. iOS 17+ → добавьте AV1 (проверьте влияние на батарею). Android 8–12 → H.264 обязателен; H.265 зависит от устройства. Android 13+ → добавьте VP9/AV1 для современных устройств.

В4. Опытна ли ваша команда в нативных видеофреймворках? Да → нативное приложение. Нет → наймите специалистов или возьмите выделенную команду; избегайте видеомостов RN/Flutter, если у вас нет 6+ месяцев на освоение.

В5. Нужны ли фоновое воспроизведение, PiP или кастинг? Да → только нативно (platform channels во Flutter/RN сложны). Нет → кроссплатформенные инструменты жизнеспособны, если поддержка кодеков простая (только H.264).

Ошибки, которых стоит избегать при выпуске кроссплатформенного видео

1. Считать, что кроссплатформенные обёртки сами разберутся с детектированием кодеков. Не разберутся. Опрашивать каждую платформу нужно в рантайме; название устройства и версия ОС — ненадёжные ориентиры. Xiaomi на Android 12 может не декодировать H.265, тогда как Poco с той же ОС — декодирует.

2. Откладывать DRM на вторую или третью версию. Докрутка DRM — это 4–6 недель на платформу. Стройте CMAF-CBCS с первого дня; подпись манифеста и лицензионный сервер переносимы между платформами и переиспользуются навсегда.

3. Тестировать сетевые условия на симуляторах. Полоса пропускания в симуляторе iOS ненастоящая; эмулятор Android голоден до CPU и будет ронять кадры, которые реальные устройства проигрывают плавно. Тестируйте на реальных 4G/3G через лабораторию устройств; проектируйте под худший RTT и потери пакетов 2–5%.

4. Выпускать без согласованного scope для entitlement фонового аудио. Вы получите отказы Apple прямо во время запуска, если заявите фоновое аудио, но используете его для музыкального стриминга (отклоняют) вместо видеозвонков (одобряют). Сначала спросите Apple, получите письменное одобрение, а потом выпускайте.

5. Использовать один формат субтитров на всех платформах. WebVTT работает везде, кроме Tizen/Roku и некоторых ТВ-платформ. Проектируйте субтитры как sidecar WebVTT + запасной CEA-608 или IMSC1 под платформу; не зашивайте намертво один формат.

KPI — что измерять, когда ваше кроссплатформенное приложение запущено

KPI качества. TTFF по платформам (iOS < 1,5 с, Android < 2 с, веб < 2 с), доля ребуферизации < 1% по платформам, средняя рендиция по кодеку (H.264 vs H.265 vs AV1), доля пропущенных кадров на Android < 2%. Разбивайте эти метрики по типу сети (4G, Wi-Fi, 3G) и классу устройства (флагман, средний сегмент, бюджет). Один тихий убийца: средняя рендиция падает на 20% неделя к неделе на одной платформе (признак: откат кодека или баг плеера).

Бизнес-KPI. Удержание по перцентилю QoE (у сессий с TTFF > 3 с удержание на 40% ниже); время просмотра по платформам (когда на iOS смотрят дольше, чем на Android, — это норма; когда на Android дольше, чем на iOS, — это баг плеера). Стоимость на час просмотра по кодеку (H.265 экономит 30–40% на egress по сравнению с H.264).

KPI надёжности. Доля успешных стартов потока > 99% на платформу, частота ошибок по типу (сбои переключения ABR, таймаут DRM-лицензии, 404 на сегменте) и доля сбоев < 0,1% (измеряется на сборку приложения, а не на платформу). Отслеживайте лимиты сессий Widevine L3; если вы видите ошибки лицензии на одном устройстве снова и снова, вы упёрлись в потолок из 6 одновременных сессий.

Когда не стоит идти в кроссплатформенное видео

Видео — это функция, а не продукт. CRM со встроенными видеозвонками должна использовать SDK Daily или Twilio, а не строить кастомный плеер. Сложность кроссплатформенного видео не оправдана ради одной кнопки звонка.

У вас нет специалиста по видео. Кроссплатформенное видео требует человека, который знает особенности кодеков, развёртывание DRM и платформенные API плееров. Нанять или привлечь такую экспертизу дешевле, чем учиться на ходу и выпускать сломанное видео для половины пользователей.

Ваша цель — одна платформа (например, iPad для бизнеса, Chrome для веб-only SaaS). Делайте нативно под эту платформу. Сложность растёт линейно; одна платформа на 100% проще двух.

Частые вопросы

Почему AV1 экономит трафик не на всех устройствах?

AV1 эффективнее H.264 по битрейту на 20–30%, но декодирование нагружает CPU. На iOS 16 и старше аппаратного декодера AV1 нет; программное декодирование тратит дополнительные 15–25% заряда батареи в час. На Android аппаратная поддержка AV1 зависит от устройства (Pixel 6+, S24, Snapdragon 8 Gen 1+). Проверяйте AV1 на расход батареи до релиза; для большинства пользователей H.265 — лучший выбор.

В чём разница между Widevine L1 и L3?

L1 расшифровывает ключи в защищённом анклаве (TEE); поток никогда не виден в RAM. L3 расшифровывает программно; открытый ключ доступен ОС. L3 на бюджетных Android-устройствах означает, что потоки можно записать через захват экрана. Если нужна защита уровня студии — только L1, но спроектируйте откат на незащищённый (DRM-free) контент для L3-устройств, иначе вы закроете доступ половине Android.

Можно ли использовать React Native для стримингового приложения в 2026 году?

Да, если вы принимаете, что видеослой не «кроссплатформенный» — видеомосты на Kotlin и Swift вам всё равно придётся писать. react-native-video отстаёт от функций платформ на 6–12 месяцев. Закладывайте 4–6 месяцев на видеоинфраструктуру; экономия на коде приложения реальна, но сложность слоя плеера остаётся нативной.

Как протестировать поддержку кодеков, не покупая каждое устройство?

Лаборатории устройств (BrowserStack, Sauce, AWS Device Farm) дают доступ к сотням физических устройств. Для тестирования матрицы кодеков возьмите в аренду 20–30 устройств (3 iPhone, 5 Android, 3 браузера, ТВ при необходимости) и прогоните часовые потоки на каждом. Стоимость: около 150 тыс. ₽ за полный прогон тестов; планируйте за 2–3 недели до запуска.

Что будет, если устройство пользователя не поддерживает кодек из моего манифеста?

Плеер запросит манифест, разберёт его, не найдёт проигрываемой рендиции и выдаст ошибку. Предотвратите это, всегда включая рендицию H.264 как запасную. Если вы отдадите только H.265 или AV1, 10–20% пользователей увидят ошибку «видео недоступно» и уйдут.

CMAF — это то же самое, что DASH?

Нет. CMAF — это формат упаковки (фрагментированные MP4-сегменты с опциональным шифрованием). DASH — это протокол (манифест + URL сегментов). CMAF можно упаковать как HLS (через HTTP Live Streaming), как DASH (через манифест MPEG-DASH) или как оба сразу. CMAF + шифрование CBCS позволяют одному набору сегментов отдавать HLS, DASH и DASH-CMAF.

Зачем нужен отдельный чек-лист по субтитрам для каждой платформы?

У каждой платформы свои рендереры субтитров и уровни поддержки. AVPlayer на iOS разбирает WebVTT нативно; ExoPlayer на Android требует плагин SubtitleProvider; <video> в вебе поддерживает WebVTT в тегах <track>; у Tizen/Roku свои вендорные парсеры. Планируйте WebVTT как универсальный запасной вариант; добавляйте платформенно-нативные форматы (CEA-608 на iOS/tvOS, IMSC1 на DASH) ради лучшего UX.

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

Готовы выпустить кроссплатформенное стриминговое приложение, которое работает везде?

Кроссплатформенное видео — это матрица кодеков (запасной H.264 + рендиции H.265 и AV1), матрица плееров (AVPlayer + ExoPlayer + hls.js + Shaka), матрица DRM (FairPlay + Widevine + PlayReady) и матрица функций (фоновое аудио, PiP, субтитры, доступность). Ошибитесь в одной матрице — и 30–50% ваших зрителей тихо уйдут.

Фора Софт выпустила полную матрицу на BrainCert и шести других продуктах за 21 год. Мы знаем, какая платформа становится узким местом для качества, где обещания кроссплатформенных SDK дают трещину и когда натив побеждает фреймворк. Если вы планируете стриминговое приложение, мигрируете между платформами или чините QoE на одной из них, самый быстрый путь к надёжной архитектуре — это разговор с нашей командой.

Позвоните нам или напишите — и мы сопоставим ваши конкретные требования по кодекам, плеерам и DRM с целевыми платформами, дав сроки выпуска и модель стоимости для каждого варианта.