PlayReady подробно: DRM от Microsoft для 2026 года

TL;DR

PlayReady – это система управления цифровыми правами (DRM) от Microsoft. На сегодняшний день это единственный DRM, который работает на всех основных классах устройств, куда может попасть ваш стриминговый продукт: Windows, Edge, Chrome на Windows 11, Xbox, Roku, любые крупные платформы Smart TV, IPTV-приставки и растущий список Android STB. Именно поэтому PlayReady стоит рядом с Widevine и FairPlay практически в каждой OTT-инсталляции с премиальным контентом. Под капотом PlayReady оборачивает протокол выдачи лицензии на основе SOAP-XML вокруг контентного заголовка (WRMHEADER), который плеер несёт внутри MPEG-4 pssh-бокса. Сегменты шифруются теми же схемами ISO/IEC 23001-7 Common Encryption (cenc AES-CTR или cbcs AES-CBC), что и у Widevine с FairPlay, – значит, один CMAF-актив способен обслужить все три DRM. Клиенты делятся на три уровня безопасности: SL150 для разработки, SL2000 для «software-DRM» и SL3000 для аппаратно защищённых клиентов с Trusted Execution Environment, поддерживающих 4K и HDR. Текущий релиз – PlayReady 4.8 (апрель 2026); самое значимое серверное изменение за три года – counter-signed-сертификаты, появившиеся в версии 4.7 (август 2025).

Зачем это нужно

Если вы продаёте видео и ваша аудитория хотя бы частично использует Windows, Xbox, Roku или любую крупную платформу Smart TV – вы должны поддерживать PlayReady. Safari не работает с PlayReady (там используется FairPlay Streaming), а десктопный Chrome по умолчанию использует Widevine. Однако как только аудитория включает Microsoft Edge, Xbox, Smart TV в отелях или – всё чаще – Chrome на Windows 11 с аппаратной защитой 4K, PlayReady становится единственным DRM, который сможет воспроизвести ваш стрим.

Продакт-менеджер после прочтения этой статьи поймёт, почему требование «мы возьмём только Widevine на Smart TV» почти всегда проваливается на ревью (Smart TV изначально поддерживают PlayReady; поддержка Widevine у разных производителей и поколений устройств непредсказуема) и почему в голливудских контрактах на 4K в 2026 году по-прежнему указано условие: «Widevine L1 ИЛИ PlayReady SL3000».

Инженер уйдёт со статьёй, получив схему SOAP-обмена «на проводе», синтаксис WRMHEADER, EME-строки key-system и четыре типичные продакшен-ошибки, которые могут сорвать релиз за неделю до запуска.

Основатель получит чёткий ответ на вопрос: «Чем PlayReady отличается от Widevine?» – в двух словах: структурно они похожи (оба делят клиентов по уровням безопасности, используют шифрование по стандарту Common Encryption и согласование лицензий через HTTPS), но коммерчески – разные. PlayReady доминирует там, где устройства поставляются от Microsoft или чип-вендоров с PlayReady TEE, а это сейчас почти каждый чипсет Smart TV на рынке.

Эта статья – четвёртая и последняя в мини-цикле о DRM: DRM 101: почему три системы и почему вы ставите все три – основа; Common Encryption (CENC) подробно – упаковочный слой; Widevine: L1, L2, L3 – что они значат на самом деле – сторона Google; FairPlay Streaming подробно – сторона Apple. Этот текст – про Microsoft.

Что такое PlayReady на самом деле

Сначала определение, потом «на проводе». PlayReady – это формат контентного заголовка + протокол выдачи лицензии + клиентский Porting Kit + серверный SDK + многоуровневая лицензионная программа. Кусочки складываются так.

Контентный заголовок, называемый WRMHEADER, – это небольшой XML-документ, который пакетизатор формирует при шифровании, а плеер читает при воспроизведении. В нём указывается идентификатор ключа (KID) контента, алгоритм шифрования и, при необходимости, URL для запроса лицензии. Пакетизатор помещает WRMHEADER внутрь pssh-бокса (Protection System Specific Header) в начале каждого MPEG-4 / fMP4 / CMAF-актива, а для доставки HLS с использованием Common Encryption – внутрь тега #EXT-X-SESSION-KEY.

Протокол выдачи лицензии – это обмен SOAP-через-HTTPS между клиентом и вашим лицензионным сервером. Клиент отправляет base64-кодированный challenge (XML-документ, подписанный клиентским сертификатом), а сервер возвращает base64-кодированный response с одной или несколькими лицензиями; каждая лицензия – отдельный XML-документ, подписанный сервером. Клиент проверяет подпись, извлекает контентный ключ и начинает расшифровку. Всё это умещается в один HTTPS POST.

Клиентский Porting Kit, или PlayReady Device Porting Kit (PK), – это исходный код на языке C, который Microsoft лицензирует производителям устройств для реализации PlayReady-стека внутри их чипов. Microsoft не предоставляет бинарный клиент; производитель портирует PK в свою Trusted Execution Environment (TEE), проходит аудит на устойчивость (robustness) и выпускает устройство с встроенным клиентским сертификатом, у которого уровень безопасности (Security Level) задаётся на этапе производства.

Серверный SDK, PlayReady Server SDK, – это .NET-библиотека, которую операторы лицензионных серверов (вы) интегрируют в веб-сервис. По состоянию на апрель 2026 года доступны две версии: legacy .NET Framework, предназначенная исключительно для установки на Windows, и .NET 8.0 Core, работающая на любой платформе, включая Linux-контейнеры. Server SDK выполняет криптографические операции: парсит запрос (challenge), проверяет подписи и подписывает лицензию. Бизнес-логика подключается к нему через небольшой набор хуков.

Лицензионная программа – это юридический слой. Microsoft лицензирует PlayReady двум разным аудиториям: разработчикам клиентских решений (чип-вендоры, разработчики приложений, команды браузеров) и разработчикам серверных решений (стриминговые сервисы, поставщики лицензионных серверов). Обе стороны подписывают соглашение о соответствии и надёжности; клиентская часть включает SL3000 self-assessment, который Microsoft ввела в апреле 2015 года, чтобы соответствовать требованиям Голливуда к поддержке 4K и HDR.

Из этого устройства вытекают два следствия, и они лежат в основе каждого решения, которое ваша команда принимает по PlayReady.

Первый. Охват PlayReady зависит от чипа, а не от браузера. Устройство поддерживает PlayReady, потому что его System-on-Chip включает реализацию PlayReady TEE, а не из-за наличия в операционной системе программного CDM. Поэтому почти все Smart TV на рынке – Tizen, webOS, Vidaa, Android TV, Roku, Fire TV – воспроизводят PlayReady «из коробки»: чипсеты от MediaTek, Realtek, Amlogic, Broadcom и Sigma лицензируют PK и поставляют SL2000- или SL3000-клиент. По той же причине Widevine на Smart TV распространён гораздо неравномернее.

Второй. PlayReady на ПК означает Edge, а всё чаще – Chrome на Windows 11. Десктопный Safari не поддерживает PlayReady. То же самое – с десктопным Firefox. Chrome на десктопе исторически не поддерживал PlayReady, но в конце 2024 – начале 2025 года Chrome на Windows 11 (билд 22000 и выше, версия 140 и выше) получил поддержку аппаратного DRM SL3000 через Content Decryption Module, унаследованный от Edge. Таким образом, современный Chrome на актуальной Windows-машине с совместимым GPU стал полноценной платформой для PlayReady SL3000. Старая EME-строка com.microsoft.playready по-прежнему работает для программных клиентов; новая com.microsoft.playready.recommendation – то, что нужно использовать для любого клиента, претендующего на 4K с аппаратной защитой.

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

Протокол «на проводе»: Challenge и Response

Запрос лицензии PlayReady представляет собой двухэтапный HTTPS-обмен. Оба сообщения – это SOAP-документы в формате XML, закодированные в base64-объекты. Для плеера они являются непрозрачными, однако инженер лицензионного сервера может полностью их прочитать.

Сообщение 1 – Challenge. Когда плеер понимает, что нужна лицензия, он просит PlayReady-клиент сформировать challenge. Клиент собирает: WRMHEADER из pssh-бокса (чтобы сервер знал, какой KID искать), цепочку клиентских сертификатов (чтобы сервер проверил уровень безопасности клиента), список поддерживаемых функций (чтобы сервер понял, готов ли клиент к многоалгоритмным лицензиям PlayReady 4.6 или работает только со старой одноалгоритмной формой), anti-replay nonce и блок client-info, в котором указаны ОС, версия PK и подсказки по политике. Клиент подписывает challenge приватным ключом устройства, кодирует результат в base64, и плеер отправляет HTTPS POST на ваш URL лицензии – обычно с Content-Type: text/xml и заголовком SOAP-Action, указывающим операцию (AcquireLicense, AcknowledgeLicense или JoinDomain).

Сообщение 2 – Response. Ваш PlayReady License Server получает запрос, передаёт его в Server SDK, и SDK:

1. Проверяет подпись клиента по цепочке сертификатов, доходит до корневого сертификата Microsoft и убеждается, что сертификат не отозван (SDK сверяется с глобальным списком отзыва, который Microsoft публикует ежемесячно).
2. Читает WRMHEADER, чтобы определить KID, и ищет соответствующий контентный ключ в вашей базе данных.
3. Извлекает уровень безопасности клиента из сертификата (150, 2000 или 3000) и проверяет, соответствует ли он политике, установленной вашей бизнес-логикой для данного контента.
4. Применяет бизнес-правила: авторизован ли пользователь, не истёк ли срок проката, находится ли пользователь в разрешённой географии, требуется ли в лицензии поддержка HDCP, защита выхода, сохранение лицензии (persistence) или ограничение по количеству запусков.
5. Если все проверки пройдены, SDK формирует одну или несколько лицензий (каждая – XML-документ, подписанный сертификатом развёртывания сервера вашей команды, в котором контентный ключ обёрнут в сессионный ключ, предоставленный клиентом в запросе challenge), упаковывает их в ответ и подписывает конверт.

Response возвращается к плееру, который передаёт его PlayReady-клиенту. Клиент проверяет подпись сервера с помощью Server Deployment Certificate (Microsoft выдал его вашей команде при подключении к лицензионной программе), расшифровывает контентный ключ и запускает процесс расшифровки. Как и в FairPlay и Widevine, контентный ключ никогда не передаётся по сети в открытом виде – он защищён session key, который клиент сам отправил в запросе challenge, а этот session key был уникален для одного конкретного ответа на одном устройстве.

Сокращённый SOAP-обёртка с PlayReady-запросом выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <AcquireLicense xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols">
      <challenge>
        <Challenge xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols/messages">
          <LA xmlns="http://schemas.microsoft.com/DRM/2007/03/protocols" Id="SignedData" xml:space="preserve">
            <Version>1</Version>
            <ContentHeader>
              <WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.3.0.0">
                <DATA>
                  <PROTECTINFO>
                    <KIDS><KID ALGID="AESCBC" VALUE="base64-KID"/></KIDS>
                  </PROTECTINFO>
                  <LA_URL>https://license.example.com/playready</LA_URL>
                </DATA>
              </WRMHEADER>
            </ContentHeader>
            <CLIENTINFO>...</CLIENTINFO>
            <RevocationLists>...</RevocationLists>
            <LicenseNonce>base64-anti-replay-nonce</LicenseNonce>
            <ClientTime>2026-05-25T12:00:00Z</ClientTime>
            <EncryptedData>...</EncryptedData>
          </LA>
          <Signature>...</Signature>
        </Challenge>
      </challenge>
    </AcquireLicense>
  </soap:Body>
</soap:Envelope>

License Server и Header Specification от Microsoft полностью описывают побайтовый синтаксис; приведённый выше пример – лишь ориентир, а не спецификация.

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

WRMHEADER и PSSH-бокс

DASH-манифест с защитой PlayReady выглядит почти так же, как обычный. Отличия – в добавлении элемента ContentProtection, указывающего на PlayReady, и, если WRMHEADER размещается не только в боксе pssh внутри сегментов, но и встроен прямо в манифест, – в наличии base64-кодированного элемента pro с заголовком.

WRMHEADER – это единственный XML-документ, необходимый каждому PlayReady-клиенту для инициирования запроса лицензии. Атрибут version передаётся в формате MAJOR.MINOR.0.0; сегодня активно используются версии 4.0.0.0, 4.1.0.0, 4.2.0.0 и 4.3.0.0. PlayReady Header Specification описывает синтаксис каждой версии полностью; практическое руководство следующее:

• 4.0.0.0 – один KID, только AES-CTR. Используйте только если нужно поддерживать legacy SL2000-клиенты до 2017 года.
• 4.1.0.0 – добавляет custom data и расширенные атрибуты, по-прежнему один KID.
• 4.2.0.0 – добавляет поддержку нескольких KID в одном WRMHEADER. Обязательно для типичного multi-period DASH и multi-track CMAF, где у аудио и видео разные ключи.
• 4.3.0.0 – добавляет cbcs (ALGID="AESCBC") рядом с cenc (ALGID="AESCTR") и разрешает опускать CHECKSUM, когда алгоритм AESCBC (checksum – артефакт детерминированного counter-поведения AESCTR, в CBC он не нужен). Используйте эту версию, когда пакуете CMAF одним мастером для FairPlay-и-PlayReady-на-одном-активе.

Минимальный WRMHEADER 4.3.0.0 с одним AESCBC-ключом выглядит следующим образом:

<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.3.0.0">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID ALGID="AESCBC" VALUE="base64-KID-16-bytes"/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>https://license.example.com/playready</LA_URL>
    <DS_ID>base64-Domain-Service-ID</DS_ID>
  </DATA>
</WRMHEADER>

Пакетизатор оборачивает WRMHEADER в PlayReady Object – небольшой бинарный контейнер, описанный в спецификации, – а сам объект помещается в pssh-бокс в начале MPEG-4-файла. SystemID pssh-бокса для PlayReady – фиксированный UUID 9A04F079-9840-4286-AB92-E65BE0885F95, и именно эта магическая константа позволяет каждому плееру распознать защищённый PlayReady-стрим. Плееры ищут этот бокс во всех DASH-сегментах, CMAF-фрагментах и HLS-fMP4-сегментах; обнаружив его с нужным SystemID, они передают содержимое своему PlayReady-клиенту, после чего запускается процесс приобретения лицензии.

Для HLS-доставок, ориентированных на PlayReady (что типично для Smart TV, предпочитающих HLS вместо DASH), WRMHEADER передаётся в плейлисте через:

#EXT-X-SESSION-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.microsoft.playready",KEYFORMATVERSIONS="1",URI="data:text/plain;charset=UTF-16;base64,<base64-WRMHEADER>"

Строка KEYFORMAT com.microsoft.playready – это магическая константа для PlayReady-on-HLS; плееры, которые её не распознают, пропускают тег и ищут другую DRM-строку в том же плейлисте. Таким образом, один HLS multi-variant-плейлист может одновременно содержать FairPlay (com.apple.streamingkeydelivery) и PlayReady (com.microsoft.playready), а каждый плеер выбирает ту строку, которую поддерживает его нативная DRM.

CMAF, CENC и режим шифрования, объединивший три DRM

Десять лет multi-DRM-экономика существовала за счёт дублирования: каждый премиум-стриминг упаковывал каталог дважды – один раз в cenc (AES-128 в режиме счётчика, схема, поддерживаемая PlayReady и Widevine) и один раз в cbcs (AES-128 в режиме сцепления блоков с паттерном – единственная схема, совместимая с FairPlay). Две копии каждого закодированного контента на каждом узле CDN и пропорциональные расходы на трафик, хранение и упаковку.

Это изменилось в октябре 2017 года с выходом PlayReady 4.0, который добавил поддержку cbcs параллельно с cenc. С этого момента один CMAF-мастер, зашифрованный один раз в cbcs, можно было использовать для создания DASH-манифеста под PlayReady, другого DASH-манифеста под Widevine и HLS-плейлиста под FairPlay: три DRM-системы, три манифеста, но один и тот же набор зашифрованных сегментов на CDN. Экономика кардинально изменилась. Затраты на хранение сократились вдвое. Время пакетирования – тоже вдвое. Семьдесят пять процентов расходов CDN, связанных с доставкой контента (egress), остались прежними (зритель всё равно загружает один из трёх потоков), но оставшиеся двадцать пять процентов – хранение и пакетирование – резко снизились. ISO/IEC 23001-7:2023 – это зонтичный стандарт, определяющий обе схемы; ISO/IEC 23000-19 (CMAF) требует, чтобы каждый зашифрованный CMAF-трек-сэмпл использовал одну из двух схем CENC.

Подводный камень: каждый PlayReady-клиент, потребляющий cbcs, должен поддерживать версию PlayReady 4.0 или выше. Xbox One получил PlayReady 4.0 с прошивкой 1709 (ноябрь 2017); современные Smart TV работают на 4.0 и выше; Windows 10 начиная с версии 1709 поддерживает cbcs. Устройства старше – небольшое меньшинство в 2026 году, но они всё ещё присутствуют в long-tail-каталогах – потребуют cenc. Прагматичный подход по умолчанию в 2026 году: «cbcs для всего нового контента; сохраняйте один legacy-пакет cenc, только если аналитика продолжает фиксировать значительный трафик с устройств до 2017 года».

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

Уровни безопасности: SL150, SL2000, SL3000 – что они на самом деле значат

PlayReady делит клиентов на три уровня безопасности (Security Level). Каждый уровень – это свойство клиентского сертификата, заложенное на этапе производства и доступное любому лицензионному серверу, с которым клиент когда-либо взаимодействует. Сервер может отклонить запрос (challenge), уровень безопасности которого ниже установленной политики MinimumSecurityLevel для контента, а клиент откажется привязываться к лицензии, если её уровень MinimumSecurityLevel выше его собственного – таким образом обеспечивается симметричная защита с обеих сторон.

SL150 – разработка и тест. SL150 означает «ничто не закалено». Клиент может работать целиком в user-space-коде, ключи не защищены, сертификат устройства не привязан к железу. SL150 – это уровень, на котором разработчик плеера интегрируется с Porting Kit; собственная документация Microsoft по SL150 прямо пишет, что этот уровень «not suitable for commercial content». Лицензионный сервер в продакшене должен отклонять SL150-challenges, если они не идут из известного внутреннего IP-диапазона.

SL2000 – Software-DRM. SL2000 – минимально допустимый уровень для коммерческого контента. Активы, клиентские и контентные секреты защищены «программными или аппаратными средствами» – стандартная интерпретация: SL2000-клиент представляет собой защищённую программную реализацию с кодовой подписью, защитой от отладки и обфускацией, но без аппаратного Trusted Execution Environment. Десктопный Edge в программном режиме, устаревшая EME-строка com.microsoft.playready без суффикса .recommendation, а также многие Android-стрибоксы без аппаратного DRM-TEE – всё это примеры SL2000. SL2000 позволяет воспроизводить контент в разрешениях SD и HD в соответствии со стандартными голливудскими соглашениями; 4K, HDR и другие форматы Enhanced Content – недоступны.

SL3000 – Hardware-DRM. SL3000 – уровень, который требуется голливудскими контрактами на 4K и HDR. Стек PlayReady должен работать внутри Trusted Execution Environment (TEE) процессора – аппаратно изолированной области выполнения (ARM TrustZone, Intel SGX/TDX, Microsoft Pluton, AMD Platform Security Processor или проприетарный TEE от производителя чипов: MediaTek, Realtek, Amlogic). Внутри TEE одновременно функционируют криптостек и путь декодирования видео. Ключевой материал – приватные ключи, контентные ключи, производные ключи – никогда не покидает TEE; расшифрованные сжатые сэмплы не попадают в обычную системную память; путь от декодирования до отображения использует защищённый видеопоток, так что злоумышленник, получивший root-доступ, не сможет сделать скриншот экрана.

SL3000 также требует соответствия расширенному набору правил Compliance and Robustness, включая обновление от апреля 2015 года, введшее Enhanced Content Protection для 4K и HDR. SL3000 – единственный уровень, который сегодня даёт доступ к UHD-контенту почти на всех платформах премиум-стриминга, за исключением частичного случая – Widevine L1 на Android. Однако стандартный пункт у студий гласит: «Widevine L1 или PlayReady SL3000», поэтому даже продукты, ориентированные на Android, всё равно включают PlayReady для поддержки остальных устройств.

Пример того, как это реализуется в коде политики лицензионного сервера:

if content.label == "UHD_4K_HDR":
    minimum_security_level = 3000
elif content.label == "HD_1080p":
    minimum_security_level = 2000
else:
    minimum_security_level = 2000

if client.security_level < minimum_security_level:
    return DenyLicense(reason="security_level_below_content_policy")

В реальных инсталляциях политика защиты многослойна: защита вывода (HDCP 2.2 для 4K, HDCP 1.4 для HD), ограничения на сохранение (часть 4K-аренды нельзя сохранить), лимит по числу запусков и продолжительность аренды действуют параллельно с проверкой уровня безопасности – но проверка Security Level всегда остаётся первым барьером. Response устанавливает MinimumSecurityLevel в то же значение, и доверенная исполнительная среда (TEE) клиента перепроверяет его при привязке (bind).

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

Что изменилось в PlayReady 4.6, 4.7 и 4.8

Эволюция PlayReady за последние четыре года проходила тихо, но содержательно. Три релиза имеют значение для любой команды, которая сегодня разрабатывает или поддерживает лицензионный сервер.

PlayReady 4.6 (декабрь 2022) ввёл лицензии на обмен ключами с поддержкой нескольких алгоритмов: теперь один ответ может содержать несколько контентных ключей, зашифрованных разными алгоритмами – это полезно, когда для видео и аудио используются разные алгоритмы, или когда схема шифрования меняется в середине воспроизведения. PlayReady 4.6 также перенес .NET Core Server SDK на .NET 6.0 и добавил IPackagingDataAcquisitionHandler для лицензионных серверов, которым необходимо получать метаданные упаковки в момент выдачи лицензии.

PlayReady 4.7 (август 2025) добавил counter-signed (dual-signed) сертификаты – самое значимое серверное изменение за три года. Counter-signed-сертификат содержит две подписи: оригинальную от Microsoft и дополнительную – от назначенного counter-signer. Такой механизм позволяет Microsoft обновлять доверенные сущности, не аннулируя весь парк устройств: к существующим сертификатам можно добавить counter-signature, и устройствам не нужно заново запрашивать учётные данные. PlayReady 4.7 также перенес .NET Core Server SDK на .NET 8.0 (это релиз с долгосрочной поддержкой до ноября 2026 года), добавил свойство LicenseResponse.ForceSignature, чтобы операторы могли принудительно подписывать непостоянные лицензии для аудита, и встроил версию Server SDK в каждый ответ – теперь клиентская телеметрия может отслеживать, насколько операторы используют актуальные релизы. Патч 4.7.8120 добавил историю Server Authorization Key (сертификат сервера можно ротировать без перезапуска сервиса) и устранил проблему с обновлением Device Credentials после ротации TEE-ключа.

PlayReady 4.8 (апрель 2026) – текущий релиз на момент публикации. Каталог PlayReady Product Versions от Microsoft – авторитетный changelog; на верхнем уровне 4.8 является инкрементальным обновлением по сравнению с 4.7 (продолжение доработки .NET Core Server SDK на базе .NET 8.0, обновление Device Porting Kit, без новых ломающих изменений в wire-протоколе). Команды, всё ещё использующие 4.5 или 4.6 в продакшене, должны запланировать переход на 4.8, ориентируясь на milestone LTS .NET 8.0 в ноябре 2026 года; те, кто работает на 4.7, могут обновляться в удобное для них время.

Типичные ошибки и продакшен-ловушки

Четыре типичных провала в интеграции PlayReady встречаются регулярно. Каждый из них хоть раз подводил одну из команд, с которыми я работал.

Ловушка первая: поставлять стрим только с cenc на флот, в котором есть Smart TV. Smart TV поддерживают PlayReady 4.0+ и нативно работают с cbcs; кодировать дважды – один раз в FairPlay-совместимый cbcs, другой – в PlayReady-совместимый cenc – означает удвоить затраты на пакетирование без реальной выгоды. Фикс: закодировать один раз в cbcs, создать три манифеста (DASH для PlayReady, DASH для Widevine, HLS для FairPlay) и направить каждый плеер на манифест, соответствующий его DRM.

Ловушка вторая: использовать com.microsoft.playready вместо com.microsoft.playready.recommendation для EME-клиента, который хочет 4K на Chrome / Edge. Legacy key-систем ограничивает вас поведением, эквивалентным SL2000, даже на устройстве, способном к SL3000. Фикс: использовать com.microsoft.playready.recommendation и устанавливать robustness в 3000 при согласовании возможностей в EME. Старые браузеры, не поддерживающие .recommendation, корректно откатятся к legacy-режиму; новые – активируют аппаратный DRM. Issue dash.js #3852 – канонический трекер для dash.js.

Ловушка третья: забыть проверять список отзыва клиентов на стороне сервера. Server SDK делает это автоматически, если вы ему даёте; некоторые команды отключают проверку отзыва в dev и забывают включить обратно в проде. Итог – лицензионный сервер выдаёт ключи компрометированным устройствам, которые Microsoft уже отозвал, и это ровно тот режим отказа, на котором валится аудит robustness. Фикс: никогда не отключать проверку отзыва в проде; пусть SDK тянет ежемесячный список Microsoft и отклоняет запросы от отозванных сертификатов. (Статус отзыва сертификата – одно из того, что голливудские аудиторы будут проверять по вашим логам доступа.)

Ловушка четвёртая: хардкодить SystemID и сломаться, когда спецификация съезжает. Почти – PlayReady SystemID не менялся с 2008 года и менять его никто не планирует. Но команды, которые жёстко зашивают его литералом в одном файле, а потом делают то же самое в другом (пакетизатор, парсер WRMHEADER на сервере, mock-плеер в тестах), однажды обнаруживают, что константа неправильна в одном месте, и им приходится искать её во всех трёх репозиториях. Фикс: объявить константу один раз в общей библиотеке и импортировать везде. Полный PlayReady SystemID – 9A04F079-9840-4286-AB92-E65BE0885F95.

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

Фора Софт с 2015 года разрабатывает multi-DRM-стеки для OTT-, e-learning- и телемедицинских продуктов – на платформах web, iOS, Android, Smart TV (Tizen, webOS, Vidaa), Roku и игровых консолях. PlayReady присутствует практически в каждом нашем продукте для Smart TV и Windows – в связке с FairPlay на устройствах Apple и Widevine на Android. Мы прошли апгрейды SDK 3.0 → 4.0 → 4.5 → 4.7 на серверной стороне, консолидацию cenc → cbcs и миграцию на com.microsoft.playready.recommendation на стороне браузерных клиентов. В проектах на базе WebRTC и видеоконференцсвязи PlayReady редко становится основным решением защиты (реальное время защищается DTLS- и SRTP-шифрование, а также контролем доступа на уровне сессии), но в OTT, обзорных VOD-разделах видеонаблюдения и broadcast-grade-вертикалях, где премиальный контент должен работать на широком парке устройств, PlayReady – стандартная часть решения.

PlayReady против Widevine против FairPlay: практическое сравнение

Статья DRM 101: почему три системы и почему вы ставите все три подробно разбирает сравнение. Таблица ниже – практический ориентир для принятия решения.

Самая полезная строка таблицы – про схемы шифрования. Каждый современный DRM использует cbcs; как только вы это понимаете, становится ясно, почему один CMAF-мастер и один выход пакетизатора обслуживают все три.

Главные выводы

• PlayReady – это DRM, который нативно поддерживается в Windows, браузере Edge, Xbox и практически на каждой Smart TV.
• Шифрование реализуется по стандарту ISO/IEC 23001-7 cenc (AES-CTR) или cbcs (AES-CBC, начиная с версии 4.0).
• WRMHEADER 4.3.0.0 с AESCBC – значение по умолчанию до 2026 года для новых пакетных пайплайнов.
• SL3000 – аппаратный уровень TEE, обязательный по стандарту голливудского 4K-контента.
• В PlayReady 4.7 появились counter-signed-сертификаты, а серверная часть была перенесена на .NET 8.0.
• Один CMAF-актив в cbcs может обслуживать одновременно PlayReady, Widevine и FairPlay.

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

• DRM 101: почему три системы и почему вы ставите все три
• Common Encryption (CENC) подробно
• Widevine: L1, L2, L3 – что они значат на самом деле

CTA

• Поговорите со стриминг-инженером – 30-минутный звонок с нашим DRM-лидом.
• Посмотрите кейсы – multi-DRM OTT, телемедицина, Smart TV.
• Скачайте чек-лист по установке PlayReady – краткое руководство по настройке: сертификаты, политики SL2000 / SL3000, выбор EME-ключевой системы и четыре типичные ошибки в продакшене.