Содержание статьи +
- Кратко
- Почему это важно
- Три вендора, три огороженных сада: факт, который всё объясняет
- Google Widevine: самый широкий охват
- Microsoft PlayReady: рабочая лошадка Windows, консолей и ТВ
- Apple FairPlay: цена входа в экосистему Apple
- Ошибка, ломающая Apple: `cenc` против `cbcs`
- Уровни безопасности и лимит разрешения: одна логика, три словаря
- Карта «устройство → DRM»: кто что покрывает
- Как плеер на самом деле выбирает нужный DRM
- Почему карта толкает к multi-DRM – и почему это дешевле, чем кажется
- Частая ошибка: считать, что хватит одного DRM или одного уровня
- Чем здесь помогает Фора Софт
- Ключевые выводы
- Что читать дальше
Кратко
Рынок остановился на трёх несовместимых системах защиты контента, и каждую построил вендор платформы под собственные устройства: Google Widevine работает на Android, в Chrome и на большинстве смарт-ТВ и стримерских стиков; Microsoft PlayReady – на Windows, Xbox и большой доле ТВ и ТВ-приставок; Apple FairPlay – только в Safari, на iPhone, iPad, Mac и Apple TV. Ни одна из них не дотягивается до каждого экрана, и пробелы – это глухие стены: устройства Apple не запустят Widevine или PlayReady, а Apple не лицензирует FairPlay никому, – поэтому платформа, которая хочет охватить все устройства, обязана поддерживать все три. У каждой системы есть ещё уровни безопасности (Widevine L1/L2/L3, PlayReady SL150/SL2000/SL3000), которые определяют, происходит ли расшифровка в защищённом железе или в софте, и именно этот уровень проверяет лицензия студии, прежде чем разрешить вам стримить в HD или 4K. Эта статья простыми словами объясняет, что такое каждая из трёх систем, какие устройства она покрывает, как её уровни безопасности задают разрешение, как плеер выбирает нужную систему на лету и почему карта устройств толкает любую серьёзную платформу к схеме multi-DRM.
Почему это важно
Если вы основатель, продакт-менеджер или CTO, впервые строящий стриминг, реальность трёх DRM – это место, где сталкиваются задача охвата и задача стоимости, и непонимание её даёт две предсказуемые ошибки. Первая – собрать всё под один DRM (обычно Widevine, потому что его проще всего проверить в Chrome), запуститься и обнаружить, что каждый iPhone, iPad и Mac в вашей аудитории получает чёрный экран, потому что устройства Apple признают только FairPlay. Вторая – считать «DRM» одной функцией-выключателем, а потом услышать от студии на подписании, что ваша программная защита не дотягивает до аппаратного требования для их 4K-каталога, и спешно переделывать путь воспроизведения на каждом устройстве к дедлайну. Эта статья даёт карту: кто эти три вендора, какие именно устройства покрывает каждый, что означают уровни безопасности для разрешения, которое вам разрешено стримить, и как кусочки складываются так, чтобы один защищённый каталог играл везде. К концу вы сможете посмотреть на список целевых устройств и точно сказать, какие системы DRM и какие уровни безопасности должна поддерживать ваша сборка, – ещё до первой строки кода плеера и до подписания контентной сделки.
Статья продолжает зачем нужен DRM и что он на самом деле защищает; если вы ещё не провели границу между тем, что DRM останавливает и что не может, начните оттуда, а затем возвращайтесь сюда за реальностью устройств.
Три вендора, три огороженных сада: факт, который всё объясняет
Начнём с единственного факта, на котором держится вся статья: управление цифровыми правами – это не одна технология, а три конкурирующие, и каждой владеет платформенная компания, встроившая её в собственные устройства. Нейтрального универсального DRM, который согласны запускать все устройства, нет и никогда не было. Причина коммерческая, а не техническая – каждый вендор хотел контролировать защищённый путь на своём железе и не был готов зависеть от системы конкурента.
Результат – три системы, делающие одно и то же взаимно несовместимыми способами:
- Google Widevine защищает контент на Android, в Chrome и в огромной экосистеме устройств на технологиях Google или Chromium – включая большинство смарт-ТВ и стримерских стиков.
- Microsoft PlayReady защищает контент на Windows, на Xbox и на очень большой доле смарт-ТВ и ТВ-приставок мира.
- Apple FairPlay защищает контент в экосистеме Apple – Safari, iPhone, iPad, Mac, Apple TV – и больше нигде.
Слово «несовместимые» здесь несущее. Лицензия Widevine бессмысленна для устройства Apple; ключ FairPlay не откроет контент на телефоне Android. У каждой системы свой формат лицензии, своё рукопожатие доставки ключа и свой доверенный модуль на устройстве. Представьте три марки замков на трёх марках дверей: все замки держат дверь закрытой, но ключ, нарезанный под одну марку, не повернётся в другой, и изготовители замков не продают друг другу.
Вот следствие, которое определяет вашу архитектуру. Поскольку Apple не позволит Widevine или PlayReady расшифровывать видео на iPhone, а на телефонах Android нет FairPlay, платформа, которая хочет охватить все экраны, обязана поддерживать больше одного DRM – на практике все три. Требование звучит дорого, и наивное его прочтение («зашифровать каталог три раза, по разу на систему») действительно утроило бы хранение и кодирование. Современная реальность – обратная, и держится она на общем стандарте, позволяющем одному набору зашифрованных файлов обслуживать все три системы. К этому мы придём в конце; сначала познакомьтесь с тремя системами по очереди, потому что рассуждать о карте нельзя, пока не знаешь территории.
Google Widevine: самый широкий охват
Начнём с Widevine, потому что он касается большего числа типов устройств, чем два других. Widevine – система защиты контента от Google, встроенная в обширнейший список платформ. По собственной документации Google, Widevine нативно поставляется на телефонах, планшетах, ТВ и в авто на Android; на Chromecast; на ChromeOS; в браузерах Chrome, Firefox, Edge и Opera; на устройствах Roku; на Amazon Fire TV и Fire OS; на Sony PlayStation; и на подавляющем большинстве смарт-ТВ и Blu-ray-плееров на Samsung Tizen или LG webOS. Это DRM за воспроизведением в Google Play, YouTube, Netflix, Disney+, Amazon Prime Video, Max, Hulu, Peacock и Paramount+.
Этот охват – причина, по которой Widevine обычно интегрируют первым: разработчик может проверить его прямо во вкладке Chrome на своём ноутбуке. Но тот же факт прячет ловушку для новичков, поэтому проговорим её сейчас и запомним: Widevine не работает в Safari от Apple, на iOS и на Apple TV. (Google предлагает отдельную клиентскую библиотеку Widevine, которую можно встроить внутрь iOS-приложения, но встроенный в iPhone браузер Safari и системный видеоплеер используют FairPlay, а не Widevine.) Сборка только под Widevine, потому что он работает в Chrome, – самый частый способ выпустить плеер, который молча падает на каждом устройстве Apple.
Уровни безопасности Widevine: L1, L2, L3
Widevine не даёт одинаковую стойкость везде. Он определяет три уровня безопасности, описывающих, какая доля защиты выполняется в защищённом от вскрытия железе, а какая – в обычном софте. Уровень – это не серверная настройка; это свойство устройства, зашитое на производстве, и оно определяет, насколько правообладатель доверяет устройству.
- Widevine L1 – высший уровень. На устройстве L1 и расшифровка, и обработка ключей происходят внутри Trusted Execution Environment (TEE) – отдельной защищённой области чипа, работающей в стороне от основной операционной системы, так что даже скомпрометированная ОС не прочитает ни ключи, ни расшифрованные кадры. Расшифрованное видео идёт защищённым путём прямо на экран. L1 – это то, что включает воспроизведение премиум-контента в HD и 4K. Большинство современных флагманов Android и большинство нынешних смарт-ТВ – L1.
- Widevine L2 – гибридный уровень: криптооперации идут в TEE, но обработка видео может происходить вне него. На практике L2 почти не встречается в потребительских устройствах, и его можно в основном игнорировать.
- Widevine L3 – только программный. Аппаратного TEE нет; защита работает в обфусцированном, усиленном софте, который в итоге живёт в обычной памяти. Это уровень в каждом десктопном браузере – Chrome, Firefox, Edge – и на дешёвых или старых устройствах. Поскольку защита слабее, студии ограничивают то, что может играть L3, – обычно стандартным разрешением (около 480p, иногда до 720p).
Практический итог – правило, которое вы встретите снова с двумя другими системами: уровень безопасности, который сообщает устройство, и определяет разрешение, которое студия позволит на него стримить. Пользователь на телефоне L1 может получить 4K; тот же аккаунт во вкладке десктопного Chrome (L3) держится на 480p для того же тайтла – не потому что сеть не тянет больше, а потому что лицензия правообладателя запрещает отправлять премиум-разрешение в программное окружение. Механику «уровень → разрешение» мы разбираем подробнее ниже, потому что все три вендора работают так.
В вебе Widevine доходит до браузера через Content Decryption Module (CDM) – доверенный компонент, который Google поставляет внутри Chrome, Firefox и Edge и который выполняет расшифровку. Мы вернёмся к CDM, когда посмотрим, как плеер выбирает DRM на лету; пока запомните, что браузерный Widevine – это софтовый L3, и именно поэтому студийное 4K не играет в обычной вкладке браузера.
Microsoft PlayReady: рабочая лошадка Windows, консолей и ТВ
PlayReady – DRM от Microsoft, и хотя потребители редко слышат его имя, это одна из самых широко развёрнутых систем защиты в мире. Это нативный DRM на Windows и в браузере Microsoft Edge, на консоли Xbox и – что важно – на огромной доле смарт-ТВ, ТВ-приставок и устройств платного ТВ мира. Операторы и производители ТВ поставляют PlayReady годами, поэтому очень многие устройства в гостиной говорят на нём.
PlayReady сильно пересекается с Widevine на смарт-ТВ: многие телевизоры на Tizen и webOS поставляют обе системы и отдают их веб-приложениям ТВ через один и тот же API браузера. Пересечение не избыточно – оно даёт платформе выбор, какую лицензию выдать конкретному ТВ, и оно важно, когда поддержка одной системы на устройстве меняется. Самый ясный текущий пример – меняющаяся ситуация с PlayReady на ТВ Samsung Tizen, датированная, привязанная к устройству миграция, которую платформы обязаны отслеживать и тестировать на реальном железе; ей посвящена отдельная статья миграция PlayReady на Samsung 2026, потому что это именно тот вендорский сдвиг, который ломает воспроизведение, если за ним не следить.
Уровни безопасности PlayReady: SL150, SL2000, SL3000
Схема уровней PlayReady точно определена в документации Microsoft и аккуратно ложится на разделение «софт против железа», которое вы только что видели у Widevine.
- SL150 – уровень разработки и тестирования. Ничего по сути не защищено; Microsoft прямо говорит, что он не для коммерческого контента. Считайте его «выключенным».
- SL2000 – продакшен-уровень на софте. Ключи и секреты защищены программным (или смешанным программно-аппаратным) усилением. PlayReady называет клиентов SL2000 «Software-DRM». Это рабочий уровень для многих приложений и старых устройств, примерно эквивалент Widevine L3 по тому, что студии доверят ему играть.
- SL3000 – аппаратный уровень, введённый с PlayReady 3.0 в 2015 году. Ядро стека PlayReady выполняется внутри Trusted Execution Environment процессора, ключи и расшифрованные сэмплы защищены железом. PlayReady называет клиентов SL3000 «Hardware-DRM», и SL3000 – это то, что разблокирует HD, UHD и HDR высокоценного контента; аналог Widevine L1.
Что делает модель PlayReady особенно ясной – это как уровень применяется, и это стоит понять, потому что демистифицирует всю идею «студия решает ваше разрешение». Каждый клиент PlayReady несёт сертификат, выданный на производстве, где указан его уровень безопасности. Когда устройство просит у вашего сервера лицензий ключ, оно присылает этот сертификат. Ваш сервер лицензий читает уровень и может выдать разную лицензию в зависимости от того, что видит, – более богатую, с большим разрешением, устройству SL3000; ограниченную – устройству SL2000. Документация Microsoft описывает ровно это: сервер лицензий «выдаёт разные лицензии разным клиентам», так что «клиент SL3000 получит доступ к более высокому разрешению, чем клиент SL2000». Каждая лицензия также несёт значение MinimumSecurityLevel, и клиент отказывается использовать лицензию, чей минимум он не дотягивает. Лимит разрешения – не размытая политика, а число, которое ваш сервер лицензий ставит на каждый запрос, исходя из сертификата, предъявленного устройством.
Apple FairPlay: цена входа в экосистему Apple
FairPlay Streaming – DRM от Apple, и он самый ограниченный из трёх в двух аспектах, которые формируют любой кросс-платформенный план.
Во-первых, FairPlay – единственный DRM, работающий на устройствах Apple, и Apple не лицензирует его для работы где-либо ещё. Safari, iPhone, iPad, Mac и Apple TV защищают видео FairPlay и только FairPlay – вы не запустите Widevine или PlayReady в защищённом видеопути на железе Apple. И вы не запустите FairPlay на ТВ Samsung или телефоне Android. FairPlay встроен в операционные системы Apple на системном уровне – iOS, iPadOS, macOS, tvOS и watchOS – и доходит до веба только через реализацию в Safari. Практический смысл прямой: если хоть сколько-нибудь заметная доля вашей аудитории на устройствах Apple (а для большинства потребительских сервисов это большая доля), FairPlay не опционален. Это пошлина за вход в экосистему Apple вообще.
Во-вторых, FairPlay привязан к конкретному формату доставки и конкретной схеме шифрования. Защищённая доставка Apple использует HTTP Live Streaming (HLS) – протокол стриминга, определённый Apple (IETF RFC 8216), – и FairPlay шифрует медиа схемой cbcs из Common Encryption: AES в режиме сцепления блоков с паттерном, определённый в ISO/IEC 23001-7. Этот единственный факт – самое дорогое, что можно сделать неправильно во всём multi-DRM, поэтому он получает собственную врезку ниже. FairPlay не предлагает опубликованной лестницы именованных уровней безопасности, как Widevine и PlayReady; на современном железе Apple защита аппаратная по архитектуре, на собственном защищённом кремнии Apple, а правила разрешения идут из лицензирования контента, а не из публичной таблицы уровней.
Как FairPlay доставляет ключ: SPC и CKC
У рукопожатия ключа FairPlay свой словарь, и вы услышите эти аббревиатуры в любом разговоре о воспроизведении на iOS, поэтому закрепим их сейчас. Сначала плеер получает выданный Apple сертификат. С его помощью устройство генерирует Server Playback Context (SPC) – зашифрованный блоб, доказывающий, что запрос идёт от настоящего устройства Apple, и указывающий, чего оно хочет. Ваш сервер лицензий (выполняющий логику Key Security Module от Apple) получает SPC и возвращает Content Key Context (CKC) – зашифрованный пакет, несущий ключ контента обратно на устройство. Имена отличаются от других систем, но форма – та же идея, что мы нарисовали в зачем нужен DRM: устройство доказывает, что ему можно доверять, и только тогда сервер отдаёт ключ, упакованный так, что ничто вне защищённого модуля его не прочитает. Общая механика серверов лицензий и доставки ключей для всех трёх систем – в статье серверы лицензий и доставка ключей.
Ошибка, ломающая Apple: `cenc` против `cbcs`
Вот самая частая и самая дорогая ошибка в multi-DRM, и живёт она на стыке FairPlay с двумя другими. Common Encryption (ISO/IEC 23001-7) – стандарт, позволяющий одному зашифрованному файлу кормить несколько систем DRM, – определяет две схемы шифрования, которые невзаимозаменяемы:
- cenc использует AES в режиме счётчика (AES-CTR).
- cbcs использует AES в режиме сцепления блоков с паттерном (AES-CBC).
FairPlay поддерживает только cbcs. Исторически Widevine и PlayReady использовали cenc, поэтому ранний разработчик резонно зашифровал бы всё через cenc, увидел бы воспроизведение на Android и Windows и выпустил релиз – только чтобы обнаружить, что каждое устройство Apple показывает чёрный экран, потому что FairPlay не читает cenc вообще. Сбой невидим, пока кто-то не протестирует на реальном iPhone, – поэтому он так часто доживает до продакшена.
Решение и конвергенция, к которой пришла вся индустрия, – «cbcs везде». Современные Widevine и PlayReady оба поддерживают cbcs (собственная таблица схем Google перечисляет cbcs для текущих Android, Chromecast, смарт-ТВ, десктопного и мобильного Chrome, Firefox и Opera), поэтому можно зашифровать каталог один раз через cbcs, упаковать как CMAF и обслуживать все три системы из тех же файлов. Глубокая механика – почему существуют две схемы, что делает паттерн в cbcs и как произошла конвергенция – тема статьи CENC, CTR и CBCS: общее шифрование простыми словами. Для этой статьи несите одно правило: стандартизируйтесь на cbcs с первого дня, иначе будете переделывать упаковку при первом же чёрном экране на iPhone.
Уровни безопасности и лимит разрешения: одна логика, три словаря
Вы уже видели уровни безопасности дважды – L1/L3 у Widevine и SL3000/SL2000 у PlayReady, – а аппаратная-по-архитектуре модель FairPlay – третья версия той же идеи. Сведём их вместе, потому что именно эта концепция напрямую управляет тем, что реально видят ваши пользователи.
Базовый принцип одинаков у всех трёх вендоров: чем больше защиты выполняется в защищённом от вскрытия железе, тем больше правообладатель доверяет устройству и тем выше разрешение, которое он разрешит. Аппаратная защита (Widevine L1, PlayReady SL3000, FairPlay на современном кремнии Apple) зарабатывает HD и 4K. Только программная защита (Widevine L3, PlayReady SL2000) обычно ограничена стандартным разрешением. Лимит – не технический предел софта; это контрактное правило, которое навязывает правообладатель, потому что программное окружение атаковать легче аппаратного, а утёкший 4K-мастер куда ценнее утёкшей копии 480p.
Здесь модель угроз из предыдущей статьи становится конкретным продуктовым ограничением. Разложим её – и картина ясна:
| Уровень защиты | Где идёт расшифровка | Типичное разрешение, разрешаемое студией | Примеры устройств |
|---|---|---|---|
| Аппаратная (Widevine L1 / PlayReady SL3000 / FairPlay на кремнии Apple) | Внутри аппаратного Trusted Execution Environment | До 4K / UHD / HDR | Современные флагманы Android, большинство нынешних смарт-ТВ, iPhone/iPad/Apple TV, Xbox |
| Только программная (Widevine L3 / PlayReady SL2000) | В усиленном софте, обычная память | Обычно лимит SD (~480p), иногда 720p | Десктопные Chrome/Firefox/Edge, старые или бюджетные устройства |
| Только тест (PlayReady SL150) | Не защищено | Нет – не для коммерческого контента | Сборки для разработки |
Короткий разобранный пример делает бизнес-эффект осязаемым, потому что команды регулярно недооценивают, какая доля их аудитории ограничена. Пусть у сервиса 1 000 000 активных устройств в месяц, и разбивка такая: 60% – приложения на телефонах и ТВ с аппаратным DRM, 40% – зрители в десктопных браузерах на программном L3/SL2000. Если премиум-тайтл лицензирован для 4K только при аппаратном воспроизведении, то:
устройства, видящие 4K = 1 000 000 × 60% = 600 000
устройства с лимитом ~480p = 1 000 000 × 40% = 400 000Четыреста тысяч ваших зрителей – десктопная браузерная аудитория – контрактно держатся на 480p для этого тайтла независимо от скорости их соединения. Это не баг, который надо чинить; это правило, которое лицензия налагает на программную защиту. Знание этого заранее меняет продуктовые решения: именно поэтому премиум-сервисы подталкивают пользователей к приложениям (аппаратный DRM), а не к браузеру, и поэтому «почему веб-плеер только в SD?» отвечается в контракте, а не в коде. Браузерный стек DRM и его пределы разобраны в Encrypted Media Extensions и браузерный стек DRM.
Карта «устройство → DRM»: кто что покрывает
Теперь соберём территории в одну карту, потому что именно эту таблицу вы реально будете использовать при оценке сборки. Ключевой столбец – последний: какой DRM нужно реализовать, чтобы дотянуться до устройства. Обратите внимание на жёсткие исключения: устройства Apple принимают только FairPlay, а Xbox – только PlayReady, поэтому единой системы, покрывающей весь список, нет.
| Устройство / платформа | Widevine | PlayReady | FairPlay | Что нужно поддержать, чтобы дотянуться |
|---|---|---|---|---|
| Телефоны и планшеты Android | Да | – | – | Widevine |
| Chrome / Firefox / Edge / Opera (десктоп) | Да | Edge также | – | Widevine (PlayReady на Edge) |
| Windows (нативные приложения) | – | Да | – | PlayReady |
| Safari (macOS) | – | – | Да | FairPlay |
| iPhone / iPad / Apple TV | – | – | Да | FairPlay |
| Смарт-ТВ Samsung Tizen / LG webOS | Да | Да | – | Widevine или PlayReady |
| Roku | Да | Да (на многих) | – | Widevine или PlayReady |
| Amazon Fire TV / Fire OS | Да | – | – | Widevine |
| Xbox | – | Да | – | PlayReady |
| Sony PlayStation | Да | – | – | Widevine |
Прочитайте таблицу сверху вниз – и вывод неизбежен. Чтобы покрыть Android и большинство браузеров, нужен Widevine. Чтобы покрыть Windows, Xbox и большой кусок ТВ – PlayReady. Чтобы покрыть что угодно с логотипом Apple – FairPlay, и замены нет, потому что Apple не лицензирует FairPlay никому для использования в другом месте и не допускает ничего иного на собственных устройствах. Поэтому потребительский сервис, целящийся в «каждый экран», приходит ко всем трём. Избегают одной-двумя только сервисы с намеренно узкой целью по устройствам – корпоративный инструмент только под Windows-и-Edge (один PlayReady) или приложение только под Android (один Widevine). Для всех остальных карта говорит: multi-DRM.
Как плеер на самом деле выбирает нужный DRM
Резонный вопрос на этом этапе: если есть три несовместимые системы, должно ли приложение определять устройство и запускать три разных плеера? Нет – и причина в едином браузерном стандарте, который делает код плеера в основном DRM-независимым. Этот стандарт – Encrypted Media Extensions (EME), спецификация W3C, определяющая общий способ для веб-страницы говорить с тем DRM, что есть на устройстве, без нужды знать внутренности каждой системы.
EME работает через key systems, каждая из которых обозначена строкой. Плеер спрашивает браузер, по сути: «какую из этих вы поддерживаете?» – а браузер отвечает, исходя из устройства:
- com.widevine.alpha – Google Widevine
- com.microsoft.playready.recommendation – Microsoft PlayReady
- com.apple.fps – Apple FairPlay Streaming
Доверенный компонент расшифровки, которым управляет EME, – это Content Decryption Module (CDM): CDM Widevine в Chrome, PlayReady в Edge, FairPlay в Safari. Задача плеера – предложить свой список поддерживаемых key systems и дать браузеру выбрать ту, что реально есть на устройстве. Вот форма этого согласования, упрощённая до сути:
// Спрашиваем браузер, какой DRM поддерживает это устройство, в порядке предпочтения.
const config = [{
initDataTypes: ["cenc"],
videoCapabilities: [{ contentType: 'video/mp4; codecs="avc1.42E01E"' }]
}];
async function pickKeySystem() {
// Пробуем каждую систему; браузер разрешит только ту, что реально есть на устройстве.
for (const keySystem of [
"com.widevine.alpha", // Android, Chrome, большинство ТВ
"com.microsoft.playready.recommendation", // Windows, Edge, Xbox, многие ТВ
"com.apple.fps" // Safari, iPhone, iPad, Apple TV
]) {
try {
await navigator.requestMediaKeySystemAccess(keySystem, config);
return keySystem; // первое совпадение выигрывает — родной DRM устройства
} catch (e) { /* здесь не поддерживается; пробуем следующий */ }
}
throw new Error("Нет поддерживаемого DRM на этом устройстве");
}В реальных сборках вы редко пишете даже столько сами: open-source-плееры вроде Shaka Player, dash.js и hls.js, а также нативные фреймворки ExoPlayer (Android) и AVPlayer (Apple) делают согласование key system за вас. Главное концептуально: вы пишете один плеер под EME, даёте ему эндпойнты серверов лицензий для каждой из трёх систем, а устройство выбирает свой DRM. Браузерные детали поведения EME и CDM – тема статьи Encrypted Media Extensions и браузерный стек DRM, а нативная сторона – AVPlayer с FairPlay на iOS, ExoPlayer с Widevine на Android – в воспроизведение на iOS и Android.
Почему карта толкает к multi-DRM – и почему это дешевле, чем кажется
Сложите кусочки – и архитектура напишется сама. Вам нужны все три системы, чтобы дотянуться до всех устройств. Каждой нужен свой эндпойнт лицензий. И – факт, спасающий бюджет, – вам не нужно шифровать контент три раза, потому что Common Encryption со схемой cbcs позволяет зашифровать медиа один раз и выдавать лицензии Widevine, PlayReady или FairPlay из тех же файлов в зависимости от устройства. Шифруем один раз, лицензируем многократно. Этот паттерн – multi-DRM, и он базовый современный дизайн для любой платформы со смешанной аудиторией.
Форму стоимости multi-DRM стоит проговорить прямо, потому что страх («три DRM должны стоить втрое») неуместен. Хранение и кодирование не утраиваются – вы храните одну копию, зашифрованную cbcs и упакованную в CMAF, а не три. Вы добавляете интеграционную работу (подключить три сервиса лицензий и протестировать на реальных устройствах трёх экосистем) и плату за лицензию от multi-DRM-сервиса, которая мала относительно того, что она открывает. Репрезентативную версию этой арифметики мы разобрали в зачем нужен DRM – порядка $1 500 в месяц за лицензии для сервиса на 100 000 подписчиков, доля процента от выручки защищённого каталога. Полное решение build-vs-buy для слоя DRM и то, как один multi-DRM-сервис выдаёт все три типа лицензий из одного процесса, – в следующей статье: multi-DRM: один workflow, все устройства.
Частая ошибка: считать, что хватит одного DRM или одного уровня
Ошибки в этой области группируются в три предотвратимые, и назвать их – самый быстрый способ никогда их не совершать.
Первая – сборка под один DRM с обнаружением пробелов в продакшене. Почти всегда это «протестировали в Chrome с Widevine и выпустили», за чем следуют чёрные экраны на каждом iPhone. Лекарство – начинать с карты «устройство → DRM», а не с того, что было проще протестировать: сначала выпишите целевые устройства, считайте нужные системы – и увидите все три заранее, ещё до кода.
Вторая – шифрование только cenc, которое молча ломает FairPlay. Команда шифрует старой схемой счётчика, всё играет везде, кроме Apple, и сбой прячется до теста на iPhone. Лекарство – стандартизироваться на cbcs Common Encryption с первой же упаковки, чтобы один набор файлов обслуживал все три системы.
Третья – игнорирование уровней безопасности и сюрприз с лимитом разрешения. Команда считает «DRM включён, значит всё хорошо», а потом не понимает, почему студийное 4K отказывается играть в десктопном браузере или почему бюджетный ТВ стримит только SD. Лекарство – относиться к уровню безопасности как к первоклассному факту о каждом устройстве: аппаратные уровни (Widevine L1, PlayReady SL3000, FairPlay на кремнии Apple) для HD и 4K; программные (Widevine L3, PlayReady SL2000) ограничены около SD по лицензии. Если правообладатель требует аппаратного воспроизведения для 4K, ваши программные устройства просто не получат 4K, и это факт планирования, а не баг.
Нить через все три – одна дисциплина: идите от устройств и условий лицензии, выводите нужные системы DRM и уровни безопасности и стройте под это – никогда наоборот.
Чем здесь помогает Фора Софт
Карта трёх DRM – место, где охват устройств платформы, её контентные сделки и код плеера должны согласоваться, и неверное допущение в начале оборачивается чёрным экраном на целом классе устройств или каталогом, который студия не лицензирует. Фора Софт строит ПО для видеостриминга, OTT/Internet TV, e-learning и телемедицины с 2005 года, на счету 250+ выпущенных проектов для 400+ клиентов, и именно эта задача – дотянуться до каждого экрана на том уровне безопасности, которого требует каждая контентная сделка, – проходит через эту работу: сопоставить целевые устройства клиента с нужной комбинацией Widevine, PlayReady и FairPlay, стандартизироваться на cbcs Common Encryption, чтобы один пакет обслуживал все три, подключить три эндпойнта лицензий в плееры на вебе, мобильных и ТВ и подобрать уровень безопасности каждого устройства под разрешение, которое разрешает его лицензия. Когда медиакомпании нужно воспроизведение, работающее с первого раза по всей матрице устройств, – а не только в браузере, где случайно тестировал разработчик, – этот кросс-экосистемный инжиниринг защиты контента и есть то, что мы приносим.
Ключевые выводы
- Существуют три несовместимые системы DRM: Widevine (Google), PlayReady (Microsoft), FairPlay (Apple).
- Ни одна не покрывает все устройства; устройства Apple признают только FairPlay, без замены.
- Widevine охватывает больше всего платформ – Android, браузеры, большинство ТВ – но никогда Safari или iOS.
- Уровни (Widevine L1/L3, PlayReady SL3000/SL2000) задают разрешение: железо для 4K, софт около SD.
- FairPlay нужна схема cbcs; шифрование только cenc молча ломает всё воспроизведение Apple.
- Один EME-плеер предлагает три key system; устройство выбирает свой DRM – поэтому пишете один раз.