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

TL;DR

Любой современный платный стриминговый продукт в открытой Сети сегодня одновременно поставляет три разные системы Digital Rights Management: 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 2025-08-21; 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 2025-08-21.

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

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

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

Кратко: каждая крупная device-платформа выпустила свой CDM, и ни одна не пускает чужой. Нейтрального DRM, который работал бы везде, не существует, потому что производители устройств одновременно являются и владельцами 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 и длинном хвосте broadcast-сетап-боксов.

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

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

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

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

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

Механика чистая и компактная. Стандарт описывает четыре protection scheme, которые задают, как именно зашифрован сэмпл: cenc (AES-128 CTR, полный сабсэмпл), cbc1 (AES-128 CBC, полный сабсэмпл), cens (AES-CTR pattern – шифруется один блок из десяти 16-байтных) и cbcs (AES-CBC pattern – тот же 1-из-10, но в CBC-режиме). Из четырёх в production-практике выжили два: 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 – base-64 XML-объект, который называется 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(), передавая список приемлемых key systems. EME возвращает MediaKeySystemAccess для первой системы, которую браузер на самом деле поддерживает.

Шаг 2 – диспетчеризация init-data. Как только 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 разворачивает ключ в свою защищённую память; ключ не пересекает границу JavaScript, не попадает даже в процесс рендера. Дальше CDM расшифровывает каждый поступающий сэмпл и передаёт декодированные пиксели в защищённый видеотракт GPU – остальная ОС незащищённого фрейма не видит.

Шаг 5 – обновление и ротация. Для долгих сессий и для лайв-стримов, которые ротируют ключи в середине стрима (каждые несколько часов на event-вещании), 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, – но именно это спецы лицензионного-сервера у вашего вендора реализуют все три на бэке. Поэтому 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 – software-only, ключи и расшифровка живут в обычной памяти процесса – и ограничен SD (480p или 540p в зависимости от сервиса). Именно поэтому Netflix и Disney+ молча падают до 480p на десктопном Chrome: на большинстве десктопов Widevine рапортует L3, и студийная политика обрезает разрешение.

Лестница PlayReady структурно та же, но с другими именами. SL150 – software, только для закрытого тестирования, прямо не рекомендуется для production. SL2000 – software, hardened на устройстве. SL3000 – hardware, стек 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 4K-поколения. На этих устройствах content key получается, разворачивается и хранится исключительно внутри Secure Enclave; ОС, включая ядро, прочитать его не может. Старые Intel-Mac без Secure Enclave запускают FairPlay в software – студии относят это к категории 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. Storage немного растёт за счёт PSSH-коробок (несколько сотен байт на init-сегмент), но в каталожном масштабе это пренебрежимо мало. Видимая стоимостная линия для DRM – счёт лицензионного сервера.

Публичные прайс-листы крупнейших managed-DRM-вендоров в 2026 группируются вокруг двух форм: платформенная плата 100–2 000 USD/мес плюс per-licence-request 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. Новый зритель тапает play на 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 запрещён в России), делает upstream-вызов к Widevine «modular» лицензионному серверу через HTTPS-API DRM-вендора (50–120 мс), получает обёрнутый ключ и политику, подписывает ответ под устройство и возвращает ~2 КБ клиенту. Серверное время в сумме: 70–180 мс.

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

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

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

Pattern recognition из production-проектов Фора Софт, в порядке частоты.

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

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

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

Ошибка 4 – пропустить нагрузочный тест лицензионного сервера. Команда запускает большую премьеру, в момент включения стрима CDM каждого зрителя начинает спрашивать лицензию в одно 30-секундное окно, и региональный endpoint вендора лицензионного сервера срабатывает rate-limit. Лекарство: peak-traffic-load-test против реального production-endpoint вендора и план fallback (второй регион, второй вендор) на горячие 30 секунд премьеры.

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

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

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

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

Если аудитория – только Веб и mobile (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 reviewers отклоняют платные видео-приложения, которые играют контент без одобренного DRM.

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

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

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

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

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

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

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