DRM 101: почему три системы и зачем вы поставляете все три

TL;DR

Любой современный платный стриминговый сервис в открытой сети сегодня одновременно поддерживает три системы управления цифровыми правами: Widevine от Google, FairPlay Streaming от Apple и PlayReady от Microsoft. Каждый браузер, операционная система и телевизор работает только с одной из них. Благодаря стандарту ISO 2012 года Common Encryption (CENC), описанному в ISO/IEC 23001-7 (актуальная редакция – 2023), один и тот же зашифрованный видеофайл может обслуживать все три системы: упаковщик шифрует контент один раз, а плеер расшифровывает его с помощью того DRM, который ему доступен.

Браузерный API, построенный на этой основе – Encrypted Media Extensions (W3C, Working Draft от 21 августа 2025; Recommendation – 2017): он передаёт зашифрованные данные в так называемый Content Decryption Module (CDM) – это и есть конкретный Widevine, FairPlay или PlayReady, хранящий ключи и лицензию. Multi-DRM – не «приятное дополнение», а минимально необходимая архитектура для платного видеосервиса, который не хочет потерять доступ к одной из трёх крупнейших экосистем устройств.

Зачем это читать

Если вы когда-нибудь запускали платный OTT-продукт и на старте слышали от инженеров: «возьмём Widevine», – эта статья – вежливый ответ на вопрос, который вы не успели задать: почему одного DRM недостаточно? Честный ответ: потому что Google, Apple и Microsoft создали собственные DRM-системы, и ни одна из них не позволяет стороннему CDM работать внутри своего браузера.

Для продакт-менеджера, планирующего запуск стримингового сервиса, эта статья – карта. Для основателя, оценивающего затраты на интеграцию DRM, она даёт контекст: отраслевые прогнозы на 2026 год оценивают мировые потери от видеопиратства примерно в 75 млрд USD в год, с ожиданием роста до 125 млрд USD к 2028 году – именно поэтому любой студийный контракт на премиум-контент требует multi-DRM. Для инженера, готовящегося к интеграции, статья – технический праймер, после которого документация от DRM-провайдера становится понятной.

Что такое DRM в стриминговом конвейере

Прежде чем появится первая аббревиатура, определим границы задачи. Кодек, сжимающий изображение, – это первая функция. Контейнер, в который помещаются сжатые байты, – вторая. Протокол, по которому контейнер передаётся по сети, – третья. А четвёртая, отдельная функция – разрешить расшифровку и воспроизведение контента только нужному зрителю – и есть Digital Rights Management, или DRM. DRM работает поверх кодека, внутри контейнера, проходит через протокол, но отвечает на вопрос, который остальные слои не решают: должно ли это устройство, в этой стране, для этого аккаунта, в этот момент времени, получить доступ к этому потоку?

Современный стриминговый DRM – это четырёхзвенный механизм, и каждому звену в стандартах присвоено имя.

Первое: упаковщик шифрует аудио- и видеосэмплы внутри контейнера – обычно CMAF или fragmented MP4 – с помощью симметричного ключа, который называется content key. Формат шифрования определён стандартом 2012 года Common Encryption (CENC) – ISO/IEC 23001-7. Стандарт чётко указывает, какие байты каждого видеосэмпла подлежат шифрованию, какие остаются открытыми, а также как зашифрованный файл сообщает, какие DRM-системы имеют право его воспроизвести.

Второе: упаковщик объявляет, какие DRM-системы могут выдавать лицензию на этот файл. Он делает это с помощью небольших бинарных блоков PSSH (Protection System Specific Header), которые помещаются в инициализационный сегмент – по одной PSSH-записи на каждую DRM-систему. Каждая PSSH-запись содержит System ID (16 байт, идентификатор поставщика DRM) и небольшой служебный payload. Наличие нескольких PSSH-записей в одном файле – это способ, с помощью которого один CMAF-стрим одновременно сообщает Widevine, FairPlay и PlayReady: вот ваша ссылка на ключ, остальное запрашивайте у своего лицензионного сервера.

Третье: когда плеер открывает файл, браузер передаёт PSSH-данные в так называемый чёрный ящик – Content Decryption Module (CDM). CDM – это конкретная реализация Widevine, FairPlay или PlayReady, встроенная в браузер или операционную систему. Только CDM видит расшифрованные байты – это единственное звено в цепочке, которому они доступны. Передача данных осуществляется через стандартизованный W3C API – Encrypted Media Extensions (EME), опубликованный как Recommendation в сентябре 2017 года и существующий в редакции Working Draft от 21 августа 2025 года.

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

Эти четыре задачи – зашифровать один раз, объявить несколько DRM, передать в CDM, выписать сессионную лицензию – одинаковы для всех трёх крупных DRM. Различия заключаются в том, на каких устройствах размещён CDM, как устроен протокол лицензионного сервера и насколько надёжен аппаратный изолятор. Именно это и составляет суть; далее рассмотрим каждое из трёх различий.

Почему DRM-систем три, а не одна

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

Widevine от Google – это CDM в Chrome, в браузерах на базе Chromium (в Edge на платформах, отличных от Windows, используется именно он), в Firefox (по лицензии), на Android-устройствах, в Android TV, ChromeOS и в большинстве мультимедийных стеков Linux. FairPlay Streaming от Apple – CDM в Safari (на macOS и iOS), в AVFoundation для нативных приложений на iOS и tvOS, а также в собственном стриминговом конвейере Apple TV; на платформах, не относящихся к экосистеме Apple, FairPlay не поставляется. PlayReady от Microsoft – CDM в Edge на Windows, в консолях Xbox, в Windows UWP, в Samsung Tizen, LG webOS, Hisense Vidaa и в длинном списке устройств для цифрового вещания.

Получаются три непересекающиеся карты покрытия, которые в совокупности охватывают практически все домашние устройства, воспроизводящие платное стриминговое видео. Если выбрать только одну – теряется целая экосистема: Widevine исключает Apple и большинство TV-платформ; FairPlay – всё, что не Apple; PlayReady – Apple, Android и Chrome. Отраслевой консенсус с середины 2010-х: для открытого Веба нужны как минимум Widevine и FairPlay; для платного OTT-приложения на ТВ и Xbox добавляется PlayReady.

Причины, по которым три вендора не объединились, – контрактные, а не технические. Крупные студии – члены MPA, а также Netflix, Disney+ и Amazon – принимают контент в платный каталог только при условии использования на устройстве одобренной аппаратной DRM. Объединённый список одобренных схем – это пересечение трёх множеств: Widevine L1 + FairPlay с Secure Enclave + PlayReady SL3000. Единая открытая DRM должна была бы пройти многолетнюю сертификацию у каждой студии в каждом регионе – на это ни один из трёх вендоров не пойдёт, пока существующее статус-кво и так работает.

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

Архитектура «одно шифрование, три лицензии»

Главный трюк, делающий multi-DRM практичным: файл шифруется не трижды, а один раз. Common Encryption как раз и создан для этого – один зашифрованный сегмент подходит для любой DRM в мире, а каждая система выдаёт свою лицензию на один и тот же ключ.

Механика простая и компактная. Стандарт описывает четыре схемы защиты, определяющие способ шифрования сэмпла: cenc (AES-128 CTR, полный сабсэмпл), cbc1 (AES-128 CBC, полный сабсэмпл), cens (AES-CTR pattern – шифруется один блок из десяти 16-байтных) и cbcs (AES-CBC pattern – тот же 1-из-10, но в режиме CBC). Из четырёх в реальной практике используются только два: cenc и cbcs. Pattern-режимы были добавлены, чтобы слабые чипы – например, в старых Smart TV или бюджетных смартфонах – могли расшифровывать поток в реальном времени, не перегружая процессор.

В 2026 году доминирует одна схема: CMAF, упакованный один раз, зашифрованный по cbcs, объявленный и в HLS, и в MPEG-DASH манифестах. cbcs победил, потому что FairPlay расшифровывает только cbcs, а после раунда DASH-IF в сентябре 2020 года все остальные DRM (Widevine, PlayReady) добавили полную поддержку cbcs – теперь одно шифрование работает и для Apple, и для не-Apple плееров. Двойное шифрование (cenc для DASH + cbcs для HLS/FairPlay) формально остаётся валидным и описано в DASH-IF Implementation Guidelines Part 6 §10, но удваивает объём хранилища origin без какого-либо выигрыша в качестве – индустрия выбрала этот путь упаковщиков.

После шифрования упаковщик помещает PSSH-коробки в init-сегмент – по одной на каждый DRM, которому вы хотите предоставить доступ. Каждая PSSH-коробка содержит 16-байтовый System ID, идентифицирующий поставщика DRM (edef8ba9-79d6-4ace-a3c8-27dcd51d21ed – Widevine; 94ce86fb-07ff-4f43-adb8-93d2fa968ca2 – FairPlay; 9a04f079-9840-4286-ab92-e65be0885f95 – PlayReady), и небольшой блок, специфичный для DRM: для Widevine – Key ID и content ID; для PlayReady – XML-объект в формате base-64, называемый Pro header. Когда браузер открывает файл, EME передаёт активному CDM все обнаруженные PSSH-коробки; CDM выбирает нужную по System ID, остальные игнорирует.

Это вся суть multi-DRM-решения на стороне шифрования: один файл, несколько PSSH, один выбранный CDM и один вызов лицензии.

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

Обмен лицензией от начала до конца

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

Шаг 1 – загрузка манифеста и выбор CDM. Плеер загружает HLS- или DASH-манифест, обнаруживает в нём сигнализацию защиты (строку #EXT-X-KEY METHOD=SAMPLE-AES в HLS или элемент <ContentProtection> в DASH MPD), считывает предложенные System ID и вызывает navigator.requestMediaKeySystemAccess(), передавая список поддерживаемых систем шифрования. EME возвращает MediaKeySystemAccess для первой системы, которую браузер действительно поддерживает.

Шаг 2 – диспетчеризация init-данных. Как только MSE-буфер плеера получает init-сегмент, браузер анализирует PSSH-коробки и генерирует событие encrypted на <video>. Плеер создаёт MediaKeySession, вызывает generateRequest(initDataType, initData) с байтами PSSH, соответствующими нужному System ID, и ждёт, пока CDM сформирует запрос на лицензию. Этот запрос непрозрачен – плеер не может его прочитать, только CDM.

Шаг 3 – круг к лицензионному серверу. Плеер шлёт лицензионный запрос на endpoint лицензионного сервера сервиса по HTTPS, обычно с session-token в кастомном заголовке. Сервер валидирует токен (платный ли пользователь, открыто ли арендное окно, разрешено ли устройству географически), просит ключ-менеджмент-систему обернуть ключ, прикрепляет политику (максимальное разрешение, требование HDCP, persistent vs streaming, expiration), упаковывает ответ под протокол конкретного CDM и возвращает. Обычный round trip – 100–250 мс.

Шаг 4 – установка лицензии и расшифровка. Плеер передаёт ответ через MediaKeySession.update(response). CDM загружает ключ в защищённую память; ключ не выходит за пределы среды выполнения CDM и не попадает даже в процесс рендеринга. Далее CDM расшифровывает каждый поступающий сэмпл и передаёт декодированные пиксели в защищённый видеотракт GPU – остальная часть операционной системы, работающей в незащищённом контексте, их не видит.

Шаг 5 – обновление и ротация. Для длительных сессий и прямых трансляций, в которых ключи обновляются в ходе вещания (например, каждые несколько часов на мероприятиях), CDM генерирует событие message с данными messageType: "license-renewal" или "individualization-request"; плеер выполняет дополнительный HTTPS-запрос, а CDM заменяет ключ, не теряя ни одного кадра.

На уровне EME весь обмен одинаков для всех трёх DRM. Различается только содержимое непрозрачного blob. Widevine использует Protobuf; FairPlay – бинарное сообщение, называемое Server Playback Context (SPC), на которое лицензионный сервер (Key Server Module, KSM) отвечает Content Key Context (CKC); PlayReady передаёт данные в SOAP-обёртке. Код плеера ни с одним из этих форматов не работает – это задача CDM. Именно специалисты лицензионного сервера у вашего вендора реализуют поддержку всех трёх DRM на бэкенде. Поэтому и существуют managed-услуги с поддержкой multi-DRM.

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

Уровни безопасности: откуда берётся 4K и HDR

Студийные лицензии на премиум-контент – UHD, HDR, theatrical window – почти всегда требуют воспроизведения на аппаратно защищённой DRM с проверенной цепочкой защиты выходного сигнала. Каждая из трёх систем DRM определяет собственную иерархию уровней безопасности; политика студии реализуется на лицензионном сервере: если CDM представился ниже допустимого уровня, сервер выдаст пониженную лицензию с искусственно ограниченным разрешением.

Лестница Widevine – самая известная. L1 означает, что все операции – обращение к ключу и декодирование видео – происходят внутри Trusted Execution Environment (TEE), на чипах Arm это реализуется через TrustZone. Устройства уровня L1 имеют право на разрешение 1080p и выше, включая 4K HDR при наличии аппаратного HDCP 2.2/2.3 на выходе. L2 – смешанный режим: криптография выполняется в TEE, а часть видеотракта работает в обычной памяти. Большая часть индустрии уже отказалась от L2 и фактически относит его к L3. L3 – программная реализация: ключи и расшифровка хранятся в обычной памяти процесса, что ограничивает разрешение SD (480p или 540p – в зависимости от сервиса). Именно поэтому Netflix и Disney+ без предупреждения понижают качество до 480p на десктопном Chrome: на большинстве настольных систем Widevine сообщает уровень L3, и политики студий ограничивают разрешение.

Лестница PlayReady структурно аналогична, но с другими названиями. SL150 – программная реализация, предназначена исключительно для закрытого тестирования, не рекомендуется для использования в продакшене. SL2000 – программная реализация, защищённая на уровне устройства. SL3000 – аппаратная реализация, стек PlayReady работает внутри TEE-чипа, как и Widevine L1. Именно на этом уровне функционирует экосистема Smart TV (Samsung Tizen, LG webOS, Hisense Vidaa, Xbox). Студийные лицензии на 4K UHD, как правило, требуют SL3000.

FairPlay не публикует пронумерованную лестницу – Apple предоставляет одну реализацию FairPlay на одно поколение устройств. Аппаратная защита осуществляется через Secure Enclave – выделенный сопроцессор, присутствующий в каждом iPhone с чипом A7, iPad с A8X, Mac на базе Apple Silicon (M1) и Apple TV четвёртого поколения. На этих устройствах ключ контента генерируется, расшифровывается и хранится исключительно внутри Secure Enclave; операционная система, включая ядро, получить к нему доступ не может. Старые Mac на базе Intel без Secure Enclave используют программную реализацию FairPlay – студии относят такие устройства к категории Widevine L3.

Всё, что выше 1080p, требует ещё и аппаратной защиты выходного тракта – обычно HDCP 2.2 или 2.3 по HDMI. Лицензия DRM определяет требуемую версию HDCP; CDM запрашивает у ОС информацию о реальной поддержке HDCP на выходе; если кабель не поддерживает HDCP 2.2 – лицензия ограничивается 1080p; если выход дублируется на устройство записи – лицензия, как правило, не выдаётся вовсе. Практически 4K HDR требует аппаратной DRM + HDCP 2.2 + Trusted Video Path, и отсутствие любого из этих трёх компонентов снижает уровень воспроизведения.

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

Конкретный пример: запуск глобального VOD-сервиса

Проверим цифры на гипотетическом платном запуске VOD – стриминг архива на телефоны, планшеты, Smart TV, Xbox и открытый веб – чтобы картина стоимости стала наглядной.

Пусть сервис ставит в каталог 2 000 часов в трёх качествах (1080p SDR, 4K SDR, 4K HDR) и ожидает на полной раскрутке 500 000 ежемесячных подписчиков. Каждый смотрит около 20 часов в месяц – 10 миллионов viewer-hours в месяц и (грубо одна свежая лицензия на час просмотра) около 10 миллионов лицензионных запросов в месяц.

Энкодинг и пакетирование не зависят от количества используемых DRM: каталог формируется один раз на каждое качество, шифруется cbcs и подписывается для всех трёх систем DRM через PSSH. Объём хранилища немного увеличивается за счёт PSSH-обёрток (несколько сотен байт на init-сегмент), но в масштабах каталога это пренебрежимо мало. Основная финансовая нагрузка от DRM – счёт лицензионного сервера.

Публичные прайс-листы крупнейших вендоров managed-DRM в 2026 году группируются вокруг двух моделей: фиксированная платёжная модель – 100–2 000 USD в месяц – и оплата за запрос лицензии – 0,01–0,05 USD (усреднённые значения по трём DRM-провайдерам и тиражным тарифам). При объёме в 10 миллионов лицензий в месяц и средней стоимости 0,02 USD за лицензию расходы на лицензионный сервер составляют ~200 000 USD в месяц плюс фиксированная плата за платформу. Эти цены указаны без учёта контрактов с обязательствами по объёму; крупные стриминговые платформы получают существенные скидки.

Для сравнения: тот же сервис с одним DRM заплатил бы примерно треть – но потерял бы доступ к аудитории iOS и tvOS (отсутствует поддержка FairPlay), к Smart TV (нет PlayReady) или к Android и Chrome (отсутствует Widevine). Экономика делает использование трёх DRM более выгодным вариантом, как только в расчёт включены неприобретённые подписчики.

Полный стек, если вы строите модель целиком: кодируйте каталог под три качества (о bitrate-лестнице – отдельная статья 5.2); упаковывайте CMAF-упаковщиком с поддержкой CENC (Shaka Packager, Bento4 mp4encrypt, AWS MediaPackage, Unified Streaming, Norsk); отправляйте флаг --protection-scheme cbcs в KMS (большинство multi-DRM-провайдеров используют CPIX-совместимый KMS, и упаковщик сам подтягивает ключи); публикуйте манифесты HLS и DASH на основе одних и тех же сегментов; подключайте плеер к вашему лицензионному endpoint. Полная стоимость end-to-end интеграции зависит от выбора вендора лицензионного сервера и кросс-плеерного тестирования – само шифрование при современных упаковщиках сводится к двум конфигурационным флагам.

Конкретный пример: одна транзакция лицензионного сервера

Пройдёмся по одному обмену лицензией с цифрами, чтобы инженер мог оценить объём интеграции. Приведённые ниже числа – средние значения из production за 2026 год.

У вас, как у стримингового сервиса, есть лицензионный endpoint https://license.example.com/widevine, а также /fairplay и /playready. Новый зритель нажимает «воспроизвести» на серии в 4K-HDR. Его Android TV – устройство с поддержкой Widevine L1.

Плеер Android TV инициирует EME, формирует blob лицензионного запроса Widevine объёмом около 1 КБ и отправляет его методом POST на /widevine с заголовком Authorization: Bearer <session-jwt>, содержащим ваш подписной JWT. Сетевое время: 15–40 мс RTT до edge.

Middleware лицензионного сервера проверяет JWT (около 1 мс), извлекает политику контента из CMS (аренда до завтра, доступно в Германии, 4K-HDR запрещён в России), отправляет запрос через HTTPS-API DRM-провайдера к лицензионному серверу Widevine «modular» (50–120 мс), получает обёрнутый ключ и политику, подписывает ответ под устройство и возвращает клиенту около 2 КБ данных. Общее время обработки на сервере: 70–180 мс.

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

Бюджет задержки важнее для live-трансляций, чем для VOD. В случае лайв-события с 30-секундным буфером дополнительные 200 мс остаются незаметными. А вот для low-латентного стрима с целью в 2 секунды glass-to-glass на LL-HLS бюджет нужно измерять и настраивать. Классический способ оптимизации – persistent licences: CDM кэширует ключ в защищённом собственном хранилище и пропускает запрос лицензии в последующих сессиях. Так поступают Netflix и Disney+, чтобы второй клик по серии открывался мгновенно.

Четыре ошибки, которые делают почти все

Паттерны распознавания из production-проектов Фора Софт, в порядке убывания частоты.

Ошибка 1 – зашифровать только cenc. Команда настраивает DASH на cenc AES-CTR, видит, что Widevine и PlayReady работают, через полгода добавляет Safari и обнаруживает, что для FairPlay требуется повторное шифрование на cbcs. Исправлять дорого – уже отгруженный контент закатан в cenc, перепакетировать каталог нетривиально. Правильный дефолт в 2026 – cbcs с первого дня, объявленный и для HLS, и для DASH.

Ошибка 2 – забыть флаг persistent-licence. Команда устанавливает DRM «как есть» и обнаруживает, что при каждом запуске серии происходит новый лицензионный вызов. Для live-трансляций это нормально; для VOD – это удваивает нагрузку на лицензионный сервер и добавляет 100 мс к каждому воспроизведению. Стандарт W3C предлагает решение: установите persistentState: 'required' и sessionType: 'persistent-license' в конфиге MediaKeySystemAccess, а на сервере – многочасовой LicenseExpiration в политике.

Ошибка 3 – использовать одну и ту же лицензию для всех устройств. Команда применяет единую политику для мобильных устройств, веба и ТВ. Мобильные и веб-устройства работают, а ТВ-каталог не проходит студийную проверку, потому что PlayReady на ТВ сообщает SL3000, а лицензия, полученная с сервера, помечена как подходящая только для SL2000. Решение: лицензионный сервер анализирует уровень безопасности в запросе и выдаёт соответствующую политику – SL3000 / L1 / Secure Enclave для премиум-контента 4K-HDR, а для более низких уровней безопасности – снижает разрешение.

Ошибка 4 – пропустить нагрузочный тест лицензионного сервера. Команда запускает масштабную премьеру, и в момент старта стрима CDM каждого зрителя одновременно запрашивает лицензию в течение одного 30-секундного окна. В результате региональный endpoint вендора лицензионного сервера срабатывает на rate-лимит. Решение: провести нагрузочный тест пиковой нагрузки на реальном production-эндпоинте вендора и разработать план аварийного переключения (второй регион, второй вендор) на самые напряжённые 30 секунд премьеры.

Где помогает Фора Софт

Фора Софт поставляет DRM-защищённые стриминговые решения с 2010 года в ключевых вертикалях – OTT и интернет-ТВ, видео по запросу, e-learning, телемедицина, видеоконференции с записью. Наиболее типичная задача – интеграция на этапе запуска: у команды уже есть готовый каталог, контракт с CDN и плеер, который почти работает, но падает при воспроизведении через FairPlay на iOS или не поддерживает 4K на телевизорах Tizen. Мы анализируем политику лицензионного сервера, исправляем сигнализацию PSSH и при необходимости переподнимаем cbcs-конвейер упаковки, если он изначально был настроен только под cenc. Та же экспертиза применима к WebRTC-продуктам, которым нужно записывать сессии в DRM-защищённый HLS-архив (что типично для телемедицинского комплаенса и e-learning), а также к решениям для видеонаблюдения, которым требуется tamper-evident, DRM-подписанный доказательный след.

Как выбрать ваш DRM-стек

Ментальная модель, работающая в большинстве продуктов: сначала выбираете устройства, потом применяете DRM.

Если аудитория – только веб и мобильные устройства (Twitch-подобный лайв-стрим, музыкально-видео-сервис, видеоподкаст), то Widevine и FairPlay – это минимум и почти всегда максимум. PlayReady добавлять не стоит, если нет регулируемого корпоративного клиента, требующего Edge на Windows.

Если аудитория включает Smart TV или игровые консоли (любой OTT-продукт под Samsung, LG, Hisense, Roku, Xbox) – добавляйте PlayReady. Roku – особый случай: его стек BrightScript имеет собственные DRM-биндинги через партнёров Roku, но шифрование всё равно требуется cbcs, а также необходимо поставлять тот же CMAF. Android TV использует Widevine – он покрывается вашей лицензией Widevine.

Если аудитория включает Apple TV (нативное приложение для tvOS, а не сторонние устройства с названием «Apple TV» на других операционных системах) – FairPlay не рассматривается. Проверяющие App Store отклоняют платные видеоприложения, воспроизводящие контент без одобренного DRM.

Если каталог включает 4K HDR или премиум с theatrical window – добавляются дополнительные проверки версии HDCP на плеере, политика только аппаратного DRM на лицензионном сервере (отказ в выдаче лицензий Widevine L3, PlayReady SL150/SL2000, программного FairPlay) и постоянные лицензии с коротким сроком действия для офлайн-скачивания.

Если бизнес – закрытый корпоратив (учебное видео за SSO, внутренние коммуникации), DRM почти всегда избыточен: токенизированный пайплайн со signed URL (подробности – в нашей статье о токен-аутентификации) обеспечивает 90% защиты при 10% затрат на интеграцию.

Для большинства потребительских продуктов вывод прост: зашифровать один раз в формате CMAF/cbcs, создать три PSSH-коробки, заключить контракт с провайдером управляемой мульти-DRM-защиты (крупные игроки – PallyCon, EZDRM, BuyDRM, Axinom, AWS Elemental MediaPackage с защищённым упаковщиком), подключить плеер через EME и заложить 3–6 недель инженерного времени на полную интеграцию, включая прохождение тестов на iOS, tvOS, Tizen и webOS.

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

• Три DRM-системы – Widevine, FairPlay и PlayReady – существуют, потому что Google, Apple и Microsoft контролируют каждую из них и не допускают использование чужих CDM.
• Common Encryption (CENC, ISO/IEC 23001-7) позволяет одному CMAF-файлу поддерживать все три DRM через несколько PSSH-блоков в init-сегменте.
• Стандарт по умолчанию на 2026 год – шифрование одной схемой cbcs, которое будет использоваться как для HLS, так и для DASH с одних и тех же сегментов.
• Encrypted Media Extensions (EME) – это API браузера; CDM скрывает протоколы лицензирования, специфичные для каждой DRM.
• Уровни безопасности (Widevine L1 / PlayReady SL3000 / FairPlay Secure Enclave) позволяют воспроизводить 4K HDR; программные DRM ограничивают разрешение 480p.
• Основная стоимость – в лицензионном сервере; само шифрование реализуется всего двумя флагами упаковщика.

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

• Common Encryption (CENC) подробно – сравнение байтов в cenc и cbcs, а также формат PSSH-обёртки.
• Widevine: L1, L2, L3 – что они значат на самом деле – архитектура TEE и ограничения, накладываемые студиями.
• Encrypted Media Extensions (EME): как DRM живёт в браузере – браузерный API, через который плеер воспроизводит защищённый контент.