Содержание статьи +
- 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, не пройдёте в Голливуд, не сможете предлагать 4K Ultra HD на платформах, где 4K действительно приносит доход. Ответили правильно – стоимость multi-DRM-стека (лицензии на серверы, время на упаковку, интеграционные работы) оказывается незначительной по сравнению с расходами на CDN.
Статья адресована продакт-менеджерам, основателям и техническим лидерам, которым нужно оценить multi-DRM-провайдера или построить пайплайн упаковки, способный выдержать переход к следующему поколению кодеков. Это не реклама конкретного поставщика. Рекомендации конкретны, цифры актуальны на 2026 год, диаграммы делают сложные процессы прозрачными без шестимесячного proof of concept.
Что означает «DRM» в стриминге
До того как назвать три системы, уточним термин. DRM – это контролируемая система распространения ключей и применения политик: она определяет, кому разрешено расшифровать видеофайл, на каком устройстве, в каком качестве и на какой срок. Сам зашифрованный видеофайл между Widevine и FairPlay остаётся неизменным – это стандартный MP4 с небольшим блоком шифрования в начале. Что меняется – это протокол, по которому плеер запрашивает у лицензионного сервера ключ расшифрования, криптографическая идентичность, которую плеер должен подтвердить, и защищённый путь, по которому расшифрованные пиксели передаются на экран.
Эта работа находится между двумя более знакомыми компонентами. Сверху – ваш packager: он берёт закодированные версии (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-система могла добавлять собственные метаданные лицензионного запроса, не изменяя саму схему шифрования. Один зашифрованный файл – несколько лицензионных путей.
Стандарт определяет четыре схемы защиты, идентифицируемые четырёхсимвольным кодом, записанным в поле schi (информация о схеме) файла. Первые две используют 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 – в PlayReady в том же году. С 2018 года один CMAF-файл, зашифрованный по cbcs, одинаково воспроизводится на Widevine, PlayReady и FairPlay. До этого каждый ролик приходилось упаковывать дважды – cenc для DASH и cbcs для HLS – и хранить на origin две копии. Это удваивало стоимость хранения и время упаковки. Сегодня вы отгружаете один набор сегментов, два манифеста и три лицензии – и можете спать спокойно.
Кусок метаданных, обеспечивающий поддержку multi-DRM, – это бокс pssh (protection system specific header). В нём содержится 16-байтный system ID, который сообщает плееру: «этот блок предназначен для Widevine» или «этот блок – для PlayReady», а также вендор-специфичная нагрузка, которую соответствующий CDM может распарсить. Multi-DRM-файл включает по одному pssh для каждого DRM: один для 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-эмуляторе или на старом смартфоне без драйвера TEE. Именно здесь проявляются известные уязвимости: с 2019 года исследователи демонстрируют реальные атаки по извлечению ключей из white-box-реализаций Widevine L3, а инструменты типа «Widevine dump», позволяющие извлекать ключи из L3-сессий, свободно распространяются в сети. Крупные студии в ответ ограничивают L3 разрешением 480p – поэтому ваш Chrome на десктопе не может смотреть Netflix в HD без браузера Microsoft Edge (который на Windows использует PlayReady).
Лицензионный сервер общается с клиентом по протоколу, определённому Google, поверх HTTPS; тело запроса – сериализованный Protocol Buffer, который плеер формирует на основе бокса pssh и токена идентификации пользователя. Ответы сервера содержат KID, сами ключи и политику использования: срок действия лицензии, необходимость поддержки HDCP (High-bandwidth Digital Content Protection) на выходе, возможность офлайн-просмотра. Widevine не взимает плату за каждую лицензию с оператора сервиса; стоимость передаётся вашему поставщику DRM как услуги (подробнее ниже).
FairPlay Streaming – обязательный стандарт Apple
FairPlay Streaming (FPS) – это система защиты цифровых прав (DRM) от Apple. Она встроена в iOS, iPadOS, macOS, tvOS, watchOS и браузер Safari, и является единственной DRM, которую Apple разрешает использовать для шифрования видео на своих устройствах. На iOS отсутствуют Widevine, PlayReady и сторонние CDM: если вы хотите транслировать зашифрованное видео на iPhone, вы используете только FairPlay.
Шифровальная сторона FairPlay имеет простой дизайн: AES-128 в режиме CBC с шифрованием на уровне подвыборок, адресуемый кодом cbcs. Apple использует HLS в качестве нативного формата упаковки; зашифрованные сегменты содержат тег #EXT-X-KEY с параметром METHOD=SAMPLE-AES (устаревший вариант) или, в случае CMAF-совместимого HLS, тег #EXT-X-SESSION-KEY, указывающий на URL доставки ключа с KEYFORMAT="com.apple.streamingkeydelivery".
Поток лицензионного запроса включает ключевые серверы Apple в качестве промежуточного авторитета. Ваше приложение отправляет на ваш ключевой сервер blob контекста контента (SPC); ваш ключевой сервер пересылает его на ключевой сервер Apple, который проверяет запрос и возвращает ответ с ключом контента (CKC). Ваш ключевой сервер передаёт этот CKC приложению, которое направляет его системному CDM для расшифровки сегментов. Ключевой сервер Apple выступает в роли корневого доверенного источника: без секретного ключа приложения и сертификата, выданных Apple, запустить FairPlay невозможно. Эти данные вы получаете, подписав соглашение о развертывании FairPlay Streaming на Apple Developer.
Поддержка кодеков следует дорожной карте Apple. H.264, H.265 (HEVC) и AV1 поддерживаются в стримах с защитой FairPlay на платформах Apple, где реализована поддержка кодека: аппаратное декодирование AV1 появилось с чипом A17 Pro и доступно на iPhone 16 и новее. Dolby Vision и HDR10 поддерживаются как метаданные упаковки поверх любого зашифрованного кодека. Важно: начиная с 2026 года AVPlayer на iOS перестанет воспроизводить AV1-контент, если устройство не имеет аппаратного декодера AV1, даже если в операционной системе присутствует программный декодер. Планируйте разделение сценариев: AV1 будет доступен только на новых устройствах, а резервный вариант – 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-телевизорах и приставках, выпущенных за последнее десятилетие. Samsung, Sony, LG (вместе со своей), Vizio, Roku, Amazon Fire TV, Comcast Xfinity, Sky Q – список доминирует PlayReady, потому что Microsoft лицензирует эту технологию производителям телевизоров на условиях, делающих её наиболее простым решением для операционных систем подключённых телевизоров, которым требуется защита контента уровня студийного качества.
У PlayReady два активно используемых уровня безопасности – SL2000 и SL3000. SL2000 – это программный уровень DRM: криптографические операции выполняются в программном обеспечении с обфускацией, но без аппаратной изоляции. Этого уровня достаточно для SD- и HD-контента у большинства студий. SL3000 – аппаратный уровень DRM, введённый в 2015 году вместе с PlayReady 3.0: криптографические операции выполняются внутри TEE устройства, и этот уровень требуется большинством студий для 4K Ultra HD и HDR.
Самая значимая история по PlayReady в 2025 году – утечка сертификатов SL2000 и SL3000, опубликованная на GitHub под ником «Widevineleak». Microsoft подала запросы на удаление (takedown) для серии SL3000 – высокоценных 4K-сертификатов, – а Amazon Prime Video начал блокировать аккаунты, использовавшие утечённые сертификаты для скачивания защищённого контента. Запросов на удаление по сертификатам SL2000 Microsoft не подавала – эксперты расценили это как тихое признание того, что уязвимость 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-сервере. Удвоенное хранение и двойная работа упаковщика обходились недёшево.
CMAF определяет единый формат фрагментированных MP4 (fMP4), на который могут ссылаться как HLS-, так и DASH-манифесты. При использовании CMAF вы создаёте один набор сегментов на origin и генерируете два лёгких манифеста – .m3u8 для HLS и .mpd для DASH, – ссылающихся на одни и те же сегменты. Добавив шифрование cbcs, вы обеспечиваете одинаковую расшифровку этих сегментов с помощью DRM-систем Widevine, PlayReady и FairPlay. В итоге получается современный multi-DRM-воркфлоу: один кодек, одна упаковка, один зашифрованный набор на origin, два манифеста и три лицензии при воспроизведении.
Крупные поставщики пакетов (packager) с 2026 года по умолчанию предлагают CMAF + cbcs. AWS Elemental MediaPackage по умолчанию использует CMAF для новых каналов. Энкодер Bitmovin по умолчанию генерирует CMAF для live- и per-title-воркфлоу. Открытые инструменты – Shaka Packager и Bento4 – поддерживают CMAF + cbcs с multi-DRM-метаданными ключей одной командой. Документация Apple Advanced HTTP Live Streaming с 2020 года перешла от примеров на основе MPEG-TS к примерам на fragmented MP4 и теперь рекомендует 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) – JavaScript-API, разработанное консорциумом W3C, которое позволяет веб-плееру взаимодействовать с CDM операционной системы. EME – это рекомендация W3C 2017 года; каждый современный браузер её поддерживает, а все актуальные HTML5-видеоплееры (Shaka Player, dash.js, hls.js с EME, Video.js с плагином eme, Bitmovin Player, JW Player) используют EME для работы с DRM.
Контракт EME небольшой. Плеер создаёт объект MediaKeys, привязанный к идентификатору key system – com.widevine.alpha для Widevine, com.microsoft.playready для PlayReady (или com.microsoft.playready.recommendation для сессий, поддерживающих SL3000), com.apple.fps.1_0 для FairPlay в Safari. Элемент <video> генерирует событие encrypted, когда плеер передаёт ему зашифрованный сегмент; это событие содержит initialization data – pssh-blob из файла. Плеер передаёт этот blob в метод generateRequest, браузер направляет его в платформенный CDM, который в ответ генерирует событие message с вендор-специфичным payload запроса лицензии. Плеер отправляет этот payload на лицензионный сервер, получает ответ и передаёт его в метод update. После вызова update видео начинает воспроизводиться.
Хрупкой частью EME является таблица идентификаторов key system. Одна и та же DRM-система может иметь разные идентификаторы в разных браузерах: например, различия между SL2000 и SL3000 в PlayReady отражаются как отдельные идентификаторы, а реализация FairPlay в Safari долгое время адаптировалась под API других браузеров. В 2026 году веб-плееру необходим шаг проверки key system: запросите у браузера через navigator.requestMediaKeySystemAccess, какие системы он поддерживает, пройдитесь по приоритетному списку и откажитесь от воспроизведения, если ни одна из поддерживаемых систем не подходит для защищённого контента.
Лицензионные серверы и рынок DRM-as-a-Service
Свой собственный multi-DRM-лицензионный сервер технически возможен. Google публикует протокол Widevine-лицензионного сервера, Microsoft – инструменты для PlayReady-сервера, а Apple распространяет эталонную реализацию FairPlay key server по developer-соглашению. На практике почти никто этим не занимается – операционная нагрузка по поддержанию актуальности трёх вендорских спецификаций, ротации трёх сертификатов и прохождению трёх аудиторских циклов оказывается выше, чем стоимость покупки готового сервиса у вендора, который уже обеспечивает его для тысячи других клиентов.
Рынок DRM-as-a-Service в 2026 году доминируют несколько ключевых игроков: EZDRM, BuyDRM (с продуктом KeyOS multikey), DRMtoday от Castlabs, Axinom, VdoCipher, DoveRunner. Цены складываются по двум основным моделям: ежемесячная абонентская плата в диапазоне от $100 до $2000 плюс плата за лицензию – от $0,001 до $0,05, либо фиксированная плата за лицензию без минимального абонентского взноса. EZDRM устанавливает стартовую ставку в $199,99 в месяц; BuyDRM начинает от $99 в месяц; Axinom и DRMtoday рассчитывают стоимость индивидуально, исходя из объёма. Контракты уровня Netflix или Disney заключаются на условиях фиксированной годовой оплаты в диапазоне от $10 000 до $50 000.
Выбор вендора на старте редко зависит от цены – разница между $99 и $199 в месяц – это шум по сравнению с реальной стоимостью интеграции, которая может не сработать. Важнее другое: с какими CDN и плеерами они интегрируются «из коробки», поддерживают ли ротацию ключей для live-каналов (каждые два часа, на границе события, по требованию), выдают ли персистентные лицензии для мобильных приложений с режимом download-and-go, расположен ли их лицензионный сервер в регионе ваших зрителей (задержка имеет значение, когда первый запрос на лицензию зрителя блокирует первый кадр), и есть ли у них studio-recognized integrity attestation, требуемый Hollywood-уровневыми студиями, с которыми вам предстоит вести переговоры.
Самый частый сюрприз по стоимости – объём запросов на лицензии в live-каналах с ротацией ключей. Стандартный 24-часовой live-канал, ротирующий ключи каждые два часа, генерирует 12 запросов на лицензию на одного зрителя в день. Live-событие с 100 000 одновременных зрителей и ротацией ключей раз в час создаёт 100 000 запросов на лицензию в час. При цене $0.005 за лицензию это $12 000 в день только на лицензионные платежи – помимо расходов на кодирование и CDN. Некоторые платформы ограничивают месячный счёт на основе ожидаемого использования, другие позволяют «кровоточить». Внимательно читайте контракт.
Дерево решений: какая DRM и когда
Прагматичный оператор сервиса в 2026 году не выбирает «лучшую DRM» – её не существует – а сопоставляет DRM-покрытие с охватом устройств и требованиями студий. Дерево ниже – то, что мы используем с клиентами в Фора Софт.
Если ваш сервис – потребительский, финансируемый за счёт рекламы или 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 – это ключ к работе с партнёрами в сфере подключённых телевизоров (Samsung, LG, Roku), и его невозможно подделать.
Если ваш сервис транслирует 4K Ultra HD, используйте только аппаратный DRM. То есть Widevine L1 на Android, FairPlay на Apple (где поддержка аппаратная по определению) и PlayReady SL3000 на Windows и телевизорах. Программные уровни DRM (Widevine L3, PlayReady SL2000) ограничивают разрешение 1080p или 540p – в зависимости от требований студии. Настройте манифесты так, чтобы строго соблюдать это правило: ваш плеер должен отказываться предлагать 4K-рендеринги устройствам, которые сообщают о сессии с программным DRM.
Если ваш сервис транслирует live-события с ротацией ключей, обработка запросов на лицензии со стороны вашего вендора DRM-как-услуги становится основной статьёй расходов. Договоритесь о тарифе за каждую лицензию с учётом прогноза числа зрителей, а не на основе исторических данных по VOD. Live-событие с 100 000 зрителей и ротацией ключей раз в час генерирует за один час больше запросов на лицензии, чем весь ваш VOD-каталог за год.
Если ваш сервис поставляет мобильное приложение для iOS или Android с возможностью офлайн-загрузки – распространённый сценарий в образовательных и travel-приложениях – вам потребуются персистентные лицензии с чёткой офлайн-политикой. Widevine и PlayReady поддерживают персистентные офлайн-лицензии с настраиваемым сроком действия; FairPlay реализует их через FairPlay Streaming Offline, что требует отдельной настройки FairPlay key server. Тестируйте сценарии истечения срока действия лицензий при включённом режиме полёта как можно раньше – это типичная точка отказа, которую часто упускают на этапе QA.
Частая ошибка: считать DRM гарантией безопасности
Инженеры, только начинающие работать с DRM, часто считают эту технологию гарантией того, что их контент невозможно украсть. Это заблуждение. DRM – это не защита от пиратства, а способ сделать его менее выгодным по сравнению с легальной покупкой и возможность быстро блокировать наиболее уязвимые каналы расшифровки. Но она не защищает от целенаправленной, хорошо обеспеченной атаки.
Widevine L3 сломан с 2019 года, и надёжные инструменты для извлечения свободно доступны. Сертификаты PlayReady SL2000 утекли в 2024 году, SL3000 – в начале 2025-го. FairPlay держится лучше на публике, но эталонная реализация Apple неоднократно подвергалась реверс-инжинирингу. 4K-оригиналы каждого крупного стримингового контента появляются на пиратских сайтах в течение нескольких часов после релиза. Это не означает, что DRM бесполезна – это значит, что разговор о DRM должен быть честным: нужно понимать, что она вам даёт.
DRM на самом деле даёт вам две вещи. Во-первых, она выполняет контрактное обязательство, которое накладывает на вас соглашение о лицензировании контента («вы должны использовать стандартную для индустрии DRM, совместимую со спецификацией безопасной доставки MPAA»). Именно это обязательство защищает вас от судебных исков со стороны студии за нарушение условий. Во-вторых, она делает соотношение затрат и выгод от пиратства вашего контента невыгодным для маргинального пользователя – тех, кто заплатил бы за ваш сервис, но перешёл бы на бесплатную пиратскую копию, если бы мог получить её за тридцать секунд. DRM не влияет на пиратские сайты, у которых уже есть ваш контент. Зато она эффективно сдерживает обычного пользователя, который мог бы попросить друга отправить ему файл через AirDrop.
Маркетинговый нарратив «DRM предотвращает пиратство» вредит обсуждению. Честный подход: DRM лишь повышает стоимость пиратства до уровня, при котором студии готовы заключить лицензионное соглашение, а сами студии – это ключевые посредники между вами и качественным премиальным видеопродуктом.
Математика цены: соединяем цифры
Цифры без проработанного примера – шум. Возьмём 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 запросов на лицензию за событие – это в четыре раза дороже по модели per-start, чем эквивалентная аудитория VOD.
Если у вас узкая операционная маржа, договаривайтесь с вендором DRM о гибридном контракте: фиксированная ставка до прогнозируемого объёма и оплата за лицензию сверх него. Большинство вендоров готовы пойти на годовой коммит.
Где Фора Софт вписывается
Фора Софт поставляла DRM-защищённое видео в OTT- и интернет-телевидение, в e-learning-платформы с возможностью офлайн-загрузки и в телемедицинские сервисы, где воспроизведение строго регламентировано. Паттерн, который мы наблюдаем по всем направлениям, остаётся неизменным: инженеры недооценивают объём запросов на лицензирование во время прямых трансляций, продуктовая команда – сложность реализации политики офлайн-воспроизведения только на iOS, а юридическая группа, работающая со студиями, – насколько критично наличие аппаратной поддержки PlayReady SL3000 при переговорах с партнёрами по connected TV. Мы интегрируем Widevine, FairPlay и PlayReady через Shaka Packager и крупных провайдеров DRM как услуги, а также разрабатывали кастомное промежуточное ПО для лицензионного сервера для клиентов с нестандартными требованиями к выдаче токенов. Мы не перепродаём DRM как услугу – мы подбираем поставщика под ваш набор студий и допустимый уровень задержки.
Ключевые тезисы
- DRM в 2026 году – это три системы (Widevine, FairPlay, PlayReady), использующие общий слой шифрования под названием CENC.
- CMAF с шифрованием cbcs в 2018 году заменил устаревший воркфлоу «две упаковки на ролик» на единый.
- Аппаратные уровни безопасности (Widevine L1, PlayReady SL3000) – ключ к 4K Ultra HD и большинству премиального студийного контента.
- Охват Multi-DRM на уровне 95% обеспечивают Widevine и FairPlay; оставшиеся 5% требуют подключения PlayReady.
- Объём запросов на лицензирование на live-каналах с ротацией ключей – главный сюрприз по стоимости в DRM-контрактах.
- DRM – это контрактное обязательство, а не абсолютная защита от пиратства; так и рассматривайте его при планировании.
Что почитать дальше
- Контейнеры: MP4, fMP4, MKV, WebM, MOV, MPEG-TS
- Облачный транскодинг: AWS Elemental, Bitmovin, Coconut, NETINT
- Сравнительная таблица кодеков: MPEG-2, H.264, H.265, VP9, AV1, VVC
«Примечание: в URL-адресах сохранены оригинальные пути, но в них присутствуют лишние пробелы и разрывы слов (например, webm-fmp4, bitmovin-coconut-netint, kodkov). Это может быть ошибкой при формировании ссылок. Однако, поскольку задание требует сохранять Markdown-форматирование и содержимое ссылок без изменений, я не исправил URL. Если требуется корректная работа ссылок – их нужно отредактировать отдельно.»