что такое дрм в браузере
Защищенный контент
Зачем нужен защищенный контент
Защищенный контент — произведения, зашифрованные средствами защиты авторских прав. Шифрование данных предотвращает незаконное копирование и распространение информации.
Перед началом просмотра защищенного контента вы получаете ключи шифрования по закрытому протоколу. Основные системы, которые используются для этого:
Яндекс.Браузер, Chrome, Firefox, Opera, Android
Яндекс.Браузер, Chrome, Firefox, Opera, Android
Воспроизведение защищенного контента в Linux
Просмотр видео в Linux на Debian-дистрибутивах (Ubuntu и производные, Mint, Debian) возможен только в Яндекс.Браузере, Google Chrome, Chromium, Firefox. В других браузерах просмотр не гарантируется.
Если DRM-видео в этих браузерах не воспроизводится:
Определите версию браузера, при необходимости обновите браузер до актуальной и перезагрузите компьютер.
Если у вас установлена последняя версия браузера, выполните в консоли команду:
Откройте браузер, войдите в режим «Инкогнито» и попытайтесь воспроизвести видео.
Если воспроизведение идет успешно, очистите кеш в браузере.
Чтобы просмотреть версию Linux, выполните в терминале команду:
При необходимости обновите операционную систему. Для этого введите в терминале:
Подтвердите действие root-паролем и выполните:
Дождитесь окончания установки и перезагрузите компьютер.
Выполните в терминале команду:
Не воспроизводится защищенный контент
Устаревший браузер может не поддерживать технологии, которые используются для быстрой и удобной загрузки видео. Установите последнюю версию вашего браузера.
При первом запуске браузера могут подключиться не все плагины, необходимые для корректной работы системы шифрования контента. Чтобы исправить эту ошибку, перезапустите браузер — плагины подключатся автоматически.
В режиме Инкогнито часто не работает воспроизведение защищенного контента. Чтобы посмотреть защищенное видео, выйдите из режима инкогнито и откройте ссылку с видео в новом окне браузера.
Если вы используете актуальную версию браузера и получаете сообщение, что просмотр недоступен, скорее всего, в браузере запрещено воспроизведение защищенного контента.
Выполните следующие действия в своем браузере:
EME? CDM? DRM? CENC? IDK! Что нужно, чтобы сделать собственный видеоплеер в браузере
Что означают все эти аббревиатуры? Что нужно, чтобы разработать open source-плеер для просмотра видео с Amazon, Sky и других платформ и смотреть видео от любого провайдера? О том, как происходит процесс потоковой передачи видео, Себастьян Голаш (Sebastian Golasch) рассказал на конференции HolyJS 2018 Piter. Под катом — видео и перевод его доклада.
В данный момент Себастьян (Sebastian Golasch) занимает должность разработчика в Deutsche Telekom. Достаточно долго он работал с Java и PHP, а затем переключился на JS, Python и Rust. Последние семь лет трудится над фирменной платформой умного дома Qivicon.
Немного об истории потокового видео
Сначала давайте обратимся к истории веба, как мы пришли от QuickTime к Netflix за 25 лет. Все началось в 90-х, когда Apple изобрела QuickTime. Его использование в интернете началось в 1993-1994. В то время проигрыватель мог воспроизводить видео с разрешением 156×116 точек и частотой 10 FPS, без аппаратного ускорения (с использованием лишь ресурсов процессора). Такой формат был ориентирован на dial-up соединение 9600 бод – это 9600 бит в секунду, включая служебную информацию.
Это было время браузера Netscape. Видео в браузере выглядело не слишком хорошо, ведь оно не было нативным для веба. Для проигрывания использовалось внешнее программное обеспечение (тот же QuickTime) со своим интерфейсом, которое визуализировалось в браузере при помощи тега embed.
Ситуация стала немного лучше, когда Macromedia выпустила Shockwave Player (после поглощения Macromedia компанией Adobe он стал называться Adobe Flash Player). Первая версия Shockwave Player была выпущена в 1997 году, но воспроизведение видео в нем появилось лишь в 2002 году.
Там использовалсы кодек Sorenson Spark a.k.a. H.263. Он был оптимизирован для небольших разрешений и маленького размера файла. Что это значит? Например, видео продолжительностью 43 секунды, которое использовалось для тестирования Shockwave Player, весило всего 560 Кбайт. Конечно, фильм в таком качестве смотреть было бы не очень приятно, но сама технология для того времени была интересной. Однако, как и в случае с QuickTime, для работы Shockwave Player в браузере требовалась установка дополнительного ПО. У этого плеера было много проблем с безопасностью, но самое главное — это то, что видео все еще было надстройкой над браузером.
В 2007 году Microsoft выпустила Silverlight, чем-то напоминающий Flash. Мы не будем копать глубоко, но у всех этих решений было кое-что общее — «черный ящик». Все проигрыватели работали как надстройка над браузером, и вы понятия не имели, что происходит внутри.
Элемент Video/ >
В 2007 году компания Opera предложила использовать тег Video/ >, то есть сделать нативное видео в браузере. Мы используем его и сегодня. Это легко и удобно, и любое видео можно не только просмотреть, но и скачать. И если даже мы не хотим позволять скачивание видео, мы не можем запретить его загрузку в бразуер. Максимум — это сделать так, чтобы скачать видео было сложнее.
Тег — полная противоположность «черному ящику», и просмотреть исходный код очень просто.
Однако вы не можете просто так кликнуть правой кнопкой мыши по видео на Netflix и выбрать пункт «Сохранить как». Причина этого — в DRM (Digital Restrictions Management, управление цифровыми ограничениями). Это не одна технология и не единое приложение, которое выполняет какую-либо задачу. Это общий термин для обозначения таких понятий, как:
Но если говорить о браузерах, то в них декодирование почти всегда выполняется программными средствами. Разные браузеры используют разные системы для DRM. Chrome и Firefox используют Widevine. Эта компания принадлежит Google и лицензирует их DRM-приложения. Таким образом, для декодирования Firefoх скачивает DRM-библиотеку у Google. В браузере можно увидеть, откуда именно идет загрузка.
Apple использует собственную систему FairPlay, которая была создана еще тогда, когда компания представила первые iPhone и iPad. Microsoft также использует свою разработку под названием PlayReady, которая встроена прямо в Windows. В остальных случаях чаще всего используется Widevine. Эта система существует и как приложение, и в виде аппаратного решения — чипов, которые декодируют видео.
Аббревиатура CDM расшифровывается как Content Decryption Module (модуль декодирования контента). Это какая-то часть программного или аппаратного обеспечения, которая может работать несколькими способами:
Cлои декодирования и дешифрования в браузере
Итак, как все это работает вместе? Чтобы это понять, посмотрим на слои декодирования и дешифрования в браузере. Они разделены на:
То, что происходит, когда вы воспроизводите видео в браузере, показано на картинке ниже. Она, конечно, немного запутанная: тут много стрелок и цветов. Я пройдусь по ней по шагам, используя реальные кейсы, чтобы было понятнее
В качестве примера будем использовать Netflix. Я написал приложение для дебаггинга.
Начал я с того, с чего, думаю, начал бы каждый из вас: просмотрел запросы, которые делает Netflix, когда я запускаю видео, и увидел огромное количество записей.
Однако, если оставить только те, которые действительно нужны для воспроизведения видео, окажется, что их всего лишь три: manifest, license и первый фрагмент видео.
Плеер Netflix написан на JavaScript и содержит более 76 000 строчек кода, и, конечно, я не смогу разобрать его полностью. Но я хотел бы показать основные части, которые необходимы для воспроизведения защищенного видео.
Мы начнем с шаблона:
Но прежде чем мы углубимся в функции, нам необходимо познакомиться с еще одной технологией — EME (Encrypted Media Extensions, зашифрованные медиарасширения). Эта технология не выполняет дешифрования и декодирования, это просто API браузера. EME служит интерфейсом для CDM, для KeySystem, для сервера с лицензией и для сервера, на котором хранится контент.
Итак, давайте начнем с getKeySystemConfig.
Стоит иметь в виду, что она зависит от провайдера, поэтому тот config, который я привожу тут, работает для Netflix, но не работает, скажем, для Amazon.
В этом config мы должны сказать бэкенд-системе, какой уровень доверенной исполняющей среды мы можем предложить. Это может быть безопасное аппаратное декодирование или безопасное программное декодирование. То есть мы говорим системе о том, какое аппаратное и программное обеспечение будет использоваться для воспроизведения. И это определит качество контента.
После настройки config посмотрим на создание initial MediaKeySystem.
Тут начинается взаимодействие с модулем дешифрования контента. Необходимо сообщить API, какую DRM-систему и KeySystem мы используем. В нашем случае это Widevine.
Следующий шаг необязателен для всех систем, но обязателен для Netflix. Опять же, его необходимость зависит от провайдера. Нам нужно применить к нашим mediaKeys сертификат сервера. Сертификаты сервера представляют собой обычный текст в файле Cadmium.js от Netflix, который можно легко копировать. И когда мы применяем его к mediaKeys, то все общение между сервером с лицензией и нашим браузером становится безопасным благодаря использованию этого сертификата.
Когда это сделано, мы должны обратиться к оригинальному элементу видео и сказать: «Ок, это система ключей, которую мы хотим использовать, а это тег hello video. Давайте мы вас объединим».
А вот последняя функция, которая нужна для настройки видеосистемы.
Это DRM-сессия, или MediaKeySession. Это просто данные, которые идут от провайдера к модулю дешифрования, который подписывает ими запросы. Эти данные также представляют собой обычный текст, который спрятан за несколькими функциями в файле плеера Netflix, откуда я его и скопировал.
Когда мы вызываем create.Session в объекте mediaKeys, необходимо сообщить, какое видео мы поддерживаем. В данном случае это mp4. Это возвращает нас к контексту обмена сообщениями с нашей системой CDM. Нам также нужно, чтобы Netflix применил сертификат сервера в base64 в каждой форме, но весь этот config в сессии create снова предоставляется зависимым от DRM-системы.
Последняя функция тут внизу — keySession.generateRequest строит лицензионный запрос в фоне. Или CDM строит лицензионный запрос в фоне. Иными словами, это необработанные бинарные данные, которые мы должны отправить на лицензионный сервер, чтобы взамен получить действующую лицензию.
Тут интерес представляет cenc. Это ISO-стандарт шифрования, определяющий схему защиты для mp4-видео. У WebM это называется по-другому, но функцию выполняет ту же.
handleMessage — это интерфейс EventListener, который мы настраивали. Когда это событие вызывается событием message в keySession, мы знаем, что мы готовы получить лицензию с сервера.
И в этом callback мы лишь получаем запрос на сервер с лицензией, который отдает некоторые бинарные данные (они также могут отличаться в зависимости от провайдера). Эти данные мы используем для обновления текущей сессии, добавляя лицензию. То есть как только мы получили действующую лицензию с сервера, наша CDM знает, что мы можем декодировать и дешифровать видео.
Если применить это к диаграмме ниже, то получим вот что: мы хотим проиграть видео, и JavaScript-приложение говорит: «Привет, браузер! Я хочу проиграть видео!» — затем использует Encrypted Media Extensions и делает запрос к License Functions в Widevine CDM на получение лицензии. Этот запрос затем возвращается обратно в браузер, и мы можем обменять его на действующую лицензию на сервере лицензий, и затем нужно передать эту лицензию обратно к CDM. Этот процесс и был показан на коде выше.
Но обратите внимание, что мы еще не проиграли ни секунды видео, и это все нам нужно сделать, чтобы в будущем иметь возможность воспроизвести какие-нибудь видеоролики.
И еще одна технология, которую нам нужно исследовать, — это MSE (Media Source Extensions, расширения для источников мультимедиа). Ее можно назвать сводной сестрой EME (Encrypted Media Extensions). Это тоже API браузера, и она не имеет никакого отношения к DRM. Я рассматриваю ее как программный интерфейс к Video/ > Src. С ее помощью можно создавать бинарные потоки в JavaScript и применять фрагменты видео к элементу Video/ >. Таким образом, благодаря ей исходник тега Video/ > становится динамическим.
Итак, мы можем использовать расширения для источников мультимедиа, инстанцировать и сделать обращение к видео, после чего загрузить фрагменты видео по частям и применить их к тегу Video/ >.
Смысл в том, что, когда вы смотрите двухчасовое видео, вы не хотите ждать, пока оно загрузится полностью. Вместо этого вы разрезаете его на небольшие фрагменты размером примерно от 30 секунд до 2 минут и поочередно применяете их к элементу Video/ >.
Как только наш буфер MediaSource готов и прилинкован к элементу Video/ >, мы можем добавить SourceBuffer. Мы снова должны сказать ему, какой формат видео и какие кодеки мы используем, и тогда он будет создан.
Итак, это почти последний шаг, который мы должны сделать. У вас есть сеть распространения информации, у вас есть фрагменты, и затем браузер отправляет зашифрованные и сжатые фрагменты к CDM, где выполняется дешифрование и, возможно, декодирование. Затем дешифрованные и несжатые фрагменты отправляются обратно в браузер, где они визуализируются и показываются.
Manifest
Но есть еще один момент. Как мы узнаем, какие фрагменты нам нужно загрузить, откуда их загружать и когда? И это последняя часть, отсутствующий запрос из манифеста. Когда мы делаем запрос к Netflix за манифестом, ему требуется много данных. Если мы просто хотим проиграть видео, то для нас имеет значение, какую DRM-систему мы используем, какое видео мы хотим просмотреть (Netflix ID, который можно скопировать из URL) и профили. Профили определяют, в каком разрешении мы получаем видео, а также на каком языке мы получаем аудиодорожки, в каком формате (stereo, Dolby Digital и пр.), используем ли мы субтитры и т. д.
MPEG-DASH
Наиболее часто используемым форматом манифеста является MPEG-DASH. Правда, Apple использует иной формат — HSL, который по виду напоминает список файлов в старом плеере Winamp. Но Widevine и Microsoft используют именно MPEG-DASH. В его основе лежит XML, и он определяет все: продолжительность, размер буфера, типы контента, когда какие фрагменты загружаются, фрагменты для разных разрешений, а также адаптивное переключение битрейта. Последнее означает, что в случае если пользователь, например, смотрит видео и при этом скорость загрузки падает, воспроизведение не останавливается, а просто ухудшается качество видео. Это происходит за счет того, что в манифесте определены одни и те же части для разных разрешений, у них одна и та же продолжительность и одни и те же индексы. Поэтому при уменьшении скорости загрузки браузер может просто переключиться на поток с более низким разрешением, не приостанавливая загрузку и не буферизируя данные.
Вот так выглядит манифест для фильма «Стражи Галактики». В нем мы можем увидеть, что при разной скорости загрузки люди получат видео с разным качеством, а также то, что существуют аудиодорожки для людей с нарушениями слуха. В нем также прописано наличие субтитров.
У нас есть продолжительность и указание на время, с которого надо начать воспроизведение. Эта функция используется, например, тогда, когда вы прерываете просмотр и затем снова возвращаетесь к видео, начиная с того места, где остановились.
Тут также снова есть robustness, который говорит: вот этот фрагмент можно проиграть только в том случае, если ваша система соответствует требованиям. В данном случае это декодирование с помощью аппаратных средств — Hardware Secure Codecs.
Для одной и той же части видео можно определить сколько угодно фрагментов с разными разрешениями.
И затем вы получаете URL для загрузки фрагмента, а параметр range показывает диапазон значений в миллисекундах.
Это и есть последняя часть. Вы также иногда получаете манифест из CDN. У некоторых провайдеров есть отдельный сервер для доставки фрагментов, но чаще всего они приходят с той же машины, что и функциональность манифеста. Когда мы скачали манифест, мы знаем, какие фрагменты нам нужно загрузить, мы можем отправить запрос на фрагменты, после чего дешифровать и декодировать из CDM.
В общем-то, это все. Всего, что было сказано выше, достаточно для того, чтобы разработать open source плеер для просмотра видео с Amazon, Sky и других платформ и смотреть видео почти любого провайдера.
В Netflix посчитали, что стоит добавить дополнительное шифрование сообщений между браузером и сервером. Они назвали это «слой безопасности сообщений» — Message Security Layer, или MSL. Он ничего не делает с видео напрямую, это просто дополнительный слой шифрования. Одна из причин внедрения MSL в том, что HTTPS недостаточно безопасен. С другой стороны, MSL имеет открытый исходный код, поэтому всегда можно посмотреть, как он работает. Тут я не собираюсь углубляться в эту тему, и, если вам это интересно, вы всегда можете найти информацию о том, зачем Netflix делает MSL, в их блоге. На GitHub есть подробная документация по его внедрению и рабочие реализации на Java.
Также есть реализация на Python, которую мы написали с друзьями. Насколько я знаю, это единственный рабочий open source клиент для Netflix. Он работает с Kodi Media Center. Для визуализации можно использовать VLC Player или любое другое подходящее ПО.
И снова «черный ящик»
Итак, вы увидели, что нам понадобилось, чтобы внедрить все это, и насколько часто я упоминал CDM — «черный ящик», который загружается с сайта Google. Таким образом, мы снова вернули видео в «черный ящик». Прекрасный элемент снова спрятан от нас. Мы добавили стороннее программное обеспечение, которое нам помогает, но которое при этом является закрытым и которым мы не можем управлять. Оно может делать много незаметных вещей: трекинг, аналитику, отправку данных…
Вот что по этому поводу говорил Тим Бернерс Ли: «Таким образом, в целом важно поддерживать EME как относительно безопасную онлайн-среду, в которой можно смотреть фильмы, а также как наиболее удобную и такую, которая делает ее частью взаимосвязанного дискурса человечества».
Но есть и другие мнения относительно этого. В частности, от Electronic Frontiers Foundation, которая до появления DRM была участником W3C. Вот что они говорят: «В 2013 году EFF была разочарована, узнав, что W3C взяла на себя проект стандартизации EME — зашифрованных медиарасширений. По сути, мы говорим об API, единственной функцией которого должно было стать обеспечение для DRM главной роли в экосистеме браузера. Мы будем продолжать бороться за то, чтобы интернет был свободным и открытым. Мы будем продолжать судиться с правительством США, чтобы отменить законы, которые делают DRM таким токсичным, и мы будем продолжать бороться на уровне общемирового законодательства».
Мне сложно сказать, как к этому относиться. С одной стороны, я всегда за открытый и свободный интернет, в браузерах которого нет закрытого кода, который может отправлять запросы неизвестно куда. С другой стороны, нам нужны сервисы наподобие Netflix, которые взимают плату за видео. Возможно, они могли бы создать собственные приложения для воспроизведения, и тогда интернет отказался бы от такого рода контента.
Уже через месяц, 24-25 ноября, в Москве пройдет HolyJS 2018 Moscow, где Себастьян выступит с докладом «The Universal Serial Web»: подробно разберет новый стандарт WebUSB, возможность работать с USB-устройствами из браузера. Всё это с живыми демо-примерами, очень интересно и наглядно.
DRM для защиты онлайн-видео
Что такое DRM?
Распространение видео через Интернет становится все популярнее, тенденции развития медиарынка демонстрируют нам, что с течением времени доля онлайн-видео будет только увеличиваться. Прогнозы различных агентств в данном вопросе различаются не слишком и сходятся к тому, что к 2018 году объем онлайн-видеотрафика в Интернете составит около 80%, а если учесть весь видеотрафик — VoD, P2P, ТВ, — то эта цифра вырастает до 90%. При этом утверждается, что ОТТ займет чуть меньше половины всего сектора платного ТВ. Разумеется, при таком прогнозе вопрос защиты контента в ОТТ становится чрезвычайно актуальным.
DRM — это набор технологий, который, во-первых, позволяет владельцу или распространителю премиального или персонального контента защитить его, например зашифровать. Во-вторых, DRM позволяет установить правила взаимодействия зрителя с контентом. То есть определить тарифную политику, допустимые к легальному использованию абонентские устройства, разрешить или запретить копирование и предоставление контента другим лицам. DRM появилась для защиты видеокассет и аудиодисков, и сейчас это основной механизм, позволяющий контент-провайдеру защитить свою услугу от несанкционированного просмотра, пиратства и других нарушений правил пользования.
Какие бывают типы DRM?
Существует два типа DRM: анонимная и авторизованная.
Анонимная (не требующая авторизации пользователя) DRM защищает контент в точке его хранения, например на вещательных серверах, и позволяет назначить общие правила для его распространения и просмотра. Защищается как медиафайл, так и метаданные и политики доступа.
В случае анонимной DRM предполагается, что видеосервис сам проверяет авторизацию пользователя в момент загрузки приложения или при заходе на сайт через браузер. Например, если прав на просмотр нет, в приложении просто не будет кнопки Play. Сервер DRM считает, что все обратившиеся за ключами из правильного приложения имеют на них право.
Анонимной DRM достаточно для контроля доступа и поддержки многих моделей распространения премиального контента. Есть много готовых решений, например Adobe Access и Google Widevine, которые работают на самых различных абонентских устройствах: мобильных гаджетах, персональных компьютерах, Smart TV и игровых консолях. Анонимную DRM реализовать быстрее и проще, чем авторизованную.
В случае авторизованной DRM сервер DRM выдает пользователю ключ для начала просмотра и уточняет у контент-провайдера, что это за пользователь — имеет ли он право доступа и можно ли ему посылать ключи дальше. Авторизованная DRM обеспечивает более высокий уровень контроля, предоставляя возможность реализовать модели монетизации контента, предусматривающие идентификацию каждого отдельного пользователя. Авторизованная DRM позволяет распространителю расширить набор правил пользования контентом и увеличить количество моделей распространения, например реализовать доступ к просмотру видео с определенного количества разных устройств в течение срока аренды в модели TVOD, подписку (SVOD), пакетирование видеосервисов, окна просмотра.
В чем разница между криптованием и DRM?
Криптование сигнала предполагает использование какого-либо алгоритма шифрования для того, чтобы доступ имели только авторизованные пользователи. Обычно контент-провайдер сообщает легальному клиенту алгоритм и ключ для расшифровки. Например, в онлайн-банках шифруется информация, которой обмениваются между собой клиент и банк. После расшифровки клиент может делать с контентом что угодно.
DRM, помимо криптования, позволяет устанавливать правила, предписывающие, каким образом, где и как этот контент может быть использован. Например, DRM можно настроить так, что абонент не сможет после просмотра контента его как-либо сохранить в незашифрованном виде. Поэтому DRM обеспечивает гораздо более высокий уровень защиты от нелегального шаринга, и практически все крупные производители контента требуют от распространителей, помимо криптования сигнала, применять DRM, причем проверенный и утвержденный специальными организациями, проверяющими DRM на устойчивость ко взлому.
Надо заметить, что идеальный вариант защиты недостижим. Задача запрета копирования при разрешенном воспроизведении легче решается в том случае, когда абонентское устройство находится под контролем распространителя контента, например в случае операторских телевизионных приставок, специальных видеоплееров со встроенной защитой или в случае закрытых платформ, таких как Smart TV. а для контроля пиратства вводятся дополнительные технические средства типа водяных знаков.
Для повышения надежности защиты технические методы сочетают с юридическими: в большинстве стран, включая Россию, предусмотрена ответственность (как правило, финансовая) за взлом, отключение или удаление DRM. Например, согласно статье 1299 ГК РФ не допускается «изготовление, распространение, сдача в прокат, предоставление во временное безвозмездное пользование, импорт, реклама любой технологии, любого технического устройства или их компонентов, использование таких технических средств в целях получения прибыли либо оказание соответствующих услуг, если в результате таких действий становится невозможным использование технических средств защиты авторских прав либо эти технические средства не смогут обеспечить надлежащую защиту указанных прав». В случае нарушения этого пункта пострадавший имеет право требовать возмещения убытков или выплаты компенсации.
Как работает DRM?
Защищенный контент нужно расшифровать перед проигрыванием. Для этого плеер, проигрывающий видео в веб-браузере или приложении, взаимодействует с сервером DRM, который запрещает или разрешает просмотр контента на данном устройстве и выдает лицензию, содержащую политики использования контента.
DRM в веб-браузере
В последнее время в связи с развитием браузеров и появлением в них встроенной обработки видео появилась необходимость перенести функционал DRM из плеера в браузер. Браузеры обрабатывают содержимое cтраницы в соответствии с рекомендациями консорциума W3C. И для защиты контента W3C разработал спецификации Encrypted Media Extensions (EME). EME предполагает стандартный API для всех систем защиты, от простого шифрования с ключами и до решений DRM от известных производителей. Сама расшифровка и управление лицензиями и ключами будут происходить в проприетарном модуле уровня приложений CDM — Content Decryption Module, — который разрабатывают производители DRM. При внедрении такой системы в браузер правообладатели cмогут контролировать воспроизведение своего видеоконтента в Html5.
Но пока HTML5 используется в основном для бесплатного видео, распространение которого не требуется ограничивать, и за защиту контента отвечает встраиваемый в HTML-страницу плеер. Использование DRM в этом случае обычно подразумевает установку соответствующего плагина, если он уже не встроен в плеер.
iOS и Android
Существует два пути трансляции контента на мобильные устройства: при помощи «родного» приложения, загружаемого с iTunes App Store или Google Play, или же при помощи браузера, установленного на мобильном устройстве. Все системы DRM работают только с «родными» приложениями, для браузеров обычно применяются другие решения, например шифрование для HLS.
SMART TV и игровые приставки
DRM может быть частью платформы SMART TV, в этом случае видеосервисы, которые работают на этой платформе, должны использовать вариант защиты, выбранный производителем телевизоров. Сейчас многие из разработчиков интегрируют в свои телевизоры систему Widevine, но постепенно растет доля и других решений.
В конце 2011 года Microsoft анонсировала внедрение системы PlayReady в игровую консоль Xbox LIVE. Это единственная система DRM, доступная на Xbox. Другие игровые приставки, такие как Sony PlayStation 3 и Nintendo Wii, поддерживают Widevine.
Популярные DRM-решения
Adobe Access (Flash Access)
DRM-приложение от Adobe, интегрированное во Flash Access. Пользователи могут даже не знать, что используется защита, так как скачивают плагин плеера вместе с предустановленным DRM-модулем. Так как флэш-плеер является одним из самых распространенных в браузерах, Adobe Access тоже используется очень широко. Последние версии защищают не только flash-контент.
Widevine осуществляет защиту поверх многих транспортных протоколов, включая Apple HLS и Adobe Flash. Widevine используется в Smart TV, в мобильных устройствах, для защиты blueray-дисков. Widevine на устройствах очень популярен — сегодня насчитывается около 540 млн устройств с Widevine. Популярности способствует отсутствие лицензионных отчислений с каждого устройства. Но решение небесплатное — интеграторы платят 50 тыс. долларов в год. Эти деньги расходуются Google на поддержку и разработку системы.
PlayReady — система DRM, разработанная для игровых приставок Xbox, операционной системы Windows 8 и для мобильных устройств, работающих под Windows. Также Microsoft активно продвигает портирование Play Ready на другие устройства. Сейчас, например, PlayReady поддерживают практически все Smart TV. Однако портированием PlayReady на устройства занимаются другие компании, и, по словам российских экспертов, одна из проблем PlayReady — невозможность купить решение сразу на все устройства. Требуется отдельно платить за оболочки, разработанные для мобильных устройств.
Microsoft советует использовать PlayReady со своим адаптивным протоколом SmoothStreaming и надеется в перспективе на MPEG DASH. Несколько известных провайдеров онлайн-видео, такие как Netflix и HBO GO, используют эту DRM.
Эта DRM-платформа с открытым стандартом разработана сообществом Marlin Developer Community (MDC).Само сообщество создано компаниями Intertrust, Panasonic, Philips, Samsung и Sony. Marlin используется для защиты контента в британском сервисе YouView.
В России эта DRM практически не используется. По словам российских экспертов, Marlin — отличное решение, гибкое и дешевое. Однако его внедрение в проект требует специалистов высокого класса, что нивелирует его дешевизну. Появление облачного DRM-сервиса Expressplay, возможно, будет способствовать росту популярности Marlin.
Вообще, у всех решений DRM есть стоимость лицензирования и стоимость инженеров, ее обслуживающих, и при оценке расходов на DRM нужно учитывать оба этих аспекта.
Выбор подходящей платформы DRM зависит от множества факторов: бюджет, требования по защите и использованию контента (как ваши, так и правообладателей), требования к абонентским устройствам. К тому же это очень динамичный рынок: возможности платформ меняются буквально каждый год. Один из важных факторов, влияющих на выбор системы DRM, — пакетирование контента. Например, правообладатель может предоставлять сервис-провайдеру уже пакетированный и криптованный контент. Также правообладатель может предъявлять к сервис-провайдеру свои требования по защите контента.
По материалам компании Brightcove
Подпишитесь на канал «Телеcпутника» в Telegram: перейдите по инвайт-ссылке или в поисковой строке мессенджера введите @telesputnik, затем выберите канал «ТелеСпутник» и нажмите кнопку +Join внизу экрана.