Содержание статьи +
- TL;DR
- Почему это важно
- Что значит «DRM» в стриминге
- Common Encryption (CENC): стандарт под стандартами
- Три DRM: практический обзор
- CMAF – выигрыш единой упаковки
- CDM, EME и путь в браузере
- Лицензионные серверы и рынок DRM-as-a-Service
- Дерево решений: какая DRM и когда
- Частая ошибка: рассматривать DRM как гарантию безопасности
- Математика цены: соединяем цифры
- Где Фора Софт вписывается
- Ключевые тейкавеи
- Что почитать дальше
TL;DR
DRM (digital rights management) – это замок на вашем премиальном видео; CENC (common encryption) – стандарт замка, который позволяет одному и тому же зашифрованному файлу открываться тремя разными ключами: Google Widevine на Android и Chrome, Apple FairPlay на iOS и Safari, Microsoft PlayReady на Windows, Xbox и smart-TV. Появление CMAF (Common Media Application Format) со схемой шифрования cbcs в 2018 году схлопнуло старый воркфлоу «две упаковки на каждый ролик» в одну – единая зашифрованная битрейтная лестница теперь кормит и HLS-, и DASH-плееры. В 2026 году multi-DRM – это не выбор, а базовая планка: Widevine плюс FairPlay даёт ~95% охвата устройств, все три вместе – выше 99%, а недавняя утечка сертификатов PlayReady SL3000 и давний компромисс Widevine L3 делают трезвый разговор об уровнях безопасности и принуждении HDCP важнее, чем выбор конкретного «бренда» DRM. В статье разобраны три системы, лежащий под ними стандарт CENC, воркфлоу упаковки в Shaka Packager и Bento4, экономика лицензионных серверов и дерево решений «с чего начать».
Почему это важно
Если ваш продукт распространяет платное видео, студии и правообладатели первым делом спросят: какие DRM вы поддерживаете и до какого уровня безопасности. Ответили не так – не сможете легально стримить Netflix-grade контент, не сможете продавать в Голливуд, не сможете отгружать 4K Ultra HD на тех платформах, где 4K реально приносит деньги. Ответили правильно – стоимость multi-DRM-стека (лицензии license-сервера, время на упаковку, интеграционная работа) растворяется в шуме счёта за CDN. Статья – для продакт-менеджеров, фаундеров и инженерных лидов, которым нужно оценить multi-DRM-вендора или построить пайплайн упаковки, который выдержит следующий codec generation. Это не реклама конкретного провайдера. Рекомендации конкретны, цифры актуальны на 2026 год, диаграммы делают подвижные части видимыми без шестимесячного proof of concept.
Что значит «DRM» в стриминге
До того как назвать три системы, зафиксируем термин. DRM – это контролируемая система распространения ключей и принуждения политик: она решает, кому разрешено расшифровать кусок видео, на каком устройстве, в каком качестве, на какой срок. Сам зашифрованный видеофайл между Widevine и FairPlay не меняется – это стандартный MP4 с маленьким боксом шифрования спереди. Что меняется – это протокол, по которому плеер просит у лицензионного сервера ключ расшифрования, криптографическая идентичность, которую плеер должен доказать, и защищённый путь, по которому расшифрованные пиксели идут к экрану.
Эта работа сидит между двумя более знакомыми частями. Сверху – ваш packager: он берёт закодированные renditions (H.264, H.265, AV1) с вашего транскодера и эмитит HLS- и DASH-сегменты с наложенным слоем шифрования. Снизу – плеер и платформа: ОС или браузер хостят CDM (content decryption module), который общается с лицензионным сервером, получает ключ и расшифровывает каждый сегмент по мере поступления. DRM – это контракт между этими двумя концами. (Контекст по входной упаковке смотрите в нашей статье про контейнеры и статье про облачный транскодинг. По кодекам – сравнительная таблица кодеков.)
Почему их три, а не одна: крупные платформодержатели хотят контроля над защищённым путём на своём собственном железе. Google поставляет Widevine внутри Chrome и Android. Apple поставляет FairPlay внутри iOS, macOS, tvOS и Safari. Microsoft поставляет PlayReady внутри Windows, Xbox и большинства smart-TV. Каждая экосистема отказывается хостить чужой CDM на уровне hardware root of trust, поэтому сервис, который хочет дотянуться до каждого экрана, должен зашифровать контент так, чтобы все три вендора это поняли, а затем доставить три разные лицензии трём разным CDM в момент воспроизведения. Этот общий слой шифрования и есть CENC, и это самый важный стандарт в статье.
Common Encryption (CENC): стандарт под стандартами
Common encryption определена стандартом ISO/IEC 23001-7, сейчас в третьей редакции 2023 года. Задача стандарта узкая, но важная: задать, как шифровать payload-семплы внутри контейнера ISOBMFF (ISO base media file format), чтобы любая DRM-система могла прицепить собственные метаданные лицензионного запроса, не меняя само шифрование. Один зашифрованный файл – много лицензионных путей.
Стандарт определяет четыре protection schemes, адресуемых четырёхсимвольным кодом, записанным в боксе schi (scheme information) файла. Первые два используют AES в режиме счётчика (CTR), вторые два – AES в режиме сцепления блоков шифра (CBC). Четырёхсимвольные коды – cenc, cens, cbc1, cbcs. В продакшене вы реально встретите два – cenc и cbcs.
| Схема | Режим шифра | Паттерн | Где используется |
|---|---|---|---|
| cenc | AES-128 CTR | Полный семпл, без паттерна | DASH на Widevine и PlayReady до 2018 |
| cens | AES-128 CTR | Sub-sample паттерн | Вариант cenc для экономии полосы, редко |
| cbc1 | AES-128 CBC | Полный семпл, без паттерна | Исходный CBC-режим, фактически устарел |
| cbcs | AES-128 CBC | 1:9 sub-sample паттерн | HLS на FairPlay; новая общая схема |
В 2026 году значение имеет режим cbcs. Он шифрует один блок из каждых десяти и оставляет девять остальных в чистом виде – этого математически достаточно, чтобы битстрим был непроигрываем без ключа, но дёшево настолько, что аппаратные декодеры на телефонах не захлёбываются на расшифровке каждого байта. Apple требовала cbcs для FairPlay с первого дня; Google добавила поддержку cbcs в Widevine в 2018; Microsoft добавила поддержку cbcs в PlayReady в том же году. С 2018 года один CMAF-файл, зашифрованный по cbcs, играется на Widevine, PlayReady и FairPlay одинаково. До этого изменения каждый ролик упаковывали дважды – cenc для DASH, cbcs для HLS – и хранили на origin две копии. Это удваивало стоимость хранения и время упаковки. Сегодня вы отгружаете один набор сегментов, два манифеста и три лицензии – и спите спокойнее.
Кусок метаданных, который делает multi-DRM возможным, – бокс pssh (protection system specific header). Бокс pssh несёт 16-байтный system ID, который говорит плееру «этот blob для Widevine» или «этот blob для PlayReady», плюс вендор-специфичный payload, который соответствующий CDM умеет парсить. Multi-DRM-файл содержит один pssh для Widevine (system ID EDEF8BA9-79D6-4ACE-A3C8-27DCD51D21ED), один для PlayReady (9A04F079-9840-4286-AB92-E65BE0885F95) и один для FairPlay (94CE86FB-07FF-4F43-ADB8-93D2FA968CA2); плеер итерирует их, выбирает тот, что понимает его CDM, остальные игнорирует. Web-плееры используют API EME (Encrypted Media Extensions) консорциума W3C; нативные iOS-плееры используют вызовы FairPlay из AVFoundation; нативные Windows-плееры – рантайм PlayReady.
Три DRM: практический обзор
Widevine – рабочая лошадь Google
Widevine – самая распространённая DRM в мире по количеству устройств. Google поставляет её внутри каждого Android-устройства с Google Mobile Services, внутри Chrome и Chromium-браузеров на всех настольных платформах, внутри экосистем Cast и Android TV. Это покрытие: Android (~3 миллиарда устройств в 2026), Chrome на десктопе (~2 миллиарда пользователей), большинство smart-TV не от Apple и не от LG, Chromecast.
У Widevine три уровня безопасности – L1, L2, L3. Разница в том, где происходит расшифровка и где живут расшифрованные кадры.
L1 – самый строгий уровень. И криптография (обработка ключей, расшифровка), и обработка видео (декодирование, скейлинг, наложение во фреймбуфер) происходят внутри TEE (trusted execution environment) – аппаратно-изолированной области центрального процессора устройства, которую ОС не может прочитать. На Android TEE обычно реализован поверх ARM TrustZone. Студии требуют L1 для 1080p и 4K-стриминга, потому что расшифрованные кадры никогда не покидают железо. Без L1 Netflix на Android режет вас на 540p.
L2 – промежуточный уровень: криптография в TEE, но декодированное видео может его покидать. L2 существует в основном как исторический артефакт. Сегодня мало устройств уходит с конвейера на L2.
L3 – самый низкий уровень. И криптография, и обработка видео происходят в софте, вне любого TEE. L3 – это то, что вы получаете на десктопном Chrome на обычном x86-ПК, на Android-эмуляторе, на старом Android-телефоне, у которого нет драйвера TEE. L3 – это и место, где живут известные слабости: исследователи демонстрируют практические атаки на извлечение ключа из white-box-реализации Widevine L3 с 2019 года, и инструменты класса «Widevine dump», которые вытаскивают ключи из L3-сессий, свободно ходят по сети. Крупные студии реагируют, ограничивая L3 разрешением 480p, – поэтому ваш десктопный Chrome не может стримить Netflix в HD без браузера Microsoft Edge (который на Windows использует PlayReady).
Лицензионный сервер говорит по Google-определённому протоколу поверх HTTPS; тело запроса – сериализованный Protocol Buffer, который плеер строит из бокса pssh и токена идентичности пользователя. Ответы лицензии включают KIDs, сами ключи и usage policy: на сколько действительна лицензия, требуется ли HDCP (High-bandwidth Digital Content Protection) на выходе, можно ли её сохранять для офлайна. Widevine не берёт per-license fee с оператора сервиса; цена идёт вашему DRM-as-a-Service-вендору (подробнее ниже).
FairPlay Streaming – обязательный замок Apple
FairPlay Streaming (FPS) – DRM Apple. Поставляется внутри iOS, iPadOS, macOS, tvOS, watchOS и Safari, и это единственная DRM, которую Apple разрешает использовать для шифрования видео на устройствах Apple. На iOS нет Widevine, нет PlayReady, нет стороннего CDM – если вы хотите отгружать зашифрованное видео на iPhone, вы отгружаете FairPlay.
Шифровальная сторона FairPlay проста по дизайну: AES-128 в режиме CBC с subsample-шифрованием, адресуемая кодом cbcs. Apple использует HLS как нативный формат упаковки; зашифрованные сегменты несут тег #EXT-X-KEY с METHOD=SAMPLE-AES (старая разновидность) или, в CMAF-HLS, тег #EXT-X-SESSION-KEY, указывающий на URL доставки ключа с KEYFORMAT="com.apple.streamingkeydelivery".
Поток лицензионного запроса включает ключевые серверы Apple как промежуточный авторитет. Ваше приложение отправляет content-key context (SPC) blob на ваш key server; ваш key server форвардит его на ключевой сервер Apple, который валидирует запрос, возвращает content-key response (CKC); ваш key server возвращает CKC приложению, которое передаёт его системному CDM, который расшифровывает сегменты. Ключевой сервер Apple – это trust root: вы не можете запустить FairPlay без выданного Apple application secret key и сертификата, которые получаете, подписав FairPlay Streaming Deployment Package agreement на Apple Developer.
Поддержка кодеков отслеживает дорожную карту Apple. H.264, H.265 (HEVC) и AV1 – все поддерживаются в FairPlay-защищённых стримах на платформах Apple, где кодек реализован: аппаратное декодирование AV1 пришло с чипом A17 Pro и универсально для iPhone 16 и новее. Dolby Vision и HDR10 поддерживаются как packaging metadata поверх любого зашифрованного кодека. То, что нельзя упустить: на 2026 год AVPlayer на iOS откажется проигрывать AV1-контент, если у устройства нет аппаратного AV1, даже если в ОС есть программный декодер. Планируйте бифуркацию реальности: AV1 уходит только на новые телефоны, fallback на H.264 или H.265 – везде.
Проверка реальности по FairPlay в 2026: SDK укреплялся стабильно десятилетие. Самая обсуждаемая слабость сегодня – не сам SDK, а мост SPC/CKC: если ваш key server возвращает CKC атакующему, который может повторить запрос, атакующий получает ключ. Привязывайте SPC-запросы к короткоживущим сессионным токенам, валидируйте application_id устройства, никогда не логируйте CKC.
PlayReady – рабочая лошадь Microsoft для set-top и TV
PlayReady – третья крупная DRM и та, которую чаще всего понимают неправильно. Microsoft поставляет PlayReady внутри Windows, Xbox, Microsoft Edge и – что важнее – внутри почти каждого smart-TV и set-top-box, выпущенного за последнее десятилетие. Samsung, Sony, LG (вместе со своей), Vizio, Roku, Amazon Fire TV, Comcast Xfinity, Sky Q: список доминирован PlayReady, потому что Microsoft лицензирует технологию TV-производителям на условиях, делающих её путём наименьшего сопротивления для connected-TV-ОС, которой нужен studio-grade content protection.
У PlayReady два активно используемых уровня безопасности – SL2000 и SL3000. SL2000 – это software-DRM-уровень: криптооперации выполняются в софте с обфускацией, но без аппаратной изоляции, и уровень достаточен для SD- и HD-контента у большинства студий. SL3000 – hardware-DRM-уровень, введённый в 2015 году вместе с PlayReady 3.0: криптооперации выполняются внутри TEE устройства, и этот уровень требуется большинством студий для 4K Ultra HD и HDR.
Самая значимая история по PlayReady в 2025 году – утечка сертификатов SL2000 и SL3000, опубликованная на GitHub под ником «Widevineleak». Microsoft подала takedown-запросы по серии SL3000 (высокоценные 4K-сертификаты), а Amazon Prime Video начал блокировать аккаунты, которые использовали утечённые сертификаты для скачивания защищённого контента. Microsoft не запросила takedown по SL2000-сертификатам – наблюдатели прочли это как тихое признание, что атакующая поверхность SL2000 уже широко известна. Практическое влияние на оператора сервиса в 2026 году небольшое: PlayReady остаётся единственной жизнеспособной DRM для контента, который должен играть на smart-TV и Xbox, и утечка не меняет математику шифрования – она меняет калькуляцию того, какие устройства студия считает «безопасными» для премиального контента.
Поток лицензионного запроса прямой по меркам 2026 года: плеер шлёт XML-сообщение запроса лицензии поверх HTTPS на ваш лицензионный сервер, сервер валидирует запрос против ваших бизнес-правил (подписка активна, регион разрешён, количество одновременных стримов в пределах лимита) и возвращает XML-ответ лицензии, подписанный PlayReady-сертификатом сервера. Microsoft требует использовать её серверы (или серверы Microsoft-сертифицированного вендора) – криптографическая цепочка доверия идёт обратно к корневому сертификату Microsoft.
CMAF – выигрыш единой упаковки
Common Media Application Format (CMAF) – это стандарт упаковки 2017 года от MPEG и совместного усилия Apple и Microsoft, который решил первородный грех стримингового видео: то, что HLS и DASH использовали несовместимые форматы сегментов. До CMAF вы упаковывали закодированный H.264-мастер дважды – один раз как серию MPEG-TS-сегментов для HLS, один раз как серию фрагментированных MP4-сегментов для DASH – и хранили оба на origin. Удвоенное хранение и удвоенная работа packager-а стоили реальных денег.
CMAF определяет один формат фрагментированных MP4 (fMP4), на который могут ссылаться и HLS-, и DASH-манифесты. С CMAF вы пишете один набор сегментов на origin и эмитите два тонких манифеста – .m3u8 для HLS и .mpd для DASH – указывающих на одни и те же сегменты. Добавьте cbcs-шифрование, и тот же набор сегментов расшифровывается Widevine, PlayReady и FairPlay одинаково. Совокупный результат – современный multi-DRM-воркфлоу: один кодек, одна упаковка, один зашифрованный набор на origin, два манифеста, три лицензии в момент воспроизведения.
Крупные packager-ы поставляют CMAF + cbcs как дефолт 2026 года. AWS Elemental MediaPackage эмитит CMAF по умолчанию для новых каналов. Энкодер Bitmovin защолчанию выдаёт CMAF для live- и per-title-воркфлоу. Open-source-тулинг – Shaka Packager и Bento4 – оба поддерживают CMAF + cbcs с multi-DRM-метаданными ключей одной командной строкой. Документация Apple Advanced HTTP Live Streaming переключилась с примеров MPEG-TS на примеры fragmented MP4 в 2020 году и теперь рассматривает CMAF как рекомендуемый путь.
# Shaka Packager — одна упаковка, multi-DRM (Widevine + PlayReady + FairPlay)
# Один кодек на входе, один набор CMAF на выходе, два манифеста, три license endpoints.
packager \
in=h264_1080p.mp4,stream=video,output=video_1080p.cmfv \
in=h264_720p.mp4,stream=video,output=video_720p.cmfv \
in=audio_aac.mp4,stream=audio,output=audio.cmfa \
--protection_scheme cbcs \
--enable_raw_key_encryption \
--keys label=video:key_id=$KID:key=$KEY \
--pssh "$WIDEVINE_PSSH,$PLAYREADY_PSSH,$FAIRPLAY_PSSH" \
--hls_master_playlist_output master.m3u8 \
--mpd_output stream.mpdCDM, EME и путь в браузере
Браузерный путь к расшифровке идёт через Encrypted Media Extensions (EME) консорциума W3C – JavaScript-API, который позволяет web-плееру говорить с CDM операционной системы. EME – рекомендация W3C 2017 года; каждый современный браузер реализует EME, и каждый современный HTML5-видеоплеер (Shaka Player, dash.js, hls.js с EME, Video.js с плагином eme, Bitmovin Player, JW Player) гоняет DRM через него.
Контракт EME небольшой. Плеер создаёт объект MediaKeys, привязанный к идентификатору key system – com.widevine.alpha для Widevine, com.microsoft.playready для PlayReady (или com.microsoft.playready.recommendation для SL3000-aware-сессий), com.apple.fps.1_0 для FairPlay в Safari. Элемент video стреляет событием encrypted, когда плеер скармливает ему зашифрованный сегмент; событие несёт initialization data – pssh-blob из файла. Плеер передаёт blob в generateRequest, браузер передаёт его в платформенный CDM, CDM эмитит событие message с вендор-кодированным payload запроса лицензии, плеер шлёт payload на лицензионный сервер, получает ответ, передаёт его в update. После update видео играется.
Хрупкая часть EME – таблица идентификаторов key system. Одна и та же DRM имеет разные идентификаторы на разных браузерах, различие SL2000 / SL3000 в PlayReady выражено как отдельный идентификатор, а реализация FairPlay в Safari годами выравнивалась с API остальных браузеров. Web-плееру в 2026 году нужен шаг проба key-system: спросите у браузера через navigator.requestMediaKeySystemAccess, какие системы он поддерживает, пройдитесь по приоритетному списку и откажитесь играть, если ни одна из поддерживаемых систем не подходит защищённому контенту.
Лицензионные серверы и рынок DRM-as-a-Service
Свой собственный multi-DRM-лицензионный сервер технически возможен. Google публикует протокол Widevine-лицензионного сервера, Microsoft публикует PlayReady-серверный тулинг, Apple распространяет reference-имплементацию FairPlay key server по developer-соглашению. На практике это почти никто не делает – операционная нагрузка по поддержанию актуальности трёх вендорских спецификаций, трёх ротаций сертификатов и трёх аудиторских циклов больше, чем стоимость покупки сервиса у вендора, который уже это делает для тысячи других клиентов.
Рынок DRM-as-a-Service в 2026 году доминирован горсткой специалистов: EZDRM, BuyDRM (с их продуктом KeyOS multikey), DRMtoday от Castlabs, Axinom, VdoCipher, DoveRunner. Цены сходятся на двух моделях: ежемесячная платформенная плата в диапазоне $100–$2,000 плюс per-license fee в диапазоне $0.001–$0.05, или плоский per-license fee без платформенного минимума. EZDRM публикует стартовую ставку $199.99 в месяц; BuyDRM стартует от $99 в месяц; Axinom и DRMtoday квотируют индивидуально под объём; enterprise-контракты уровня Netflix или Disney договариваются о плоских годовых в диапазоне $10,000–$50,000.
Выбор между вендорами на стартовом тире редко про цену – разница между $99 и $199 в месяц это шум по сравнению с ценой интеграции, которая не работает. Что важно: с какой CDN и каким плеером они интегрируются по умолчанию, есть ли у них фичи ротации ключей для live-каналов (каждые два часа, на границе события, по требованию), выдают ли они персистентные лицензии для download-and-go мобильных приложений, работает ли их лицензионный сервер в регионе ваших зрителей (latency имеет значение, когда первый license-запрос зрителя гейтит first frame), есть ли у них studio-recognized integrity attestation для Hollywood-tier-студий, с которыми вам придётся вести переговоры.
Самый частый сюрприз по стоимости – объём license-запросов на live-каналах с ротацией ключей. Стандартный 24-часовой live-канал, который ротирует ключи каждые два часа, генерирует 12 ротаций ключа на зрителя в день. Live-событие со 100 000 одновременных зрителей и часовой ротацией генерирует 100 000 license-запросов в час. При $0.005 за лицензию это $12 000 license-fees в день поверх вашего счёта за кодирование и CDN. Некоторые платформы кэпят месячный счёт против ожидаемого использования; другие позволяют вам кровоточить. Читайте контракт.
Дерево решений: какая DRM и когда
Прагматичный оператор сервиса в 2026 году не выбирает «лучшую DRM» – её не существует – а сопоставляет DRM-покрытие с охватом устройств и требованиями студий. Дерево ниже – то, что мы используем с клиентами в Фора Софт.
Если ваш сервис – потребительский ad-funded или freemium, и ваш контент не лицензирован у крупной студии, можно отгружать Widevine плюс FairPlay и считать задачу закрытой. Widevine покрывает Android, Chrome и большинство smart-TV. FairPlay покрывает iPhone, iPad, Apple TV и Safari. Вместе – это около 95% потребительского охвата устройств в большинстве западных рынков. Те 5%, которые вы упускаете, – старые smart-TV и set-top-box, у которых только PlayReady; для рекламного сервиса этот разрыв приемлем.
Если ваш сервис распространяет платное премиальное видео (SVOD, TVOD, EST) и вам нужно закрывать сделки с крупными студиями, отгружайте все три: Widevine, FairPlay и PlayReady. Студии этого потребуют. PlayReady – это билет на вход к connected-TV-партнёрам (Samsung, LG, Roku), и подделать его нельзя.
Если ваш сервис отгружает 4K Ultra HD, отгружайте только hardware-DRM. То есть Widevine L1 на Android, FairPlay на Apple (там hardware-backed по определению) и PlayReady SL3000 на Windows и TV. Software-DRM-уровни (Widevine L3, PlayReady SL2000) ограничивают разрешением 1080p или 540p в зависимости от студии. Заточите манифесты на принудительное соблюдение этого – ваш плеер должен отказываться предлагать 4K-renditions устройствам, которые рапортуют software-only DRM-сессию.
Если ваш сервис гоняет live-события с ротацией ключей, обработка license-запросов вашим DRM-as-a-Service-вендором становится доминирующей строкой стоимости. Договаривайтесь о per-license fees против прогноза количества зрителей, а не против исторического VOD-счёта. Live-событие со 100 000 зрителей и часовой ротацией генерирует за час больше license-запросов, чем ваш VOD-каталог за год.
Если ваш сервис отгружает iOS- или Android-мобильное приложение с офлайн-загрузкой – частый паттерн в образовательных и travel-приложениях – вам нужны персистентные лицензии с явной offline-policy. Widevine и PlayReady поддерживают персистентные офлайн-лицензии с настраиваемым expiration; FairPlay поддерживает их через FairPlay Streaming Offline, который требует отдельной конфигурации FairPlay key server. Тестируйте expiration-пути под airplane mode рано – это failure mode, который чаще всего упускается в QA.
Частая ошибка: рассматривать DRM как гарантию безопасности
Инженеры, новые в DRM, часто рассматривают технологию как гарантию того, что их контент не может быть пиратирован. Это не так. DRM – это гарантия того, что обычное пиратство тяжелее, чем заплатить за контент, и что владелец платформы может быстро прикрыть самые утечные пути расшифровки. Это не гарантия против решительного, хорошо ресурсированного атакующего.
Widevine L3 сломан с 2019 года, и надёжные инструменты извлечения свободно ходят. Сертификаты PlayReady SL2000 утекли в 2024, SL3000 – в начале 2025. FairPlay лучше держится на публике, но reference-имплементация Apple многократно реверсилась. 4K-мастер-копии каждого крупного стримингового тайтла появляются на пиратских сайтах в течение часов после релиза. Это не значит, что DRM бесполезна – это значит, что разговор про DRM должен быть честным про то, что она вам покупает.
DRM на самом деле покупает вам две вещи. Первое – она удовлетворяет контрактное обязательство, которое ваше content licensing agreement накладывает на вас («вы будете использовать индустриально-стандартную DRM, совместимую с MPAA secure delivery specification»), и это контрактное обязательство – то, что мешает студии засудить вас за нарушение. Второе – она делает соотношение cost-vs-benefit пиратирования вашего контента невыгодным для маржинального пользователя: людей, которые заплатили бы за ваш сервис, но переключились бы на бесплатную пиратскую копию, если бы её можно было получить за тридцать секунд. DRM ничего не делает с пиратскими сайтами, у которых уже есть ваш контент. Она много делает с casual-пользователем, который попросил бы друга AirDrop-нуть ему файл.
Маркетинговый фрейм «DRM предотвращает пиратство» вредит разговору. Честный фрейм: DRM поднимает стоимость пиратства достаточно, чтобы студии подписали licensing-агримент, а студии – это ворота между вами и жизнеспособным премиальным видеопродуктом.
Математика цены: соединяем цифры
Цифры без проработанного примера – шум. Возьмём SVOD-сервис с 50 000 MAU, в среднем 20 video starts на пользователя в месяц, 24-часовой VOD-каталог и 2-часовое live-событие раз в неделю со средними 8 000 одновременных зрителей. Прайсуем DRM-строку на трёх модельных контрактах: per-license $0.005 за лицензию, per-active-user $0.10 за MAU, плоский enterprise.
вход
monthly_active_users = 50 000
starts_per_user_month = 20
monthly_starts = 50 000 × 20 = 1 000 000
live_events_per_month = 4
live_concurrent_avg = 8 000
live_rotation_hourly = 1
live_event_hours = 2
per-license
vod_licenses = 1 000 000 (одна на старт)
live_licenses = 4 × 8 000 × 2 = 64 000 (ротация генерирует одну на зрителя в час)
monthly_licenses = 1 064 000
monthly_cost = 1 064 000 × $0.005 = $5 320
per-MAU
monthly_cost = 50 000 × $0.10 = $5 000
плоский enterprise
monthly_cost = $4 000 (договариваемый против прогноза)На этом масштабе все три модели приземляются в диапазоне $4 000 – $5 500 в месяц – выбор про предсказуемость, а не про абсолютную стоимость. Сервис со стабильными паттернами просмотра предпочитает плоский тариф; сервис со спайковым live-спросом предпочитает per-license (потому что тихие месяцы дешевле); сервис, монетизируемый per user, предпочитает per-MAU (потому что стоимость скейлится с выручкой). Строка, которую чаще всего упускают, – live-ротация: при часовой ротации 8 000 одновременных зрителей за два часа добавляют 16 000 license-запросов за событие, в четыре раза дороже per-start, чем эквивалентная VOD-аудитория.
Если ваша операционная маржа тонкая, выбивайте у DRM-вендора гибридный контракт: плоский тариф до прогнозного объёма, per-license overage сверху. Большинство вендоров согласятся на 12-месячный коммит.
Где Фора Софт вписывается
Фора Софт отгружала DRM-защищённое видео в OTT- и Internet-TV-продуктах, в e-learning-платформах с офлайн-загрузкой и в телемедицинских сервисах с регуляторно-обязательными ограничениями воспроизведения. Паттерн, который мы видим по вертикалям, один и тот же: инжиниринг недооценивает объём license-запросов на live-событиях, продакт недооценивает гочи iOS-only-офлайн-политики, а studio-facing legal team недооценивает, насколько важна аппаратная поддержка PlayReady SL3000 при переговорах с connected-TV-партнёром. Мы интегрируем Widevine, FairPlay и PlayReady через Shaka Packager и крупных DRM-as-a-Service-вендоров, и строили кастомное license-server-промежуточное ПО для клиентов с нестандартными требованиями к выдаче токенов. Мы не перепродаём DRM-as-a-Service – мы подбираем вендора под ваш микс студий и бюджет latency.
Ключевые тейкавеи
- DRM в 2026 году – это три системы (Widevine, FairPlay, PlayReady), делящие один слой шифрования под названием CENC.
- CMAF с шифрованием cbcs схлопнул в 2018 году старый воркфлоу «две упаковки на ролик» в одну.
- Аппаратные уровни безопасности (Widevine L1, PlayReady SL3000) – ворота к 4K Ultra HD и большинству премиального студийного контента.
- Multi-DRM-охват 95% даёт Widevine плюс FairPlay; последние 5% стоят вам PlayReady.
- Объём license-запросов на live-каналах с ротацией ключей – доминирующий сюрприз стоимости в DRM-контрактах.
- DRM – это контрактное обязательство, а не абсолютная блокировка пиратства; фреймите так внутри.