Воспроизведение видео на iOS и Android: плеер, DRM

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

Коротко

Телефоны и планшеты – это экраны, на которых происходит большая часть OTT-просмотра, и две мобильные платформы имеют полностью раздельные стеки воспроизведения: Apple iOS использует встроенный плеер AVPlayer, нативно играет только формат HLS и защищает контент через FairPlay, а Google Android использует движок ExoPlayer внутри библиотеки Jetpack Media3, играет HLS и DASH и защищает контент через Widevine. Хорошая новость одна – конвергенция: если зашифровать видео один раз по схеме cbcs стандарта Common Encryption, те же файлы открываются под FairPlay на iOS и под Widevine на Android, так что пакет вы собираете один раз, а лицензию выдаёте под каждую платформу. Офлайн-скачивание – это отдельный второй путь воспроизведения на каждой платформе, со своим API загрузки и своей хранимой лицензией со сроком истечения. Чаще всего команды спотыкаются не о технику, а о политики сторов Apple и Google, которые требуют HLS по сотовой сети и забирают долю с любой подписки, проданной внутри приложения.

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

Для большинства стриминговых сервисов iPhone и Android-телефон – два экрана, которые дают основную долю времени просмотра, и одновременно два экрана, которые решают, выйдет ли приложение вообще, потому что Apple и Google проверяют каждое приложение перед публикацией. Основатель или продакт-менеджер, который считает «мобильное приложение» одной строкой бюджета, столкнётся с сюрпризом: iOS и Android почти не делят код воспроизведения, навязывают разные правила цифровой защиты и накладывают политики сторов, способные переписать вашу цену и ваше кодирование. Эта статья объясняет оба нативных стека простым языком, чтобы вы могли оценить мобильную сборку, проверить SDK вендора, поставить задачу инженерам и обойти две ошибки – шифрование не в той схеме и игнорирование правила стора, – которые тихо топят мобильные запуски. Это мобильный спутник статьи клиентская матрица OTT, которая раскладывает все экраны, что вам нужно покрыть.

Два телефона – два полностью раздельных стека

Начнём с того, что застаёт врасплох каждую новую команду: iPhone и Android-телефон не делят видеоплеер. В вебе можно выпустить один JavaScript-плеер и покрыть большинство браузеров, как мы разбираем в статье про веб-воспроизведение. На мобильных такого ярлыка нет. Каждая платформа поставляет свой движок плеера, говорит на своём предпочтительном формате стриминга и навязывает свою систему защиты от копирования. Вы строите, тестируете и поддерживаете два стека параллельно.

Под «стеком» здесь понимается цепочка частей, которая превращает файл на сервере в движущуюся картинку на стекле: плеер (софт, который качает и декодирует видео), формат стриминга (как видео нарезано на маленькие куски и описано плееру) и система управления цифровыми правами, DRM – замок, который не даёт устройству платящего зрителя копировать премиальный контент. На мобильных все три различаются между Apple и Google. Дальше мы пройдём каждый стек, затем две вещи, которые они делят, – офлайн-скачивание и правила сторов.

Рисунок 1. Два мобильных стека, общего почти нет. Единственная общая ступень – само зашифрованное медиа, если упаковать один раз по схеме cbcs Common Encryption.

iOS: AVPlayer, HLS и FairPlay

На телефонах и планшетах Apple вы почти никогда не пишете видеоплеер с нуля. Операционная система уже включает его – он называется AVPlayer и входит в медиа-фреймворк Apple AVFoundation. Передайте AVPlayer адрес потока, и он скачает поток, прочитает его описание, декодирует видео аппаратно и будет подстраивать качество вверх и вниз по мере изменения сети. Это непрерывное переключение качества называется адаптивным битрейтом (англ. adaptive bitrate, ABR), и получить его бесплатно от системы – главная причина, по которой воспроизведение на iOS в счастливом сценарии проще из двух.

Подвох – в формате. AVPlayer нативно играет ровно один адаптивный формат стриминга: HTTP Live Streaming, или HLS, собственный формат Apple, стандартизированный как IETF RFC 8216. Самостоятельно он не играет другой крупный формат, MPEG-DASH. Если ваш конвейер упаковки выдаёт только DASH, вашему iOS-приложению нечего играть. Поэтому первое правило iOS: вы обязаны выпускать HLS. Как выдавать оба формата из одного набора файлов, мы разбираем в статье упаковка: CMAF, HLS и DASH.

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

Минимальный набросок обвязки FairPlay, иллюстративный, а не продакшен-код:

// Подключаем content-key session для управления FairPlay на HLS-ассете.
let keySession = AVContentKeySession(keySystem: .fairPlayStreaming)
keySession.setDelegate(self, queue: DispatchQueue.main)
keySession.addContentKeyRecipient(asset)   // asset — это AVURLAsset для .m3u8

// В делегате вы получаете key request, формируете запрос лицензии (SPC),
// шлёте его на ваш лицензионный сервер и возвращаете ответ (CKC).
// Никогда не зашивайте реальный ключ в приложение — сервер выдаёт его на сессию.

Android: ExoPlayer, Media3 и Widevine

Android тоже поставляет базовый медиаплеер, но реальные стриминговые приложения его не используют. Стандарт – ExoPlayer, открытый движок плеера от Google. С 2023 года ExoPlayer поставляется внутри семейства библиотек Google Jetpack Media3 (пакет androidx.media3); старая отдельная библиотека объявлена устаревшей и заморожена, поэтому новые работы ведутся на Media3. По состоянию на март 2026 актуальная линия – Media3 1.10. Когда статья говорит «ExoPlayer», имеется в виду движок в составе Media3.

ExoPlayer гибче AVPlayer по формату: он играет HLS, MPEG-DASH, Microsoft Smooth Streaming и обычные прогрессивные файлы. Многие Android-first сервисы стандартизируются на DASH, но раз ExoPlayer играет ещё и HLS, единая Android-кодовая база может потреблять то, что выдаёт ваша упаковка. Плата за эту гибкость – вы собираете и настраиваете плеер сами, а не получаете готовый от системы.

DRM в Android – это Widevine, сделанный Google и встроенный в ОС. ExoPlayer обращается к нему через системный интерфейс защиты контента, API MediaDrm. Вы указываете плееру, какую DRM-систему использовать и где живёт ваш лицензионный сервер, и менеджер сессий ExoPlayer по умолчанию проводит обмен лицензией. Widevine, как и FairPlay, работает на Common Encryption – и вот тут конвергенция экономит реальные деньги.

Два факта о Widevine на Android определяют, что может ваше приложение, и оба взяты из собственной документации Google. Первый – схема шифрования: таблица ниже из руководства Android Media3 по DRM (обновлено 2026-03-09).

Схема WidevineМин. версия AndroidУровень APIПоддерживаемые форматы
cenc (AES-CTR)4.419DASH, HLS (только fMP4)
cbcs (AES-CBC)7.125DASH, HLS (только fMP4)

Схема cbcs – та самая, что нужна и FairPlay, – работает на Android 7.1 (2016) и новее, то есть фактически на каждом активном телефоне в 2026. Именно это делает «упаковку один раз» возможной на обеих платформах.

Второй факт – уровень безопасности. Widevine присваивает каждому устройству уровень безопасности, который управляет максимальным качеством, разрешённым владельцем контента. L1 означает, что ключи и декодированное видео остаются внутри изолированной аппаратной зоны на чипе – доверенной среды исполнения (Trusted Execution Environment, TEE); студии требуют L1 для 1080p и 4K. L3 означает, что защита только программная; владельцы контента обычно ограничивают L3-устройства до 480p или 720p. Флагманский телефон обычно L1; дешёвое или старое устройство может быть L3, и то же приложение получит там меньше качества. Это политика владельца контента, навязанная через DRM, а не баг вашего плеера, – и именно поэтому тайтл, который стримится в HD на одном телефоне, упирается в стандартное разрешение на другом.

Шифруем один раз, лицензируем многократно – единственная общая ступень

Вот в чём выигрыш. Common Encryption – зонтичный стандарт ISO/IEC 23001-7 – определяет две схемы шифрования: cenc (counter mode) и cbcs (cipher-block-chaining с под-сэмплированием). FairPlay принимает только cbcs; Widevine принимает обе, но поддерживает cbcs. Поэтому, если упаковать видео один раз, зашифровав по cbcs, в сегментах fragmented-MP4 (контейнер, который использует современный формат CMAF, ISO/IEC 23000-19), те же зашифрованные файлы играют под FairPlay на iOS и под Widevine на Android. Каталог не шифруется дважды. Вы шифруете один раз и выдаёте разную лицензию под каждую платформу со своего сервера ключей.

Эта схема предотвращает частую ошибку – шифрование только в cenc. Команда пакует под Android, релизит, потом добавляет iOS и обнаруживает, что каждое видео – чёрный экран на iPhone, потому что FairPlay не читает cenc. Лечится это перешифровкой всего каталога, что на крупной библиотеке – дни вычислений и задержка релиза. Решите про cbcs до того, как что-либо зашифруете. Как единый workflow собирается от начала до конца, – тема статьи multi-DRM: один workflow, все устройства; детали схем – в CENC, CTR и CBCS.

Рисунок 2. Матрица покрытия мобильных. Читайте столбец, который оцениваете; зелёные ячейки – то, что платформа поддерживает нативно.

Заметка о кодеках: что умеет декодировать чип

Выбор формата стриминга – не то же, что выбор кодека, метода сжатия, который ужимает видео, такого как H.264, HEVC или AV1. Телефон играет только тот кодек, который умеет декодировать его железо, и карта кодеков зависит от возраста устройства. H.264 играет везде. HEVC (он же H.265) имеет аппаратное декодирование заметно более чем на 95% продаваемых сегодня телефонов. AV1, самый новый и эффективный, декодируется аппаратно только на свежем кремнии: у Apple – iPhone 15 Pro и все iPhone 16 и 17; у Android – чипы вроде Snapdragon 8 Gen 1 и новее, Google Tensor G2 и новее, свежие Samsung и MediaTek, с расширением на средний сегмент в течение 2026. Практическое правило: никогда не давайте устройству rendition, который оно не может декодировать. Внутренности кодеков – это раздел Video Encoding; здесь задача одна – сопоставить лестницу кодирования с декодерами в полях, о чём мы пишем в стратегии кодеков для OTT.

Офлайн-скачивание: отдельный второй путь воспроизведения

Дать зрителю скачать эпизод на самолёт – это не тот же код, что стримить его, ни на одной платформе. Офлайн – это второй путь воспроизведения со своим менеджером загрузок и своей хранимой лицензией.

На iOS HLS-контент скачивают через AVAssetDownloadURLSession и AVAssetDownloadTask, которые тянут сегменты и безопасно хранят их на устройстве. Для защищённого контента вы дополнительно получаете постоянный ключ FairPlay – офлайн-лицензию, которая, в отличие от стриминговой, записывается на диск, чтобы видео играло без сети. На Android DownloadManager ExoPlayer (через DownloadService) тянет медиа, а помощник OfflineLicenseHelper скачивает офлайн-лицензию Widevine, возвращая маленький keySetId, который вы храните и позже отдаёте плееру, чтобы открыть файл.

Цифра, которая удивляет продуктовые команды, – объём хранилища. Посчитаем вслух. Поток 1080p на пяти мегабитах в секунду использует 5 ÷ 8 = 0,625 мегабайта каждую секунду, то есть 0,625 × 3600 ≈ 2250 мегабайт – около 2,25 ГБ – в час. Эпизод на 45 минут – значит примерно 1,7 ГБ на таком качестве. Предложите «скачать в HD» без выбора качества – и сезон быстро забьёт бюджетный телефон, поэтому большинство приложений дают зрителю выбрать качество загрузки и по умолчанию ставят ступень ниже. Ещё два ограничения идут от владельца контента, а не от платформы: офлайн-лицензия несёт срок истечения (загрузка перестаёт играть, скажем, через 30 дней или через 48 часов после первого запуска), а некоторые студии запрещают офлайн вовсе. Эти правила задаются в политике лицензий – см. политика лицензий: аренда, офлайн, output, – а клиентское поведение – в офлайн-скачивание и воспроизведение.

Рисунок 3. Офлайн – это две загрузки, а не одна: медиа и постоянная лицензия со сроком истечения.

Правила сторов, которые формируют биллинг и воспроизведение

Правила, которые чаще всего переписывают мобильный план, лежат не в каком-либо видео-спеке. Это политики сторов Apple и Google, и они касаются и того, как вы играете, и того, как берёте деньги.

По воспроизведению указание Apple – пункт 2.5.7 App Store Review Guidelines – прямое: видеоконтент длиннее десяти минут, доставляемый по сотовой сети, обязан использовать HLS и включать базовый поток не менее 192 кбит/с. На практике это повторяет «выпускайте HLS для iOS» и «держите низкую ступень в лестнице для слабых сетей». Выпустите длинное видео без HLS – и Apple отклонит сборку.

По деньгам ставки выше. Оба стора требуют, чтобы цифровые подписки, продаваемые внутри приложения, шли через собственный биллинг стора – Apple In-App Purchase и Google Play Billing, – и оба берут комиссию. Стандартная ставка – 30%, падает до 15% для подписчиков после первого года и в рамках программ для малого бизнеса. Посчитаем на подписке $9,99 в месяц при стандартных 30%: стор оставляет $9,99 × 0,30 = $3,00, а вы получаете $6,99. На 10 000 подписчиков внутри приложения это $30 000 в месяц, уходящие в стор ещё до оплаты единственного сервера. Эта строка – причина, по которой стратегию монетизации и мобильную инженерию нельзя планировать порознь; сторону биллинга и прав мы разбираем в биллинг подписок и entitlement.

Есть проверенное исключение. «Reader»-приложение – то, чья основная работа в проигрывании контента, купленного или оформленного где-то ещё (категория, где сидят Netflix и Spotify), – может получить право разместить ссылку на свою внешнюю страницу регистрации, где подписка не несёт комиссии стора. Правовая почва здесь сдвигается: решение суда США 2025 года по делу Epic Games против Apple заставило Apple разрешить внешние платёжные ссылки, а декабрьское апелляционное решение 2025 года частично его отменило, оставив Apple возможность брать некую «разумную» комиссию с внешних покупок по ставке, не зафиксированной на момент написания. Считайте точную комиссию по внешним ссылкам подвижной величиной и сверяйте её, прежде чем моделировать выручку.

Рисунок 4. Два способа брать оплату на мобайле и одно правило воспроизведения, которое на iOS не обойти.
«Частая ошибка – четыре, что топят мобильные запуски. Первая: шифрование только в cenc, и тогда каждое видео – чёрный экран на iPhone; пакуйте cbcs. Вторая: выпуск только DASH, и тогда iOS нечего играть; всегда выпускайте HLS. Третья: своя форма оплаты картой для подписок внутри приложения, которую оба стора отклоняют; используйте In-App Purchase или квалифицируйтесь как reader-app. Четвёртая: предположение, что Widevine L1 везде, и обещание 4K на телефонах; большинство устройств стримят на L3 и упираются ниже HD.»

Нативно или кросс-платформенно: вопрос стоимости сборки

Раз два стека делят так мало, команды спрашивают, может ли кросс-платформенный фреймворк свести их в одну кодовую базу. React Native и Flutter могут, до известной степени: оба гоняют единую кодовую базу приложения на iOS и Android, и у обоих есть видеокомпоненты, которые оборачивают нативные плееры под капотом – AVPlayer на iOS, ExoPlayer/Media3 на Android. Вы пишете один UI; само декодирование и DRM по-прежнему работают на нативном движке каждой платформы. Это экономит реальные усилия на экранах и навигации. Меньше экономит на трудной части – обвязке DRM под каждую платформу, офлайн-поведении и тестировании на устройствах, той работе, что не исчезает, каким бы фреймворком ни рисовались кнопки. Честная формулировка для CTO: кросс-платформа ужимает бюджет интерфейса, а не бюджет воспроизведения-и-защиты. Полный разбор – в плеер на каждом экране: единая стратегия, а гостиные собратья этих двух платформ – tvOS и Fire TV – в Apple TV / tvOS и Fire TV.

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

Мобайл – обычно место, где OTT-сервис встречает больше всего зрителей и больше всего способов провалиться, потому что стеки iOS и Android должны быть каждый корректен, защищён и совместим со стором в масштабе полного каталога. Фора Софт строит видеостриминг, OTT/интернет-ТВ, e-learning, телемедицину и видеоконференции с 2005 года – 250+ проектов для 400+ клиентов за 20+ лет, – поэтому паттерны нативного воспроизведения отсюда (AVPlayer с FairPlay, ExoPlayer/Media3 с Widevine, упаковка-один-раз по cbcs, офлайн-лицензии и решения по биллингу сторов, которые идут рядом) – это повседневность нашей стриминговой работы. Мы вендор-нейтральны: мы переводим правила платформ в сборку, а не перепродаём один SDK.

Главное

  • iOS и Android не делят плеер: AVPlayer играет только HLS; ExoPlayer/Media3 играет HLS и DASH.
  • FairPlay защищает iOS, Widevine защищает Android; обе работают на Common Encryption.
  • Упакуйте один раз по схеме cbcs – и те же файлы открываются на обеих платформах.
  • Widevine L1 (железо) открывает HD/4K; L3 (софт) обычно ограничен 480–720p.
  • Офлайн – отдельный путь с хранимой лицензией, у которой есть срок истечения.
  • Правила сторов требуют HLS по сотовой сети и забирают 15–30% подписок в приложении.

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

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

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