Widevine: L1, L2, L3 – что они значат на самом деле

Автор: Николай СапуновОбновлено: август 202625 мин чтения
Содержание статьи +

TL;DR

Widevine – это система Digital Rights Management от Google, которая встроена в каждый браузер на движке Chromium и почти в каждое Android-устройство. У неё три уровня безопасности – L1, L2 и L3, – и именно уровень, который сообщает устройство, определяет, какие разрешения видео платный стриминг имеет право ему отдать. L1 держит ключи расшифровки, ключ контента и декодированный кадр внутри Trusted Execution Environment – изолированного аппаратного «защитного отсека» процессора – и требуется для 1080p и 4K от крупных студий; L3 запускает весь конвейер в обычной программной памяти, и именно его выдаёт каждый десктопный Chrome, ограничивая разрешение 480p или 720p; L2 – редкий промежуточный случай, когда ключи живут в железе, а пиксели декодирует софт. Уровень не выбирается плеером или сайтом – он зашит в устройство на заводе через процесс сертификации Widevine, проверяется через Android-API MediaDrm или через строку robustness в EME-запросе на лицензию, и применяется лицензионным сервером ещё до того, как ключ контента вообще выдаётся. В 2026 году практическая карта простая: Android-смартфон с L1, Smart TV c L1 или Apple TV с FairPlay получают 4K; Linux-машина, десктопный Chrome и Firefox получают 480p–720p; всё остальное лежит где-то между, и задача вашего OTT-продукта – определить уровень до того, как вы пообещали разрешение, которое не сможете отдать.

Зачем это знать

Если вы продаёте платное видео, уровень Widevine, который сообщает устройство зрителя, – это то самое поле, которое решает, правда ли ваше маркетинговое обещание про 4K. Продакт-менеджер, дочитавший статью, уйдёт со знанием того, почему Chrome на MacBook показывает Netflix в 540p, а тот же Netflix на iPad – в 1080p (разные DRM, разный robustness, разные правила студий). Инженер уйдёт с конкретным путём кода, по которому запрашивают уровень, со схемой pssh и tenc, привязывающей лимиты разрешения к уровню безопасности (подробно – в статье Common Encryption (CENC) подробно), и с точными значениями robustness, которые передаются в requestMediaKeySystemAccess. Основатель, прикидывающий риск пиратства, уйдёт с обоснованным ответом на вопрос «насколько L1 сложнее сломать, чем L3?» – кратко: в 2019 году исследователь сломал white-box-криптографию L3 за выходные на ноутбуке (атака Бьюкенена через Differential Fault Analysis на white-box AES в L3); публично опубликованных взломов production-L1 после Widevine 5 (выпущен в 2014) не было.

Это вторая половина пары. Параллельная статья – DRM 101: почему три системы и почему вы ставите все три – объясняет, почему одной Widevine недостаточно; эта статья объясняет, почему одна Widevine на практике – это три Widevine.

Что вообще такое «уровень безопасности»

Прежде чем разбираться с буквами и цифрами, зафиксируем суть. Уровень безопасности Widevine – это контракт между Google и производителем устройства о том, где именно в железе устройства происходят опасные операции: расшифровка ключа контента, расшифровка видеосэмплов и попадание декодированных кадров на экран.

Опасных операций три, и мест, где они могут произойти, тоже три:

  1. Разбор лицензии – когда устройство получает зашифрованную лицензию от лицензионного сервера, его задача – расшифровать её и извлечь ключ контента.
  2. Расшифровка сэмпла – получив зашифрованный видеосэмпл (часть I-кадра, P-кадра или B-кадра), устройство расшифровывает его этим ключом контента.
  3. Декодированный кадр – после расшифровки декодер превращает сэмпл в пиксели и передаёт их на дисплей.

Trusted Execution Environment, сокращённо TEE – это отдельный, изолированный режим процессора, в который обычная Android- или Linux-операционная система не может заглянуть. Все три операции могут жить в TEE. А могут жить в обычной памяти приложения – той же памяти, в которой ваш браузер рисует страницу. Уровень Widevine – это короткое обозначение того, какая из этих комбинаций у вас.

L1 – все три операции происходят внутри TEE. Ключи никогда не появляются в обычной памяти CPU, зашифрованные сэмплы никогда не попадают в обычную память, а декодированные кадры идут прямо из TEE в контроллер дисплея через защищённый видеоканал. Операционная система не может прочитать ни ключи, ни декодированные пиксели; запущенный поверх ОС инструмент для записи экрана видит чёрный прямоугольник вместо видео.

L2 – разбор лицензии и расшифровка сэмпла происходят внутри TEE, но декодированные кадры выпускаются обратно в обычную память приложения для софтового декодера. Ключи в безопасности; пиксели – нет. На практике L2 встречается редко – потому что построить TEE дорого, а добавив к нему защищённый видеоканал (что и превращает L2 в L1) выходит относительно дёшево. На производственной картинке 2026 года есть фактически только два уровня: L1 и L3.

L3 – никакого TEE. Все три операции происходят в обычной памяти приложения. И ключи, и сэмплы, и декодированные кадры видны операционной системе. Криптография всё ещё настоящая – AES-128, RSA, те же примитивы, что и в L1, – но она реализована в софте и скрыта техникой под названием white-box cryptography, которая пытается сделать ключ невозможным для извлечения статическим анализом. White-box-криптографию ломали публично уже дважды: Дэвид Бьюкенен в 2019 году атакой через Differential Fault Analysis, и Томер Хадад в 2020-м – через боковой канал в RSA. Ключи L3 для семейства CDM 4.10.x публично известны. Именно поэтому студии не дают L3 расшифровывать 1080p.

Самое полезное предложение этой статьи – следующее. Уровень безопасности живёт в устройстве, а не в контенте. Зашифрованный файл одинаковый, кто бы его ни проигрывал; меняется то, каким устройствам лицензионный сервер согласен выдать ключ и какие разрешения лицензия в каждом случае разблокирует.

Рисунок 1. Граница доверия на L1, L2 и L3. TEE – пунктирный синий прямоугольник; «обычная память» – всё, что за его пределами.

Где какой уровень живёт в 2026 году

Это та самая таблица, которую любой продуктовой команде стоит распечатать и повесить над столом.

Класс устройстваТипичный уровень WidevineДопустимое разрешение по контракту
Современный Android-смартфон (Pixel 6+, S22+, Xiaomi 12+)L14K UHD
Старые Android-смартфоны (2016–2019)L1 или L3 (по-разному)1080p или 480p
Android TV / Google TV (2020+)L14K UHD
Fire TV Stick 4K (Gen 2+)L14K UHD
Chromecast with Google TVL14K UHD
ChromeOS-устройство (Chromebook 2020+)L11080p
Desktop Chrome / Edge на WindowsL3720p (Edge через PlayReady SL3000 – 1080p+)
Desktop Chrome / Edge на macOSL3720p (Safari через FairPlay – 4K)
Desktop Chrome на LinuxL3720p
Desktop Firefox (любая ОС)L3720p
Smart TV Tizen / webOS (приоритет PlayReady)n/a (PlayReady)4K через PlayReady SL3000

Источники – публикуемые вендорами матрицы устройств (Bitmovin, Widevine Security Levels in Depth, документация Bunny.net по Widevine) сверены с реестром совместимости устройств в интеграционной консоли integration.widevine.com (новая консоль, заменившая partnerdash.google.com 17 декабря 2025).

Главный паттерн в этой таблице стоит запомнить. Любое устройство, созданное жить в гостиной, имеет L1; любое устройство, созданное для общих вычислений, имеет L3. Этот разрыв – точно тот инженерный разлом между «я сделал устройство, чтобы крутить видео» и «я сделал устройство, чтобы делать что угодно». Chromecast, Roku, Samsung TV – это маленький закрытый встраиваемый компьютер с проверенной цепочкой загрузки, измеренной прошивкой и аппаратным TEE на уровне чипа. MacBook с Chrome – это универсальный ноутбук, к которому отладчик можно подключить миллионом способов, и Google не может дать ему L1, не соврав про гарантию безопасности.

Самый частый вопрос про эту таблицу – «почему десктопный Chrome выдаёт только 720p?» – отвечается в один абзац. Десктопный Chrome запускает Widevine CDM как обычный процесс Chrome в обычной user-space-памяти. Ключи, которые он держит, защищены только white-box-криптографией, то есть программной обфускацией. Студии знают, что ключи L3 извлекаемы, и оценивают защиту как слабую – поэтому лицензируют не выше 720p (а часто 540p или 480p). Тот же самый Chrome на Chromebook – это тот же код, но ключи он загружает из TPM (Trusted Platform Module), а декодер аппаратно изолирован, поэтому студии лицензируют 1080p. Меняется не браузер – меняется корпус.

Рисунок 2. Какой уровень какое разрешение даёт в production-внедрениях 2026 года.

Строка robustness: как EME просит уровень

Когда веб-страница хочет проиграть защищённое видео в браузере, она вызывает одну функцию: navigator.requestMediaKeySystemAccess, определённую в спецификации W3C Encrypted Media Extensions (EME) (Recommendation, 2017; актуальный черновик – W3C EME 2). Вызов спрашивает у браузера, доступна ли ключевая система com.widevine.alpha, и – что важно – какой уровень robustness браузер может гарантировать.

У Widevine шесть строк robustness. Их полезно прочитать вслух – это первый урок DRM-операций:

  • SW_SECURE_CRYPTO – программные ключи, программное декодирование. Widevine L3.
  • SW_SECURE_DECODE – программные ключи, программное декодирование. Widevine L3 (разница с SW_SECURE_CRYPTO историческая; обе сегодня означают L3).
  • HW_SECURE_CRYPTO – аппаратные ключи, программное декодирование. Widevine L2.
  • HW_SECURE_DECODE – аппаратные ключи, аппаратное декодирование сжатых сэмплов. Widevine L1.
  • HW_SECURE_ALL – аппаратные ключи, аппаратное декодирование и защищённый видеоканал на пути декодированного кадра к дисплею. Widevine L1 в строгом профиле. Netflix требует это для 4K.
  • "" (пустая строка) – у браузера спросили «дай что можешь». Большинство браузеров при пустом robustness откатываются до SW_SECURE_CRYPTO (L3). Это самая частая production-ошибка: сайт, забывший выставить robustness, тихо получит 720p на устройстве, которое могло бы дать 1080p.

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

Минимальный production-JavaScript для сервиса с 1080p и выше:

const config = [{
  initDataTypes: ['cenc'],
  videoCapabilities: [{
    contentType: 'video/mp4; codecs="avc1.640028"',
    robustness: 'HW_SECURE_ALL',
  }],
  audioCapabilities: [{
    contentType: 'audio/mp4; codecs="mp4a.40.2"',
    robustness: 'SW_SECURE_CRYPTO',
  }],
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
  .then(keySystemAccess => {
    // устройство сертифицировано для L1 HW_SECURE_ALL — 4K разрешён
  })
  .catch(err => {
    // упасть на менее строгий конфиг (HW_SECURE_DECODE, потом SW_SECURE_CRYPTO),
    // и согласно этому переписать набор доступных ступеней в манифесте
  });

Паттерн: сначала строгий, потом откат. Никогда не начинайте с самого мягкого конфига – иначе 1080p уйдёт L3-зрителю, а десктопный Chrome получит бесплатное повышение, на которое ваш контракт со студией не подписывался. Та же логика – для нативного Android, где уровень читается через MediaDrm.getPropertyString("securityLevel") и сразу возвращает одну из строк "L1", "L2", "L3" – никаких маппингов robustness не требуется.

Что находится внутри L1: TEE, защищённый видеоканал и HDCP

Фраза «все три операции происходят внутри TEE» прячет за собой четыре куска инфраструктуры, которые должны существовать в чипе ещё до того, как это станет правдой. Стоит пройтись по ним – каждый из четырёх это место, где L1 может сломаться и тихо откатиться до L3.

1. Проверенная загрузка (verified boot). При включении устройства маленький кусок кода в кремнии (boot ROM, буквально только-для-чтения память, прожжённая в чип на фабрике) проверяет подпись на загрузчике, прежде чем его запустить. Загрузчик проверяет подпись ядра; ядро – подпись системного образа; системный образ – подпись бинарника Widevine TEE. Если любая подпись не сходится, цепочка рвётся, и устройство отказывается грузить следующий этап. Ключи подписи держат совместно Google и производитель устройства. Без verified boot не бывает L1. Именно поэтому рутованные Android-телефоны теряют L1 – рут требует разблокировать загрузчик, разблокированный загрузчик ломает verified boot, и Widevine при следующей загрузке видит сломанную цепочку и опускает уровень до L3. Подробное описание цепочки – в документации Widevine на integration.widevine.com и в спецификации Android Verified Boot 2.0.

2. Сам TEE. На устройствах с ARM (почти каждый Android-телефон и почти каждый Smart TV) TEE – это защищённый мир, обеспеченный ARM TrustZone, который работает параллельно обычной ОС. У процессора два режима – «обычный мир» и «защищённый мир», – и кремний чипа гарантирует, что код в обычном мире не сможет прочитать память защищённого. Переход между режимами идёт через одну инструкцию, Secure Monitor Call (SMC), описанную в техническом справочнике ARM TrustZone. Когда Widevine CDM из обычного мира хочет, чтобы защищённый расшифровал лицензию, он вызывает SMC и передаёт зашифрованную лицензию; защищённый мир возвращает хендл на ключ контента – но никогда сам ключ. Ключ не пересекает границу. На устройствах с x86 (Chromebook, некоторые Windows-ARM-устройства) эквивалентами выступают Intel SGX или AMD SEV; принцип тот же.

3. Защищённый видеоканал. После того как видеосэмпл расшифрован внутри TEE, декодированные YUV-пиксели идут на дисплей по аппаратно изолированной шине, которую ОС не может прослушать. На Android этот канал использует защищённую поверхность GPU, на Apple TV – путь CoreMedia, доступный только FairPlay. ОС никогда не видит пиксели; запись экрана возвращает чёрный прямоугольник. Защищённый видеоканал – это и есть то, что отличает L1 от L2 – у L2 есть TEE, но декодированные пиксели у него утекают обратно в обычную память.

4. HDCP на выходе. Когда декодированный кадр в итоге покидает чип через HDMI-кабель, он перешифровывается технологией High-bandwidth Digital Content Protection (HDCP), и только потом отправляется по проводу. HDCP 2.2 требуется для 4K у большинства крупных студий; HDCP 1.4 хватает на 1080p. Принимающий телевизор расшифровывает кадр и показывает. Если на HDMI-пути есть несовместимое с HDCP устройство (дешёвая HDMI-захватывающая коробка, AV-ресивер без HDCP), HDCP-аутентификация падает, и источник возвращает 480p или чёрный экран. Именно поэтому «я подключил 4K-ресивер, а Netflix упал в SD» – типичный тикет в поддержке: ресивер только HDCP 1.4.

Пятислойный стек целиком – это и есть причина, по которой L1 трудно атаковать: чтобы извлечь декодированные пиксели, атакующему нужно сломать verified boot, выйти из обычной ОС в защищённый мир, обойти изоляцию памяти TEE, прослушать защищённый видеоканал и снять HDCP – и всё это так, чтобы чип не заметил и не отозвал свои ключи. Каждый слой – отдельный исследовательский проект. Суммарная поверхность атаки достаточно мала, чтобы публичных воспроизводимых атак на L1 не появлялось с тех пор, как Widevine перешёл с версии 4 на версию 5 (модульная архитектура DRM) в 2014 году.

Рисунок 3. Конвейер L1. Каждый блок на этой схеме – место, которое атакующему пришлось бы сломать.

Почему L3 – дёшево, полезно и обречено на 720p

L3 – это уровень, который остаётся от Widevine, если убрать поддержку чипа. Он работает везде, где работает обычный CPU – в каждом Chrome в каждом ноутбуке под любой ОС. CDM – это одна общая библиотека (на Windows – widevinecdm.dll; на macOS – .dylib внутри Frameworks-директории Chrome), загружаемая в адресное пространство процесса браузера.

Защита – это white-box cryptography: реализации AES и RSA внутри CDM построены так, что ключи математически переплетены с таблицами поиска алгоритма, и идея в том, что реверс-инженер, читающий бинарник, не сможет показать пальцем на байты и сказать «вот это ключи». Технику ввели в академический оборот Chow и соавторы в 2002 году, и с тех пор каждые несколько лет выходит новая работа со взломом. Самый влиятельный публичный взлом – атака Дэвида Бьюкенена 2019 года через Differential Fault Analysis (DFA), извлёкшая мастер-ключи L3 из десктопного Chrome CDM, выложенная как инструмент widevine-l3-decryptor. Год спустя Томер Хадад показал обновлённую атаку на свежий CDM через побочный канал RSA. Оба исследователя сообщили о находках в Google; Google ротировал ключи CDM и выпустил обновлённые сборки. Цикл продолжается.

Именно поэтому студии ограничивают L3 720p (а часто 540p или 480p). Конкретные числа зависят от контракта со студией – Netflix известно строжайший, разрешая в L3 максимум 720p даже если браузер заявляет SW_SECURE_DECODE; Amazon Prime Video и Disney+ дают 720p, но ограничивают звук стерео; меньшие сервисы могут давать 1080p на L3 в рамках сделок bring-your-own-license. Полезное обобщение: если зритель в десктопном Chrome, не заявляйте 1080p в манифесте, если контракт со студией не разрешает и лицензионный сервер не сконфигурирован выдавать 1080p-ключи в L3.

Отдельный абзац – про операционную реальность. Несмотря на то что L3 «сломан», практическая стоимость пиратства L3-контента в 2026 году низкая. Пират, которому нужны HD-утечки 1080p, идёт за HDMI-захватом с аппаратного Smart TV (цифровой эквивалент «аналоговой дыры»), а не воюет с white-box AES. Защита L3 достаточна, чтобы отпугнуть случайный обмен: скопировать поток из Chrome другу нетехнический пользователь не сможет, – и для 720p этого студиям, как правило, достаточно.

Где живёт уровень: разговор с лицензионным сервером

Эффективный уровень безопасности зрителя определяют три участника: устройство, лицензионный сервер и политика владельца контента. Их разговор короткий.

Шаг 1. Устройство загружается, бинарник Widevine TEE подключается, и Widevine спрашивает у защищённого мира чипа об идентичности (Widevine Provisioning Server, WVPS, выдал чипу сертификат устройства ещё на производстве). CDM запоминает уровень, на котором сертифицирован чип – L1, L2 или L3.

Шаг 2. Приложение вызывает requestMediaKeySystemAccess со строкой robustness (или, на нативном Android, без строки – фреймворк MediaDrm сообщает уровень напрямую). Браузер сопоставляет robustness c запрашиваемым уровнем и проверяет, что устройство ему соответствует.

Шаг 3. Стартует воспроизведение. Плеер парсит манифест (HLS или DASH), встречает зашифрованный сегмент и просит у CDM лицензию. CDM собирает запрос на лицензию, включая (a) идентификатор ключа контента (KID, из бокса tenc – см. нашу статью Common Encryption (CENC) подробно), (b) сертификат устройства и (c) запрошенный robustness. CDM подписывает запрос приватным ключом устройства и шлёт лицензионному серверу.

Шаг 4. Лицензионный сервер проверяет сертификат устройства (список отзыва), проверяет запрошенный robustness относительно сертифицированного уровня устройства и сверяется с политикой контента – набором правил, привязанных к ключу контента в базе сервера. Политика контента – это то место, где живут контракты со студией: «этот ключ может быть выдан L1-устройствам для 4K, L1-устройствам для 1080p с понижением, если нет HDCP, и L3-устройствам с лимитом 720p, и больше никому». Сервер выбирает наивысший robustness, который устройство может предложить и который политика разрешает, собирает лицензию, шифрует её публичным ключом устройства и возвращает.

Шаг 5. CDM расшифровывает лицензию внутри TEE (L1) или в обычной памяти (L3), извлекает ключ контента и передаёт его декодеру. Воспроизведение начинается.

Самая частая ошибка любой команды на старте – считать, что «устройство L1» достаточно. Устройство L1 необходимо, но не достаточно. Лицензионный сервер тоже должен быть сконфигурирован выдавать L1-лицензии; политика контента должна разрешать запрашиваемое разрешение; манифест должен указывать правильный KID (один ключ на ступень разрешения – production-паттерн, см. блок «Типичные ошибки» ниже). Достаточно ошибиться в одном из трёх, чтобы то же самое L1-устройство, которое вчера показывало 4K, сегодня показало 480p.

Типичные ошибки (и как их поймать до production)

«Ловушка: один ключ контента на все разрешения. Если зашифровать ступени 240p, 480p, 720p, 1080p и 4K одним и тем же KID, у лицензионного сервера остаётся одно решение: выдать ключ или нет. То есть L3-устройство, которое успешно расшифровало 720p, автоматически расшифровало и 1080p, и 4K – потому что один и тот же ключ открывает их все. Фикс – один KID на ступень разрешения: 240p–720p общий KID_A; 1080p – KID_B; 4K – KID_C. Тогда сервер выдаёт KID_A L3-устройствам и при этом не выдаёт KID_B и KID_C. Это production-стандарт у каждого крупного OTT-оператора; DASH-IF называет паттерн «multi-key per asset».»
«Ловушка: пустая строка robustness. Веб-приложение, забывшее поле robustness в EME-конфиге, получит то, что выбрал браузер, – а это почти всегда SW_SECURE_CRYPTO (L3). L1-смартфон в руках зрителя так и остаётся на L3, потому что сайт никогда не попросил L1. Всегда выставляйте robustness явно и делайте откат по шагам.»
«Ловушка: считать, что Android всегда показывает L1. Рутованные смартфоны, разблокированные загрузчики, кастомные ROM и подделанная прошивка тихо опускают устройство с L1 на L3. Единственный надёжный способ проверить – вызов MediaDrm.getPropertyString("securityLevel"); нельзя верить разрешению в манифесте только потому, что версия ОС свежая. Бесплатное приложение DRM Info в Google Play отчитывается зрителю; для QA – инструментируйте Android API MediaDrm.»
«Ловушка: запросить HW_SECURE_ALL на Chromecast Audio. Промис requestMediaKeySystemAccess отклоняется, если устройство не может удовлетворить запрошенный robustness. Запрос HW_SECURE_ALL на маломощном Android TV (он может быть L1 на видео, но не иметь защищённого видеоканала) полностью отклоняется, и плеер откатывается до «DRM недоступен» вместо «L1 с понижением». Всегда обрабатывайте отказ повторной попыткой со следующим, более мягким robustness, а не остановкой воспроизведения.»

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

Мы строим и эксплуатируем Widevine-защищённое OTT-видео, видеоконференции и телемедицину в семи вертикалях, в которые поставляем продукты, – стриминг, OTT/Internet TV, WebRTC, видеонаблюдение, e-learning, телемедицина, AR/VR – с момента запуска модульной архитектуры Widevine в 2014 году. Реальная работа, которая окупается, редко выглядит как «интегрировать Widevine»; это матрица QA по устройствам, подтверждающая, что и 1080p Smart TV в спальне клиента, и L3 десктопный Chrome у него на ноутбуке ведут себя корректно; это перевод 14-страничного контракта со студией в 40 строк JSON-политики на лицензионном сервере; это production-grade лестница откатов robustness, которая не оставляет зрителя с чёрным экраном, если у него разблокирован загрузчик. Мы делаем эти вещи по умолчанию, а не как «доп».

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

  • Уровень безопасности Widevine решается чипом устройства, а не сайтом и не плеером.
  • L1 держит ключи, сэмплы и декодированные кадры внутри Trusted Execution Environment с защищённым видеоканалом; L3 всё кладёт в обычную память.
  • Любое устройство для гостиной после 2020 года – L1; любой десктопный браузер на универсальном ноутбуке – L3.
  • White-box-криптография L3 публично сломана дважды, и именно поэтому студии ограничивают L3 720p и ниже.
  • Не устройство, а лицензионный сервер выдаёт ключ контента под конкретное разрешение – поэтому multi-key-упаковка (один KID на ступень) – production-стандарт.
  • Всегда выставляйте строку robustness явно; пустая строка молча понижает L1-устройство до L3-лицензии.

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

CTA

Поговорите со стриминговым инженером – обсудите запуск Widevine-защищённого OTT с нашей командой. · Посмотрите наши кейсы – production OTT и телемедицина из портфолио Фора Софт. · Скачайте чек-лист определения уровня Widevineодностраничный референс с матрицей QA, лестницей откатов robustness и правилами политики лицензионного сервера.

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.